Date: Sun, 14 Apr 2013 16:28:15 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Monthadar Al Jaberi <monthadar@gmail.com> Cc: freebsd-wireless@freebsd.org Subject: Re: 802.11 TX Path && mesh data forwarding Message-ID: <CAJ-Vmok1JdXeO4s-wypVEhmf7pGw5EtE6Beqp4sb4dd%2BR_q_oA@mail.gmail.com> In-Reply-To: <CA%2BsBSoJsYRRq5PeJVp9av_hSNEmQ-2xoF1h-mozRXdH=6CijQg@mail.gmail.com> References: <CA%2BsBSoJsYRRq5PeJVp9av_hSNEmQ-2xoF1h-mozRXdH=6CijQg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
So what we've discussed thus far is to create another mbuf tag and use that for TX setup related material. right now the only 802.11 mbuf tag is for TX completion callback information. The rest of 802.11 state is not kept in a tag. What I'd actually like to do is to migrate the bulk of the 802.11 state into an mbuf tag (or two maybe, one for TX, one for RX) and then use that everywhere. But that can come later. I have a prototype somewhere for migrating the tx parameter information for raw transmit frames into an mbuf tag; that way ic_raw_xmit() can go away and be replaced by the driver decoding each mbuf and seeing if it's a raw frame or an 802.11 frame. If it's a raw frame then the driver start / transmit method can just call xxx_raw_xmit(). That way everything stays serialised. So if we're going to do that, we may as well stuff the mesh info in an mbuf tag (same one, or new one, it doesn't really matter.) That way we can re-inject forwarded mesh frames back into the VAP and the VAP code will have all the info it needs to resynthesise said mesh frame for transmission. that's my current handwavy idea. :-) Adrian On 14 April 2013 04:27, Monthadar Al Jaberi <monthadar@gmail.com> wrote: > Hi everyone, > > I would like to bring up an issue me and Adrian have been thinking bout for > some time now. > > It has to do with the recent TX path code re-write Adrian have been working > on and how that affects the 802.11 mesh code. And what is the best solution > for handling data frame forwarding. > > I think mesh_forward need to be refactored and modified. And basically just > after duplicating the data frame and decrementing TTL we need to queue the > frame somehow. > > This frame is an 802.11 frame that needs to go through the same low level > TX processing a frame coming down from the stack go through. > > We need to mark the mbuf containing the frame somehow so we skip some steps > in the normal TX path. Or maybe we need to add a new queue or something > similar. > > Any thoughts are much appreciated. > > -- > Monthadar Al Jaberi > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmok1JdXeO4s-wypVEhmf7pGw5EtE6Beqp4sb4dd%2BR_q_oA>