quoted

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