From: Alan Ott <alan@signal11•us>
To: Alexander Smirnov <alex.bluesman.smirnov@gmail•com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail•com>,
"David S. Miller" <davem@davemloft•net>,
linux-zigbee-devel <linux-zigbee-devel@lists•sourceforge.net>,
netdev@vger•kernel.org, linux-kernel@vger•kernel.org
Subject: Re: [PATCH 1/6] mac802154: Immediately retry sending failed packets
Date: Tue, 02 Apr 2013 17:28:25 -0400 [thread overview]
Message-ID: <515B4D79.40805@signal11.us> (raw)
In-Reply-To: <515B3F78.2020301@signal11.us>
On 04/02/2013 04:28 PM, Alan Ott wrote:
> On 04/02/2013 03:11 PM, Alexander Smirnov wrote:
>> 2013/4/2 Alan Ott <alan@signal11•us <mailto:alan@signal11•us>>
>>
>> When ops->xmit() fails, immediately retry. Previously the packet was
>> sent
>> to the back of the workqueue.
>>
>> Signed-off-by: Alan Ott <alan@signal11•us <mailto:alan@signal11•us>>
>> ---
>> net/mac802154/tx.c | 17 ++++++++---------
>> 1 file changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
>> index 4e09d07..fbf937c 100644
>> --- a/net/mac802154/tx.c
>> +++ b/net/mac802154/tx.c
>> @@ -59,19 +59,18 @@ static void mac802154_xmit_worker(struct
>> work_struct *work)
>> }
>> }
>>
>> - res = xw->priv->ops->xmit(&xw->priv->hw, xw->skb);
>> + do {
>> + res = xw->priv->ops->xmit(&xw->priv->hw, xw->skb);
>> + if (res && ++xw->xmit_attempts >=
>> MAC802154_MAX_XMIT_ATTEMPTS) {
>> + pr_debug("transmission failed for %d times",
>> + MAC802154_MAX_XMIT_ATTEMPTS);
>> + break;
>> + }
>> + } while (res);
>>
>>
>>
>> IIRC this 802.15.4 stack uses single-thread-work-queue and all RX/TX
>> are performed by using it.
> Hi Alexander,
>
> Yes, that is true. As is currently implemented, the driver xmit()
> functions are called from a workqueue and block until the packet is sent.
>
>
>> Doing TX retry in the way you proposed -
>> it's possible that you will block other packets pending in this
>> queue.
> Yes. Since sending data is a blocking operation, any time spent sending
> (or re-sending) is blocking.
>
> As it was before this patch series, with the buffer (workqueue) growing
> arbitrarily large, doing retry by putting a packet at the end of the
> workqueue was largely useless because by the time it came to retry it,
> any state associated with it (with respect to fragmentation/reassembly)
> had expired.
>
> Keep in mind that with the netif stop/wake code, putting retries at the
> end of the workqueue or doing them immediately is basically the same
> thing, since the workqueue is no longer the packet queue (and will
> ideally only have 0 or 1 packets in it). The workqueue (with these
> patches) only serves to lift the driver xmit() calls out of atomic
> context, allowing them to block.
>
> However, it is easy to envision one process clogging up the works with
> retries by sending many packets to an unavailable address.
>
> What do you recommend doing here instead?
According to 7.5.6.5 of IEEE 802.15.4-2003, if the retransmission fails
more than aMaxFrameRetries (3) times, it is assumed that it has failed.
Since some transceivers (and I would assume most if not all) do this in
hardware, it's now my opinion that we should _not_ try to retransmit at
all in mac802154/tx.c.
For a driver for a device which _doesn't_ do retransmission in hardware,
maybe it should be handled by that driver then.
>
>> Despite on Linux is already 'slow' system to provide
>> real-time for specific 802.15.4 features, I think it's not a good
>> idea to increase nodes communication latency.
> With the transmit buffer length increased (and actually being used),
> maybe the packets with realtime requirements can be given a higher
> priority to deal with these requirements.
>
> Alan.
>
>>
>> out:
>> mutex_unlock(&xw->priv->phy->pib_lock);
>>
>> - if (res) {
>> - if (xw->xmit_attempts++ < MAC802154_MAX_XMIT_ATTEMPTS) {
>> - queue_work(xw->priv->dev_workqueue, &xw->work);
>> - return;
>> - } else
>> - pr_debug("transmission failed for %d times",
>> - MAC802154_MAX_XMIT_ATTEMPTS);
>> - }
>>
>> dev_kfree_skb(xw->skb);
>>
>> --
>> 1.7.11.2
>>
>>
next prev parent reply other threads:[~2013-04-02 21:28 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 18:47 [PATCH 0/6] 802.15.4 and 6LoWPAN Buffering Fixes Alan Ott
[not found] ` <1364928481-1813-1-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
2013-04-02 18:47 ` [PATCH 1/6] mac802154: Immediately retry sending failed packets Alan Ott
[not found] ` <1364928481-1813-2-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
2013-04-02 19:11 ` Alexander Smirnov
[not found] ` <CAJmB2rCr5ds11+iN=W5GCKsUgdfb57uKg+mH4NY4CWw6EFCTbg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-02 20:28 ` Alan Ott
2013-04-02 21:28 ` Alan Ott [this message]
[not found] ` <515B4D79.40805-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
2013-04-02 22:35 ` Alan Ott
2013-04-02 23:13 ` Werner Almesberger
2013-04-03 1:24 ` Alan Ott
2013-04-03 1:56 ` [Linux-zigbee-devel] " David Miller
[not found] ` <20130402.215625.1555279506975246223.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2013-04-03 1:59 ` Alan Ott
[not found] ` <515B8D09.9050304-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
2013-04-03 2:03 ` David Miller
[not found] ` <20130402.220315.1782012687105065631.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2013-04-03 2:25 ` Alan Ott
[not found] ` <515B9318.8090101-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
2013-04-03 2:30 ` David Miller
2013-04-03 2:57 ` [Linux-zigbee-devel] " Alan Ott
2013-04-03 2:38 ` Werner Almesberger
2013-04-02 18:47 ` [PATCH 2/6] mac802154: Move xmit_attemps to stack Alan Ott
2013-04-02 18:47 ` [PATCH 3/6] mac802154: Use netif flow control Alan Ott
2013-04-02 21:21 ` Sergei Shtylyov
2013-04-02 18:47 ` [PATCH 4/6] mac802154: Increase tx_buffer_len Alan Ott
2013-04-02 18:48 ` [PATCH 5/6] 6lowpan: handle dev_queue_xmit error code properly Alan Ott
[not found] ` <1364928481-1813-6-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
2013-04-02 19:21 ` Alexander Smirnov
[not found] ` <CAJmB2rB+9-gLV=SVvr4JUc2swjmTaWxD0gYM5VLw8PL1d455JA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-02 19:30 ` Alan Ott
2013-04-02 18:48 ` [PATCH 6/6] 6lowpan: return the dev_queue_xmit() return value from lowpan_xmit() Alan Ott
[not found] ` <1364928481-1813-7-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
2013-04-02 19:27 ` Alexander Smirnov
2013-04-03 14:00 ` [PATCH v2 0/4] 802.15.4 and 6LoWPAN Buffering Fixes Alan Ott
2013-04-03 14:00 ` [PATCH v2 1/4] mac802154: Do not try to resend failed packets Alan Ott
[not found] ` <1364997658-16498-1-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
2013-04-03 14:00 ` [PATCH v2 2/4] mac802154: Use netif flow control Alan Ott
2013-04-03 14:00 ` [PATCH v2 3/4] mac802154: Increase tx_buffer_len Alan Ott
2013-04-03 14:00 ` [PATCH v2 4/4] 6lowpan: handle dev_queue_xmit() error code properly Alan Ott
2013-04-07 21:06 ` [PATCH v2 0/4] 802.15.4 and 6LoWPAN Buffering Fixes David Miller
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=515B4D79.40805@signal11.us \
--to=alan@signal11$(echo .)us \
--cc=alex.bluesman.smirnov@gmail$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dbaryshkov@gmail$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-zigbee-devel@lists$(echo .)sourceforge.net \
--cc=netdev@vger$(echo .)kernel.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