From: Simon Wunderlich <sw@simonwunderlich.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Cc: "B.A.T.M.A.N" <b.a.t.m.a.n@lists.open-mesh.net>
Subject: Re: [B.A.T.M.A.N.] skb->priority and fragments
Date: Wed, 13 Apr 2016 13:11:12 +0200 [thread overview]
Message-ID: <2242031.raF8ugmCc9@prime> (raw)
In-Reply-To: <20160412204259.GK29895@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
Hi Andrew,
On Tuesday 12 April 2016 22:42:59 Andrew Lunn wrote:
> Hi Folks
>
> Does anybody remember the history for the follow and can explain why
> the code is as it is?
>
> The soft interface transmit function, batadv_interface_tx() calls
> batadv_skb_set_priority(skb, 0) to set the skb->priority based on the
> TOS bits or 801.p.
>
> If the packet needs to be fragmented because of MTU issues,
> batadv_frag_create() is used to create the fragments. It overwrites
> the skb->priority in the original skb to TC_PRIO_CONTROL, and leaves
> the fragment skb with the default priority.
>
> This seems a bit odd to me. I would of expected the priority to of
> been copied from the original into the fragment.
I think this part could be improved. Right now, if I remember correctly, we
set TC_PRIO_CONTROL by default and set another priority if we can parse the
header (batadv_skb_set_priority()).
There are two cases:
1.) On the original sender, both fragments could adopt the priority as you
suggest. The code probably doesn't take care of that yet, so that could be
fixed.
2.) On routers on the way, the priority could only be set based on the first
fragment, since the second fragment will not have a valid header to parse. And
unless we remember the priority from the first fragment, we have no way to
know to which priority we should set the second fragment.
I believe case 1 can be fixed easily, for case 2 I don't have an idea right
now. :)
Cheers,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-04-13 11:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 20:42 [B.A.T.M.A.N.] skb->priority and fragments Andrew Lunn
2016-04-13 11:11 ` Simon Wunderlich [this message]
2016-04-13 12:14 ` Andrew Lunn
2016-04-13 12:19 ` Simon Wunderlich
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=2242031.raF8ugmCc9@prime \
--to=sw@simonwunderlich.de \
--cc=b.a.t.m.a.n@lists.open-mesh.net \
--cc=b.a.t.m.a.n@lists.open-mesh.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