> Message: 1
> Date: Sat, 27 Oct 2012 16:18:11 -0700
> From: Adrian Chadd <adr...@freebsd.org>
> To: email@example.com
> Cc: FreeBSD Net <freebsd-...@freebsd.org>, freebsd-a...@freebsd.org
> Subject: request for help: 'fixing' the 802.11 TX path
> Content-Type: text/plain; charset=ISO-8859-1
> Hi all,
> I'd like to try and sort out the last remaining niggles in the 802.11
> code - this email is focusing on the TX path.
> The TX path has a few problems:
> * there's a normal versus raw TX path (for raw frames, management
> frames, etc) - the raw path doesn't necessarily queue frames into the
> raw TX queue, so it's a kind of "side path" to the driver. This causes
> frame ordering problems with things like sequence number allocation.
> * there's limited locking in the TX path, primarily because you can't
> _really_ fine grain lock the TX path. Since you have multiple TX
> thread contexts all sending into the same driver queue and that queue
> has to share incrementing sequence number, aggregate status and CCMP
> encryption replay counters, you _have_ to either use some long-held
> mutexes to enforce this _or_ throw all sending into a TX thread and
> run that.
> * raw TX requires some extra state to be glued (the bpf_params info);
> I'd like to glue that into mbufs as an option, so the driver can use
> those instead of interpreting their own 802.11 header contents.
> And the one I'd like to discuss here:
> * Fragment transmission is totally broken and causes mbufs to be just
> leaked. The problem with sending fragments (at least for the ath
> drivr) is the packet duration calcluation requires the _next_ fragment
> to be available.
> Now, this is a design hold-over from the previous, pre-vap scheme. The
> driver netif would be handed a raw mbuf frame, which it would then
> pass through the net80211 encapsulation code and that would
> potentially generate 802.11 fragments. The rest of the driver TX path
> would then see that it was handed a fragment list and TX those.
> Fragments were chained together using m_nextpkt, like a normal mbuf
> This doesn't happen any longer. The net80211 vap gets the raw frame,
> which then sends that to the driver netif after doing the vap and
> 802.11 state / encapsulation work. But since all the wifi drivers use
> if_start() right now, m_nextpkt gets blanked on both encap and decap..
> and thus things leak.
> Now I can't really see a way around this, without doing dirty hacks
> with mbuf attributes to link the fragments together. The only clean
> way I can see is to force all wifi drivers to use if_transmit(), and
> then have if_transmit() interpret a chain of frames as "the fragment
Cannot we just add custom hand off function to ieee80211_start()?
/* We can also queue mgt packets to the same queue */
for (m0 = m; m0->m_nextpkt != NULL; m0 = m0->m_nextpkt);
ifq_tail = m0;
taskqueue_enqueue(taskqueue, parent->if_new_tx_function); /*
or wake(); */
Because of IF_LOCK, queued packets and seq num should be in order.
Then, the driver only need to dequeue and Tx. The drivers can tell if
the packet is a fragmented packet or a standalone packet from
ieee80211 header or we can add a new member to bpf_params.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"