Hello.
On 04/08/15 20:42, Alexander Aring wrote:
On Tue, Aug 04, 2015 at 06:28:56PM +0200, Stefan Schmidt wrote:
Hello.
On 30/07/15 10:55, Alexander Aring wrote:
Hi,
this patch series contains a RFC for changing the max_frame_retries behaviour.
The current behaviour is that we allow a range from -1 until 7 (802.15.4
standard describes a range from 0 until 7 only). Nevertheless for historical
reason we have the "-1" value, which describes no aret handling.
The point is when the ack request bit is set inside the mac header the
transceiver need to handle the ack somehow, this is mostly the aret mode
which is done by hardware. Instead to having this as mac setting which doesn't
allow a change during interface up, we simple do this handling per frame
indicated by the ack request bit.
I think it is sound to handle it per frame to give us the opportunity to
change this setting without taking the interface down. I wonder about the
frame retry counter which needs to be written in some transceiver register
to be used by the hardware directly. That one can only be done when the
interface is down. Whcih means we can decide if we want ARET handling per
frame but not how often the retry happens. Do I miss something?
yes, turning into ARET mode (which use the max_frame_retries setting) or
NOT ARET mode (I always call this normal TX mode, which don't use the
max_frame_retries value) is now per frame. It depends on ackreq bit is
set or not, because this bit occurs - when the frame is transmitted the
receiving node will send a ack frame back then.
The number "how often the retry is inside ARET mode, if no ack was received"
can be set by interface down only. I already thought about to remove the
check "netif_running" (we probably can do that later). The point where I
am feeling bad is, this is some mac operation which is done by hardware.
We have with mac802154 normally the SoftMAC implementation for doing MAC
layer on linux side, but for ARET handling we can't because these timing
restrictions. In linux when a phy have a running interface means that
the mac802154 is operational and the phy do receive/transmit handling.
Now I can say what happens when e.g. at86rf2xx transceiver is in
TX_ARET_BUSY mode (means something is currently transmitted in ARET mode).
While in this state the transceiver changes his mac value
"max_frame_retries" to some other value. What happens then? I don't
know, the datasheet doesn't say anything how this is protected while
transmit handling. Maybe it isn't protected.
So we have the two arguments for allow/deny transceiver mac settings
while interface up:
Argument to allow:
- The transceiver will handle the change while transmit "somehow".
Argument to deny:
- We simple don't allow change mac settings which are handled by
transceiver while mac is "operational" -> interface is up.
Currently we have the option where we deny to change these mib values
while mac is operational.
We should keep it as is for now. Only changing mac setting while the
interface is down.
I was just curious.
It could be that we need to re-think it later for some settings (like
the retry counter) but there is no need now and we would to more testing
to see how the transceiver are behaving with this.
I also don't think that there exists much use
case for doing a "complex" locking mechanism to allow the change while
interface is up. And this will huge complex with multiple interface
support and such things. Easiest way -> setup mib values which are
handled by transceiver on interface up and don't allow changes during
mac operational.
That's why I do different handling for mib values and pib values.
For phy settings (pib) CCA/channel/page we allow to change these values
during interface up. These values should not having much todo with the
mac layer. Probably we can argument with the same argument what happens
while TX_ARET_BUSY and different channel setting? I also don't know what
happens then. :-) But the point is that the linux side doesn't do any
phy layer things, for MAC we have mac802154 and the transceiver mac
operations (ARET/CSMA/etc...).
Instead of max_frame_retries "-1" value which could be useful for making a
default ack request bit handling if no information is given if it should be
set or not, we have now the ack request default entry inside the mib.
This could be useful for the 6LoWPAN stack which have this as default
behaviour for data frames.
You have the wpan-tools bits for the new netlink command pushed somewhere to
test out with this patchset?
Yes, I have it. Will send them later. Also I want to include for "next
nl802154 feature" the CONFIG_NL802154_EXPERIMENTAL, but I don't think we
should introduce it for this patch series. Because we change the
behaviour of max_frame_retries -1 to the ackreq bit. We will introduce
them later then (maybe for llsec).
I think this is a small enough addition that we do not need the
CONFIG_NL802154_EXPERIMENTAL guard for it yet.
Should we name it ackreq_default or ackreq_fallback?
I would go with ackreq_default.
regards
Stefan Schmidt
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
