Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Tue, 2019-04-16 at 16:36 +0800, Herbert Xu wrote: >> On Tue, Apr 16, 2019 at 10:04:24AM +0200, Arend Van Spriel wrote: >> > >> > I was just writing up an email clarifying my question. But let me summarize >> > this email thread. The patch from Felix adds this flag in mac80211 for >> > drivers that indicate to support pulling packets from the internal TXQ in >> > mac80211. I found it is deprecated, but as Felix mentioned it is used in >> > various parts of the network subsystem, ie. batman-adv, bridge, vlan, tunnel >> > implementations. So its use seems to be restricted rather than deprecated. >> > Given your response above I guess my question would be to get details about >> > what you call "proper design" as I think you are saying with that it is not >> > needed, right? >> >> Essentially the only time it would be OK to use LLTX in its current >> form is if you have no TX queue/congestion feedback which is clearly >> not the case with wireless drivers. > > It is true because we have an entire buffering layer in mac80211 (in > this case at least) and never push back to the stack. I'm wondering if we should be? For instance, fq_codel returns NET_XMIT_CN if it drops a packet from the same flow that it enqueued to. We could conceivably do the same in mac80211, although we'd have to carry the return value out through quite a few layers. Not sure if this is worth it? Eric, do you have any insight into what impact the _CN return has from fq_codel? -Toke
