On Thursday 15 December 2016 02:46 PM, Johannes Berg wrote:
>
>> Drivers advertising this capability should also implement other
>> functionalities which deal with 802.11 frame format like below
>
>> - ADDBA/DELBA offload
>
> This shouldn't be necessary.
Ok. Since driver/hw needs to implement Tx/Rx aggregation related functionalities
I thought ADDBA/DELBA processing will be little important to mac80211. May be I'm
missing something.
>
>> - Hardware rate control
>
> Neither is this, if we find some API to do sampling. The existing rate
> table API already allows setting the rates out of band, so the only
> thing that you'd have to support out of band is sampling.
Ok.
>
>> - Powersave offload
>
> That's ambiguous - you do need to handle sleeping stations (and PS-
> Poll/U-APSD) in AP mode in the device with this,
I did not dig deep into PS requirement with ethernet frame format because
frame control is not available to mac80211, so I thought to mention PS offload
is a requirement. May be there is already an infrastructure in mac80211 to
learn PS state of client which was notified in the current data frame (other
than 802.11 frame control).
but I don't see a deep
> technical reason to require it for client mode. OTOH, client mode is
> almost always offloaded anyway.
Ok.
>
> I think you may have forgotten one important item,
>
> - control port handling
Hmmm, I'm getting WPA-PSK working with this. May be there are other
control port handling which will not work with ethernet frame format?
>
> ?
>
>> + * @IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP: Hardware/driver
>> supports 802.11
>> + * encap/decap for data frames. Supporting driver have to
>> implement
>> + * get_vif_80211_encap_decap_offload() to pass if 802.11
>> encap/decap
>> + * offload is supported for the vif.
>
> I don't see why you need this, when you have the method - you can just
> assume that the method returns false when it's not implemented.
Ok, I was trying define an interface for driver to return vif type based
encap/decap capability so that in 4-addr and Mesh type 802.11 frame format
is used.
>
>> struct ieee80211_ops {
>> void (*tx)(struct ieee80211_hw *hw,
>> @@ -3639,6 +3651,10 @@ struct ieee80211_ops {
>> void (*wake_tx_queue)(struct ieee80211_hw *hw,
>> struct ieee80211_txq *txq);
>> void (*sync_rx_queues)(struct ieee80211_hw *hw);
>> +
>> + int (*get_vif_80211_hdr_offload)(struct ieee80211_hw *hw,
>> + struct ieee80211_vif *vif,
>> + bool is_4addr, bool
>> *supported);
>
> Why are you not simply returning "supported"?
>
> I don't like passing the vif pointer here. At this point, the vif
> pointer isn't known to the driver yet (through drv_add_interface) so
> it's a dead pointer as far as the sequencing is concerned.
>
> Is there a possibility that drivers need to switch off ethernet format
> handling entirely when an incompatible interface is added? For example,
> if you add a mesh interface, is there a chance that the AP interface
> might no longer be able to handle this?
>
> I'd hope this doesn't happen because I think that would be extremely
> complicated to handle safely.
Unfortunately "[RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload"
tries to implement this but more likely buggy :(. You are right, it is very
complex to get that right. May be we should not allow interface needing
dynamic switch?
Vasanth
