Re: [RFC bluetooth-next 00/15] ieee802154: add support for phy capabilities

[Varka Bhadram <varkabhadram@gmail.com>]

Hi Alex,

On 04/25/2015 03:36 PM, Alexander Aring wrote:

> On Fri, Apr 24, 2015 at 10:41:52AM +0530, Varka Bhadram wrote:
> ...
>> May be this is not the right place to ask this question.
>>
> creating a new mail to linux-wpan next time? And of course you can ask
> this here.
>
>> Do you think that patch at [0] required to us..?
>>
> no.
>
>> That will be useful multi-queue environment. Even though
>> its better to have this feature.
>>
> Note about tx multi-queue environment:
>
> Wireless (802.11) != 802.15.4
>
> 802.11 follows different strategies like 802.15.4 follows [0]. "was
> chartered to investigate a low data rate solution...", of course
> low-power and such things. I would not say that performance isn't
> important for us. (I also like to remove several shift operation in the
> current frame parsing) What I am think is that a multiqueue environment
> gives us not a big benefit.
>
> Maybe I am wrong here, you can implement it and give some benchmark
> tests if you want.
>
>
> Another thing is that the multiqueue in wireless do implement a
> priority queue (that's what I understand). So we need to have somewhere
> option which sets this priority somewhere. [1]
>
> mac802154 do that for different types of content in the payload like
> video or audio streaming. They have some priority enums defined at [2].
> Every queue has then a own priority.
>
> You see that with multiqueue inside mac80211 they want to improve
> different payload content like video which is a use case of the 802.11
> standard. For example streaming videos with 802.15.4, you can forget that.
> But then we have other things like "low energy".
>
> This is why there is no general "IoT" wireless standard outside, each have
> their benefit depends on your use case. If you want to stream videos and call
> it "IoT - Application" then 802.15.4 is not what you want. I did a fast
> googling and found [3], you see different wireless standards compared with 
> Range and data rate.
>
>
> To detect a priority for _maybe_ implement such multiqueue handling in
> 802.15.4 then this could be dine by set it in some sockopt of 802.15.4 sockets
> or grab it from DCSP field of IPv6 header, like wireless it also does [1] - 
> "DSCP (RFC 2474):" for 6LoWPAN then. But general this would be a benefit if you
> have a lot of other _lower_ priority traffic.
>
>
>
> It also could be that a wireless driver/transceiver can support
> put frame in "transceiver queue" when current one is transmitted at the moment.
> I don't know if something exists at the moment, the at86rf2xx have only
> one frame buffer which cannot be overwritten while transmit (or can but
> then it need to handle real time, I think we can't never support that
> inside linux).
>
>
>
>
> Now note about patch ("mac80211: use per-CPU TX/RX statistics")
> 084d8536fc4f1581f975c1a5fcacd4384555bdcf:
>
> First I don't apply something like that if we doesn't have multiqueue tx queue
> (if it really increase perfomance), because this patch fix something
> which only happen in multiqueue tx queue handling.
>
> Second: This patch is because there is an issue about increment the tx
> stats on netdev while using multiqueue. So far I understand this is
> because the incrementation is not an atomic operation, so this patch to
> a per cpu operation to be sure that this operation "to increment the tx
> stats" can be run on one cpu. So before this patch mulitple queues was
> running and increment these values at the same time which result in some
> inconsistent behaviour.
>
>
>> If you agree include this, patch is on the way.. 
>>
> no. In short:
>
> 1. We don't have multple tx queues (and I don't think that we can get
>    much benefits from it).
>
> 2. The patch ("mac80211: use per-CPU TX/RX statistics")
>    084d8536fc4f1581f975c1a5fcacd4384555bdcf solved an issue when multiple
>    queues increments the counter on multicore architecture. We don't have
>    this issue because we have only one queue which we stop and wake before
>    transmit and while tx completion. The incrementation is protected by
>    this handling.
>
>
> You should provide patches for an useful case of multiple tx queues with
> benchmark results. Then we need to care about "locking", this is what
> your wireless patch fix does.
>
> - Alex
>
> [0] http://www.ieee802.org/15/pub/TG4.html
> [1] https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/queues
> [2] http://lxr.free-electrons.com/source/include/net/mac80211.h#L102
> [3] http://blogs.freescale.com/wp-content/uploads/2014/11/post-10893-image-4-todays-wireless-landscape.jpg
> [4] 

Agree with you.

Thank you for your explanation.

-- 
Varka Bhadram