On Thursday 15 May 2008, Johannes Berg wrote: > > > > > A number of fixes were done by Ivo, as well as the rt2x00 part > > > > of this patch. > > > > > > I mangled it a bit though so you may want to check it, mac80211 now sets > > > REQ_TX_STATUS so you can use that for status reporting, but you can't > > > use it for queue kicking at least not in the future when mac80211 might > > > not set it on all frames. > > > > Well queue kicking from driver to mac80211 is in rt2x00 based on txdone > > events on a particular queue. (When frame was succesfully transmitted > > and is no longer full, then the queue will be awakened by rt2x00). > > 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 :) > 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. Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
