Johannes Berg wrote:
Hi,
I'm not sure we can easily use such a "stream" for off-channel
operation. In particular, that "stream" might not support multiple
queues.
Does it need to? It could as well just map all queues to a single hw
queue with this design. I'm not sure if I get your point here.
Is it okay for us to not care if the driver supports real queues for
ACs? Should we care if a driver maps all ACs from a channel context (or
vif for that matter) onto a single hw queue? I'm wondering whether that
would simplify code paths?
Well, ok, that would be possible, but I'm not sure I see the point in
using a stream for off-channel. Today, we completely offload off-channel
to the device, and I don't see how that could change? Having temporary
context allocations all the time seems like a lot of thrash?
We could pre-allocate a fixed number of channel contexts based on the
interface combinations, so we'd be "only" left with rebinding those
contexts (and queue mappings along too).
I guess this part of the discussion is moot since we're going to put
queues in vifs (and not in channel contexts).
But how do we then check if we need to stop given queue or not? Let's
say a driver stops q=2 which corresponds to BE on vif0 and vif1. But
then comes mac80211 aggregation and stops BE on vif0. I can only think
of a single solution to that: "u8 lock_reasons[256];" in ieee80211_local
but it seems like an overkill or is it not?
Essentially that's what I was considering, we'd maintain all the queue
state per HW queue ID. I said it would be a u8 for the HW queue ID, but
I don't see anyone using more than say 32 or so, so we wouldn't really
need 256. But we could go up to 256 if needed (though at that point we
should probably do dynamic allocation instead.)
We could maybe allocate it according to hw.queues? I think it should be
okay unless a driver has some kind of non-static queues. Are you aware
of such a device/driver?
-- Pozdrawiam / Best regards, Michal Kazior.
--
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
