All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Aring <alex.aring@gmail.com>
To: Peter Kietzmann <peter.kietzmann@haw-hamburg.de>
Cc: Michael Richardson <mcr@sandelman.ca>, linux-wpan@vger.kernel.org
Subject: Re: UDP stress-testing
Date: Thu, 14 Apr 2016 16:59:27 +0200	[thread overview]
Message-ID: <20160414145921.GA6196@omega> (raw)
In-Reply-To: <570F5A6E.3010009@haw-hamburg.de>

Hi,

On Thu, Apr 14, 2016 at 10:53:02AM +0200, Peter Kietzmann wrote:
> Hi,
> 
> thanks for giving this topic some informational background! As it was me
> triggering that discussion, I just wanted to give my linux-network-newie
> opinion back to you.
> 
> IMO "avoiding invalid fragments" has higher priority than "avoiding latency"
> for the reason that dropping one fragment means dropping all fragments of an
> IPv6 packet. Processing 1280B IPv6 packets leads to 14 6LoWPAN fragments
> which we'd have processed for nothing when dropping one of them fragments.
> Therefore I like Alex's proposal about queuing 6Lowpan fragments and
> checking space in the actual xmit queue. However, I currently don't know
> much about IPv6 fragmentation but probably one thing to be careful about is
> interaction between 6lo and IPv6 fragmentation and possible amplification
> effects which could affect the needed txqueue size.
> 

I think for dealing with the fragments right inside the queue we need to
use "skb_shinfo(skb)->frag_list".

A kfree_skb will then care about for releasing all other skb's which are
use for the fragment and I hope this will deal with every others skb's
which are inside the tx queue.
I need to dig more into that if using frag_list really fix this issue.

In case of IPv6 fragmentation for the wpan interface queue (lowpan
interface doesn't have any tx queue, dev_queue_xmit will direct call xmit
of lowpan interface) it's another issue and not easy because we have a
fragmentation (IPv6) over fragmentation(6LoWPAN) there and notify dropped
fragments from wpan-interface to the correct ipv6 fragments (in case of
ipv6 fragmentation) sounds more complicated.

I would try to fix at first the fragmentation for 6LoWPAN fragmentation,
which is more likely than doing IPv6 fragmentation over 6LoWPAN.

- Alex

      reply	other threads:[~2016-04-14 14:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-07 20:19 UDP stress-testing Peter Kietzmann
2016-04-07 20:41 ` Alexander Aring
2016-04-08  7:22   ` Peter Kietzmann
2016-04-08 12:58     ` Alexander Aring
2016-04-13  0:00     ` Michael Richardson
2016-04-13  8:28       ` Alexander Aring
2016-04-13 12:50         ` Michael Richardson
2016-04-13 20:34           ` Alexander Aring
2016-04-14  8:53             ` Peter Kietzmann
2016-04-14 14:59               ` Alexander Aring [this message]

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=20160414145921.GA6196@omega \
    --to=alex.aring@gmail.com \
    --cc=linux-wpan@vger.kernel.org \
    --cc=mcr@sandelman.ca \
    --cc=peter.kietzmann@haw-hamburg.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.