> > Why is that needed? Since you have a separate TX path > > (ndo_start_xmit), > > wouldn't it make more sense to call into a drv_tx_8023() or > > something like that instead? > > > > [Manikanta] Yes, it makes sense having a separate driver hook > instead of using drv_tx, but in case of drivers (fe ath10k) > where enqueuing and dequeuing tx logic (wake_tx_queue and > ieee80211_tx_dequeue) is used there should be a way > to indicate that the packet is not 80211 encapsulated, isn't it? > Correct me if I am missing anything. Ah, interesting. Yeah, I guess that makes some sense then, though I'm not super happy with sharing the code paths between differently encapsulated frames - best to leave that as minimal as possible. > [Manikanta] Hmmm you are right. I just went through the code, seems > ieee80211_tx_status_noskb does most of them what > ieee80211_tx_status_8023 is doing, resetting the station connection > monitoring logic and updating last known tx rate is missing in > _noskb. These are required, isn't it? Maybe. I don't think the tx rate is strictly required but would be nice, while the monitoring logic is probably needed only to avoid spurious null data packets over the air. However, come to think of it, we need to see how this interacts with the tx status thing - if tx status is requested then I believe _no_skb cannot be used. > [Manikanta] You are correct. It is good if driver advertises the vif > types it support in encap offload mode, but how can we decide the > netdev_ops to be used while creating the vif? drv_add_interface will > be invoked from ndo_open and > even before invoking driver add_interface we have to make the > decision of using Ethernet mode netdev_ops or the default netdev_ops, > isn't it? It might not be a problem to swap the dev->netdev_ops, changing only the start_xmit, while the interface is being brought up. I assume the driver can make this decision in add_interface(), and I think swapping there should be OK. It might be problematic if this value changes during suspend/resume or HW restart though. > Can we have a separate driver hook which gives whether 80211 encap > offload is supported for the given interface type and then decide the > netdev_ops to be attached for the vif? I don't think that makes sense, since you can't know if the interface will ever be brought up, so the driver can't make a good decision since it normally doesn't have to care about interfaces that aren't brought up. 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. johannes
