On Mon, 2008-09-15 at 22:33 +0200, Johannes Berg wrote: > On Mon, 2008-09-15 at 22:20 +0200, Mattias Nissler wrote: > > > Well, I'm a big fan of modularizing everything in a clean way. This > > whole mac80211 thingy is complex enough... But I don't really care as > > long as everybody here is happy with it. Let's wait what Mikko says, > > it's his code so far. > > Sure. If you manage to split it out entirely, maybe by some struct that > drivers embed in their private vif struct, that'd be great too. > > > > > But ACK is getting confusing, we're just reporting status based on > > > reception (or non-reception!) of ACKs :) How about retries in the hw? > > > > Retries in the hw? I don't understand? You mean that as a name? > > Well, with all this we won't know how many times the hardware attempted > to send a frame before it got an ACK, if it got one at all. We'd like to > know this too, I guess, for the rate control algorithm. > > johannes My suggestion would be something along the lines of awaiting_status_queue because the packets are waiting for status info about their transmission. To get the AP mode working (my main interest) hostapd needs to know that the other party has received the packet so that it can advance in its state machine without losing sync. The rate control algorithms on the other hand are probably interested in getting a lot more details. Currently drivers seem to keep internal statistics in addition to the external ones. Maybe some way of exporting additional statistics is needed and tackling that should perhaps not be tied to the status reporting? Rate control algorithms will probably also want to modify re-transmission intervals, contention time settings etc. Is there already some unified way of doing this? Mikko -- 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
