Re: Simplifying the 802.15.4 stack

On Tue, 11 Mar 2014 16:30:12 +0400
Dmitry Eremin-Solenikov [off-list ref] wrote:

Helo,

[…]

quoted

Differentiating between different roles of a device with different
types of interfaces is a sensible idea. I'm not actually opposed to
that, quite the contrary - I am mainly interested in a working and
semantically correct system.

As far as 802.15.4 is concerned, I do want to be able to support
all kinds of devices that make sense. It is not sensible though to
add a monitor device on a PHY that is already running a WPAN if
that PHY does not support concurrent monitors, so that should not
be allowed for 802.15.4 just as it is not allowed for 802.11. For
why I think it is not sensible to allow multiple 802.15.4 slave
devices on one PHY, see below.

If you wish to disallow multiple 802.15.4 devices on a single phy,
just do it.

However before removing the rest of the phy/device API, please,
Please, PLEASE, go and consult the 802.11 separation in Linux kernel.
This largest part of slave support code was modeled after 802.11
stack. This is not about the roles of the device - it is about the
multiple roles being attached to the device.
For example monitor mode would be hard to support on plain 802.15.4 -
one can expect that mac802.15.4 will change the skb. Especially after
adding security/encryption. Monitor (wireshark/whatever) must receive
skbs before all the rest of the handlers. It is not directly possible
with other architectures.

Removing the rest of the phy/device API is not my intention. The
separation between PHY and device was something I never wanted to
remove, though I did want to remove the ability to add multiple
devices/slaves to the same PHY. You've convinced me that that's a
really bad idea, but you've also convinced me that another kind of
restriction would be well in order: allow an arbitrary number of
low-level monitor devices, if the PHY supports that functionality, and
exactly one protocol implementation. For 802.15.4 WPAN, I think that
implementation should restrict itself to one netdev and an additional
list of slave roles as necessary, e.g. coordinator functions that are
only accessible through netlink.

[…]

quoted

Those are interesting protocols to support with the current PHY
infrastructure, yes. MiWi might benefit greatly from sharing code
with mac802154, so there is reason to keep that code reasonably
generic if anyone ever wanted to implement WiMi, the same holds for
VLC.

All of those protocols may very well share the PHY and parts of the
code with regular 802.15.4, but 802.15.4 and these protocols are
all in some way incompatible with each other. For what I can tell,
SMAC uses the first two bytes of a frame as data, where 802.15.4
expects a frame control word, so those cannot work together on the
same PHY without interfering with each other. MiWi, as an extended
subset of 802.15.4, probably also cannot coexist with 802.15.4 or
SMAC on the same PHY. Two protocols can only reliably coexist if
they were explicitly designed to do that, but I couldn't confirm
that what you listed was designed to.

This is up to the protocol and application to decide, whether it can
parse packets or it can ignore them. Compare this to having IPv4,
IPv6, IPX and SMB (NetBEUI or whatever that was called) packets on
top of a wire. It is up to the protocol to decide, whether it can
parse the packet and whether the packet looks good enough to be passed
to upper layers.

Usually, link layers support some kind of upper layer protocol type
indicator. Ethernet has the ethertype field, for example, so which
protocol payload a packet contains is described by the packet itself. On
802.15.4 PHYs, we don't usually have that - SMAC is just a pipe into
the air, 802.15.4 WPAN supports no protocol indication, and MiWi or
others probably do not either. As such, which protocol should be used
to process is a packet is not a property of the packet, but a property
of the network the PHY is in - barring interferers on the same channel
that send other things. On 802.15.4 WPANs, those interferers can be
easily ignored by switching to a different PAN and ignoring broadcast
frames from other PANs, but other protocols might not make this as easy.

Say, you have an SMAC device and a 802.15.4 WPAN on the same PHY, and
two machines with this setup. One machine sends an SMAC frame that just
so happens to look like an 802.15.4 WPAN dissasociation request, and
the other machine's 802.15.4 WPAN implementation might happily process
it as such even though it was never meant to. We could of course tell
SMAC to "just don't do that", but then that's not really SMAC anymore
and also not what an SMAC user would expect.

