Message-ID: <20140312163103.1d413b86@zoidberg>
Date:	Wed, 12 Mar 2014 16:31:03 +0100
From:	Phoebe Buckheister <phoebe.buckheister@...m.fraunhofer.de>
To:	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	linux-zigbee-devel <linux-zigbee-devel@...ts.sourceforge.net>
Subject: Re: [Linux-zigbee-devel] Simplifying the 802.15.4 stack

On Tue, 11 Mar 2014 16:30:12 +0400
Dmitry Eremin-Solenikov <dbaryshkov@...il.com> wrote:

> Helo,
[…]
> > 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.

[…]
> > 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.

> > 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.

> > 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.

> > 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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists