Re: [PATCH 5/5] mac80211: move TX info into skb->cb

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]


> > Yeah, but the patch you had sent me was removing the "driver generated"
> > flag, and I kept that around now for this purpose.
> 
> I think we refer to different things when we talk about "queue kicking" ;)
> Anyway, I'm fine with how it looks like now. It means I can remove a few
> patches from rt2x00.git :)

Maybe :) I was talking about this hunk:

@@ -179,8 +176,10 @@ void rt2x00queue_write_tx_descriptor(str
 
        /*
         * We are done writing the frame to the queue entry,
-        * if this entry is a RTS of CTS-to-self frame we are done,
-        * otherwise we need to kick the queue.
+        * also kick the queue in case the correct flags are set,
+        * note that this will automatically filter beacons and
+        * RTS/CTS frames since those frames don't have this flag
+        * set.
         */
        if (rt2x00dev->ops->lib->kick_tx_queue &&
            !(skbdesc->flags & FRAME_DESC_DRIVER_GENERATED))

which looked vastly different in your original version and tested
IEEE80211_TX_CTL_READY_FOR_TX I think.

But if you're ok with that, that's great :)

> > I have thought about this a bit, you may want to wait wrt. fragments
> > because I'm going to rewrite fragmentation, and then we could change the
> > mac80211/driver API to hand the driver an skb with all the fragments at
> > once instead of handing it each fragment one by one, thoughts?
> 
> Well that would mostly be beneficial for rt61pci who is able to attach
> multiple fragments into a single queue entry. But for the others that wouldn't
> matter that much since each fragment occupies a single queue entry, so for
> those drivers having mac80211 calling tx() multiple times, or having rt2x00
> call write_tx_frame() multiple times isn't a big difference other then rt2x00
> being able to better control frame flow by kicking the TX queue only when
> all fragments are in the queue.

Well I expect that this would have to be controlled by a hardware flag
anyway. Also, it might get you into trouble with the number of free
queue entries because mac80211 would definitely expect you to take all
fragments then, you couldn't just take the first 2 and leave 2 to
mac80211, for example.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]