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

[Alexander Aring <alex.aring@gmail.com>]

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]