netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: netdev@vger.kernel.org, linux-wpan@vger.kernel.org
Cc: Alexander Aring <aar@pengutronix.de>
Subject: Re: drop all fragments inside tx queue if one gets dropped
Date: Wed, 20 Apr 2016 16:15:34 -0400	[thread overview]
Message-ID: <11312.1461183334@obiwan.sandelman.ca> (raw)
In-Reply-To: <57175156.3050501@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]


{adding some more comments from the -wpan side of things}

Alexander Aring <aar@pengutronix.de> wrote:
    > On linux-wpan we had a discussion about setting the right tx_queue_len
    > and came to some issues in 802.15.4 6LoWPAN networks.

...

    > And then a lot of fragments laying inside the tx_queue and waits to
    > transfer to the transceiver which has only one framebuffer to transmit
    > one frame and waits for tx completion to transfer the next one.

    > My question is, if qdisc drops some fragment because the queue is full
    > or something else. Exists there some way to remove all fragments inside
    > the queue? If one fragment will be dropped and all related are still
    > inside the queue then we send mostly garbage.

The big concern is that if we make tx_queue_len too big, we are effectively
introducing bloat.
If we make it too small, then we might drop one fragment, when we would
prefer to drop the entire packet.

It seems that maybe we ought to have a queue in the upper interface and fill
the lower interface with at most two packets' worth of fragments.

    > I want to add a behaviour which drops all related fragments for 6LoWPAN
    > fragmentation at first, if the payload is above 1280 bytes, then we
    > have also IPv6 fragmentation on it. In future I also like to remove all
    > related 6LoWPAN fragments which are related according to the IPv6
    > fragment.

It would still be useful to be able to do this in general: this kind of
operation would also benefit sending large UDP packets over ethernet when we
have to do IP-layer fragmentation.

  reply	other threads:[~2016-04-20 20:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20  9:52 drop all fragments inside tx queue if one gets dropped Alexander Aring
2016-04-20 20:15 ` Michael Richardson [this message]
2016-04-20 20:45   ` Rick Jones
2016-04-21 17:48     ` Michael Richardson

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=11312.1461183334@obiwan.sandelman.ca \
    --to=mcr@sandelman.ca \
    --cc=aar@pengutronix.de \
    --cc=linux-wpan@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).