Search Linux Wireless

RE: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

>> [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.
>
[Manikanta] Good point, this is something we have to think about. I believe this one is tricky, do we need to add the .11 header just before giving to monitor interfaces?
How important will this be for Ethernet tx changes? I am running out of thoughts.

>> > 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.
>
[Manikanta] Hmmm okay.

Manikanta




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux