From: Petr Machata <petrm@mellanox.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: Petr Machata <pmachata@gmail.com>,
netdev@vger.kernel.org, Ido Schimmel <idosch@mellanox.com>,
"David S . Miller" <davem@davemloft.net>,
Peter Dawson <petedaws@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH net] selftests: forwarding: vxlan_bridge_1d: fix tos value
Date: Mon, 17 Feb 2020 11:40:13 +0100 [thread overview]
Message-ID: <87r1ytpkdu.fsf@mellanox.com> (raw)
In-Reply-To: <20200217025904.GP2159@dhcp-12-139.nay.redhat.com>
Hangbin Liu <liuhangbin@gmail.com> writes:
> On Fri, Feb 14, 2020 at 11:54:09AM +0100, Petr Machata wrote:
>> >> > After commit 71130f29979c ("vxlan: fix tos value before xmit") we start
>> >> > strict vxlan xmit tos value by RT_TOS(), which limits the tos value less
>> >>
>> >> I don't understand how it is OK to slice the TOS field like this. It
>> >> could contain a DSCP value, which will be mangled.
>> >
>> > Thanks for this remind. I re-checked the tos definition and found a summary
>> > from Peter Dawson[1].
>> >
>> > IPv4/6 Header:0 |0 1 2 3 |0 1 2 3 |0 1 2 3 |0 1 2 3 |
>> > RFC2460(IPv6) |Version | Traffic Class | |
>> > RFC2474(IPv6) |Version | DSCP |ECN| |
>> > RFC2474(IPv4) |Version | IHL | DSCP |ECN|
>> > RFC1349(IPv4) |Version | IHL | PREC | TOS |X|
>> > RFC791 (IPv4) |Version | IHL | TOS |
>> >
>> > According to this I think our current IPTOS_TOS_MASK should be updated to 0xFC
>> > based on RFC2474. But I'm not sure if there will have compatibility issue.
>> > What do you think?
>>
>> Looking at the various uses of RT_TOS, it looks like they tend to be
>> used in tunneling and routing code. I think that in both cases it makes
>> sense to convert to 0xfc. But I'm not ready to vouch for this :)
>
> Yes, I also could not... Maybe David or Daniel could help give some comments?
>
>>
>> What is the problem that commit 71130f29979c aims to solve? It's not
>> clear to me from the commit message. What issues arise if the TOS is
>> copied as is?
>
> As the commit said, we should not use config tos directly. We should remove
> the precedence field based on RFC1349 or ENC field based on RFC2474.
Well, RFC1349 didn't know about DSCP. I do not think it is possible to
conform to both RFC1349 and RFC2474 at the same time.
RFC2474 states that "DS field [...] is intended to supersede the
existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic
Class octet [IPv6]". So the field should be assumed to contain DSCP from
that point on. In my opinion, that makes commit 71130f29979c incorrect.
(And other similar uses of RT_TOS in other tunneling devices likewise.)
next prev parent reply other threads:[~2020-02-17 10:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 9:40 [PATCH net] selftests: forwarding: vxlan_bridge_1d: fix tos value Hangbin Liu
2020-02-13 12:52 ` Petr Machata
2020-02-14 2:53 ` Hangbin Liu
2020-02-14 10:54 ` Petr Machata
2020-02-17 2:59 ` Hangbin Liu
2020-02-17 10:40 ` Petr Machata [this message]
2020-02-18 2:05 ` Hangbin Liu
2020-02-18 3:01 ` David Miller
2020-02-18 8:00 ` Hangbin Liu
2020-02-17 2:57 ` 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=87r1ytpkdu.fsf@mellanox.com \
--to=petrm@mellanox.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=idosch@mellanox.com \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=petedaws@gmail.com \
--cc=pmachata@gmail.com \
/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.