From: Alan Ott <alan@signal11•us>
To: Alexander Smirnov <alex.bluesman.smirnov@gmail•com>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail•com>,
slapin@ossfans•org, Tony Cheneau <tony.cheneau@amnesiak•org>
Cc: linux-zigbee-devel@lists•sourceforge.net, netdev@vger•kernel.org,
Eric Dumazet <eric.dumazet@gmail•com>
Subject: Re: RFC: mac802154 Packet Queueing and Slave Devices
Date: Thu, 21 Mar 2013 12:09:32 -0400 [thread overview]
Message-ID: <514B30BC.4040802@signal11.us> (raw)
In-Reply-To: <504D37A7.60109@signal11.us>
On 09/09/2012 08:43 PM, Alan Ott wrote:
> Tony and I were recently talking about packet queueing on 802.15.4. What
> currently happens (in net/mac802154/tx.c) is that each tx packet (skb)
> is stuck on a work queue, and the worker function then sends each packet
> to the hardware driver in order.
>
> The problem with this is that it defeats the netif flow control. The
> networking layer thinks the packet is sent as soon as it's put on the
> workqueue (because the function that queues it returns NETDEV_TX_OK to
> the networking layer), and the workqueue can then get arbitrarily large
> if an application tries to send a lot of data. (Tony has shown this with
> iperf)
>
So I tried fixing this using netif_stop_queue() and netif_wake_queue(),
the standard way. The flow control works, but I'm now losing packets.
It happens like this:
ipv6 -> 6lowpan -> net core -> mac802154 -> hardware
single packet fragment netif_stop_queue()
fragment
fragment
fragment
Above: a single ipv6 packet is split into fragments by 6lowpan. Each
fragment is sent through the networking core where it ends up in
mac802154, which will call netif_stop_queue() and netif_wake_queue()
for flow control as packets are sent.
The problem is that since many ieee802154 hardware devices can only hold
one packet at a time in their tx buffer, netif_stop_queue() gets called
after the first fragment. Since the 6lowpan code is trying to, in the
above case, send 4 packets, the remaining 3 will get dropped when
they're handed to the networking core (dev_queue_xmit()) when the queue
is stopped.
So as a solution, one could envision 6lowpan putting the fragments into
a queue, and submitting one at a time, as the queue gets woken. The
problem with this is that there's no way to get notification for when a
queue is woken. I checked both ppp and ax25 (which would seem to have
this same issue), and they both have a fragment queue, but they rely on
external events (mostly unrelated to the queue being woken) to trigger
sending packets from the queue (see calls to ax25_kick()). That seems
hacky at best.
A thread from pppoe[1] talks about what's a similar issue. The patch
from that email was never merged. Even so, their solution seems a bit
hacky too (because it would basically cause a kick to (in this case)
6lowpan, whenever an skb gets destroyed (ie: after it's sent). With the
desire for 6lowpan to be a generic protocol[2], one would want it to be
efficient on MAC layers which do support longer queues[3].
What am I missing here? What's the right way to do this?
Alan.
[1] http://thread.gmane.org/gmane.linux.network/233089
[2] There has been some discussion about using 6lowpan on Bluetooth
low-energy.
[3] There's also the case where 2 6lowpan instances are on attached to
the same hardware, or where 6lowpan and raw are being used concurrently.
next prev parent reply other threads:[~2013-03-21 16:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-10 0:43 RFC: mac802154 Packet Queueing and Slave Devices Alan Ott
[not found] ` <504D37A7.60109-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
2012-09-10 6:12 ` Eric Dumazet
2012-09-11 3:00 ` Alan Ott
2012-11-30 1:55 ` [PATCH] 6lowpan: consider checksum bytes in fragmentation threshold Alan Ott
2012-11-30 1:58 ` Alan Ott
2012-11-30 17:19 ` David Miller
2012-11-30 4:25 ` [PATCH 1/2] mac802154: fix memory leaks Alan Ott
2012-11-30 4:25 ` [PATCH 2/2] mac802154: use kfree_skb() instead of dev_kfree_skb() Alan Ott
2012-11-30 17:19 ` David Miller
2012-11-30 17:19 ` [PATCH 1/2] mac802154: fix memory leaks David Miller
2013-03-21 16:09 ` Alan Ott [this message]
2013-03-22 5:33 ` RFC: mac802154 Packet Queueing and Slave Devices Alan Ott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=514B30BC.4040802@signal11.us \
--to=alan@signal11$(echo .)us \
--cc=alex.bluesman.smirnov@gmail$(echo .)com \
--cc=dbaryshkov@gmail$(echo .)com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=linux-zigbee-devel@lists$(echo .)sourceforge.net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=slapin@ossfans$(echo .)org \
--cc=tony.cheneau@amnesiak$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox