On Fri, May 11, 2007 at 04:04:30PM +0100, Andy Green wrote: > Could I possibly be talking about this? > http://marc.info/?l=linux-wireless&m=117882282325836&w=2 > > You understand re-reading this that when he talks about "You submit one > Tx request to the [']hardware['] and it then performs all the retries, > fallbacks, etc without host interaction over overhead." this is stuff in > the closed-source firmware? Aka "binary blob" with restrictive license? So? I don't see what this has to do with mac80211 rate control algorithm selection. This is about 802.11 functionality that has very strict timing requirements (SIFS between frame and ack and then re-try if no ack received). That is (I would say, has to, in most cases) be done somewhere else than on the host CPU. In other words, this is something that really needs to be in the wlan hardware or firmware. > Is it really true this is a feature of hardware and not closed-source > firmware? Because if I was designing such a thing - and I have designed > similarly complex silicon - damnned if I would allocate pure hardware to > it. Since the device already has a concept of firmware, as we can all > see, I would instead implement these multistage actions with the > firmware. Which happens to be closed source by Intel's choice. I do not know ipw3945 design, but I do know other wlan chipsets that do indeed take care of TX rate control between retries of the _same frame_ in hardware. No firmware involved there. Then again, I really do not follow this logic of firmware being some horrible thing that simply cannot be allowed to do anything. In this particular case, this really has to be done at the wlan chip, not at the host CPU due to timing requirements. > AIUI the proposal is to tag packets with lists of rates to retry at. > But if the aimed-for and typical case is that you get through on the > first try, how interesting is it really to migrate the retry action to a > closed-source and per-vendor (or per-device) implementation instead of > coming through the rate selection action in the stack. Being able to vary the TX rate on the SIFS-retries can produce huge improvements to rate adaption. I see this a very much valid reason for providing an alternative rate control algorithm that can take advantage of the hardware/firmware features. > Stack == mac80211. No: what James is talking about, as I quoted above, > is a firmware implementation of "per-packet rate-list automatic retry" > that requires special support in mac80211. I can only say that we see this quite differently and all I've seen from James so far on this topic makes sense and should be supported in mac80211. Firmware implementation does _not_ replace the mac80211 rate control algorithm, but modified mac80211 rate control algorithm can be used to improve rate adaption in this case and such modifications would not benefit (or be possible) with some other wlan chipsets. Thus, need for multiple mac80211 rate control algorithms and benefit from drivers being able to propose which one to use by default. > Let me ask: is it really so impossible to create a generic "nearly > optimal" algorithm for rate selection in the stack that you have to > offload the task to $DRIVER? What is it about the awesome software > running in $DRIVER or $DEVICE that can do a better job than mac80211 > ever can? Yes, in practice, it is more or loess impossible with the timing requirements on 802.11 retries. This is not about driver vs. mac80211, this is about the timing differences between wlan chip vs. host CPU. I don't want to implement all rate control stuff in hardware/firmware, but the part that involves first couple of retransmission of frames that are not acked within SIFS really falls for the wlan hardware (including firmware, if used in the design) category, not host CPU, if aiming for the best possible rate control. -- Jouni Malinen PGP id EFC895FA - 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