Our situation here, I think, is much more akin to an RS485 network or
similar networks that provide only raw, unadulterated bytestream
transport. For SMAC certainly, 802.15.4 WPAN does impose some
restrictions on this with the PAN concept and explicit non-broadcast
frames to separate different entities, but the protocol contained in a
frame taken from the PHY is still very much dependent on the network
itself. It will continue to be hard to have multiple protocols on the
same channel even with the restriction to one protocol implementation
per PHY, but that's already hard to impossible now - all depending on
the other protocols present on the channel.

quoted

So yes, it is sensible to allow different protocols on top of the
PHY, but not two different protocols at once, and also not two
different instances of the same protocol that interfere with each
other - which, for the transceivers that have drivers in the kernel
now, are any two instances at all. The transceivers we support are
designed by their manufacturers to be as cheap as possible while
still allowing a full implementation of an 802.15.4 stack, which
notable does not include a requirement for one device to be
accessible in different specific WPANs at once.

And this is to the driver to decide. I don't remember, which got to
the kernel. My original code allowed the upper layers and protocol to
agree on what is allowed and what is not. It is the driver, who knows
what is currently enabled (address filtering, auto-ack, promisc,
etc). Mac802.15.4 should not impose additional restrictions on top of
that.

Yes, but it also shouldn't allow two slaves on the same PHY with
differing views of reality. In the best case, one slave will not be
serviced as expected, in the worst case, none of the slaves will be
serviced at all.

quoted

If the stated goal of mac802154 is to support anything that uses a
802.15.4 PHY, or a similar PHY, then maybe the stack should renamed
to reflect that. Or it could be split into mac80215x and
ieee802154, smac, miwi ... A basic stack for just the PHY functions
and one stack for each protocol, where those stack could of course
share code where appropriate. Since nothing has made a move for
mainline since the 802.15.4 PHY infrastructure was added, I do
believe that this complexity is not warranted at the moment. That
might change when those protocols wish to go mainline, but right
now the implementation in the kernel is an 802.15.4 stack, and the
assumption that it is a pure 802.15.4 stack is also present in the
PHY drivers. In my opinion, we should stick to what we know -
802.15.4 - until the need to diversify arises.

PHY does/should not depend on having only 802.15.4. Monitoring and
SMAC worked w/o any issues. In fact this was the original cause for
reduced and full MLME ops, not that RFD/FFD crap, that is currently
written in the comment in ieee802154_netdev.h file.

It does not, that's correct, but activating even one 802.15.4 WPAN on a
PHY that supports address filtering will effectively lock out
everything else on the same PHY, including SMAC. Letting the PHY
perform only the lowest common denominator of all that is requested by
slaves will also not work, because we cannot possibly implement even
the ACK mechanism of 802.15.4 WPAN in the current stack without PHY
support. That's not only because we use workqueues for RX, but also
because some commonly SPI drivers use workqueues for their internals.
On a 100kbps OQPSK network, we have 12 symbol periods before an ACK for
a frame has to be sent, or about 0.5 milliseconds. Including the SPI
transfers required, there's just no way to keep that deadline.

quoted

As explained above, I am not opposed to the separation into PHY
devices and netdevs. The current mode of seperation is at odds with
what can be implemented in reality without breaking at least one
assumption of the netdev model though, so I think we should rethink
at least the mode of separation - the separation itself is a
sensible thing.

I'm open to any real suggestions. But please check the 80211 kernel
code first.

 * split the slave list into a list of monitors and a protocol impl
 * have each protocol that wants to run on the phy provide a protocol
   impl, akin to packet_type mechanism of the netdev stack
 * protocol impls are free to do whatever they wish. For 802.15.4 WPAN,
   I'd wish the protocol impl to allow only one netdev and some set of
   other roles, as outlined above. That'd be one active slave that acts
   as a network device, and a number of other slaves that don't - but
   still process and transmit packets.

[…]

First, just to make sure that you understand it. 'a TX operation
writes a frame to the device frame buffer, changes state, checks that
the state change has succeeded'.
This part already includes sleeping a lot. One can change the drivers
code to do all the job on asynchronous callbacks or in the special
driver-local worker. But you still face the issue. Again, send the
patches on how to improve the situation.

I would differentiate between sleeping (telling the scheduler to
ignore the current thread until some condition holds) and waiting
(telling an actor to provide asynchronous indication of completion).
The underlying actor may of course sleep, as some SPI drivers do, but
that doesn't force any other user to sleep as well.

Once I have some patches to show what I mean, I'll submit them. There
are other things I have to take of first, though, so this might not
happen for another few weeks.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel