Hi, [Manikanta] In that case I will keep this change, should we consider a separate driver hook for legacy/mgmt tx like drv_tx_8023?? > How about having wake_tx_queue_8023 and ieee80211_tx_dequeue_8023 so > that Ethernet transmit path is totally exclusive. Thoughts?? I'm not sure this will work well. The driver might have more space for sending to a specific station, but doesn't really know which frames should go first. So either it'd have to call both (dequeue_8023 followed by dequeue) with mac80211 sorting out what to do, or we should keep it combined. I think mac80211 sorting out the priority here etc. would be far more complex than this. > [Manikanta] Hmmm, I would like to have ieee80211_tx_status_8023 for > now and go with a TODO for single tx reporting mechanism for both > Ethernet and 802.11 tx formats. Any thoughts? There's an additional wrinkle btw - we currently report the 802.11 frame to the monitor interface, if active. Not sure we can keep that, but it's something to think about. > > The only real alternative I see, which might be preferable, is for > > the driver to advertise a bitmap of interface types that it wants > > to use ethernet framing with. > > > > [Manikanta] Correct, this would be a onetime registration. Isn't it ? > I am just curious to know whether the supported vif types for > ethernet framing can change dynamically, is this possible? I don't see why it would change. I guess there's a small chance that you might design the HW in a way that it only has enough HW resources to do header format conversion for a limited number of interfaces, but if that ends up being a problem we can perhaps add more other capabilities. The way we're looking at it will be type/header format dependent, nothing else. johannes
