On Mon, 2008-09-15 at 23:28 +0200, Ivo van Doorn wrote: > On Monday 15 September 2008, 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. > > I think the ACK handling could become quite complex, and although it > would be nice to modularize it a bit, however I am not really sure about > what the best approach would be for the implementation other then that > the driver should do as little as possible. ;) Huh? I think a single function call for the matching in the rx path is enough. You call it in the rx handler for every received frame. It returns true if it found a match and reported the tx status (in which case you stop processing) or false and you can go on doing with the frame whatever you want. Am I missing something? > > Perhaps Mikko or the zd1211rw developers will have better ideas on this subject. :) > > > > > 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. > > Well this information would definately get lost with this ACK handling, > but at least we get *some* information about the TX status. ;) The (not) failed decision is definitely enough to get the PID algo doing something useful. Mattias -- 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
