From: Vincent Bernat <vincent@bernat•ch>
To: Ido Schimmel <idosch@idosch•org>, David Ahern <dsahern@gmail•com>
Cc: Alce Lafranque <alce@lafranque•net>,
netdev@vger•kernel.org, stephen@networkplumber•org
Subject: Re: [PATCH iproute2] vxlan: add support for flowlab inherit
Date: Sun, 28 Jan 2024 15:28:13 +0100 [thread overview]
Message-ID: <d03e0741-e90a-4def-81ae-e9382164e032@bernat.ch> (raw)
In-Reply-To: <ZbZJ-IS20fe8wmQv@shredder>
On 2024-01-28 13:35, Ido Schimmel wrote:
> On Fri, Jan 26, 2024 at 10:17:36AM -0700, David Ahern wrote:
>> On 1/25/24 11:28 PM, Vincent Bernat wrote:
>>> Honestly, I have a hard time finding a real downside. The day we need to
>>> specify both a value and a policy, it will still be time to introduce a
>>> new keyword. For now, it seems better to be consistent with the other
>>> protocols and with the other keywords (ttl, for example) using the same
>>> approach.
>>
>> ok. let's move forward without the new keyword with the understanding it
>> is not perfect, but at least consistent across commands should a problem
>> arise. Consistency allows simpler workarounds.
>
> I find it weird that the argument for the current approach is
> consistency when the commands are already inconsistent:
[...]
It's still more consistent than adding a keyword. But we are OK to add a
keyword if needed. It seems there is no agreement yet on this. David, do
you prefer a keyword?
> I would also try to avoid sending the new 'IFLA_VXLAN_LABEL_POLICY' attribute
> for existing use cases: When creating a VXLAN device with a fixed flow label or
> when simply modifying an already fixed flow label. I would expect kernels
> 6.5-6.7 to reject the new attribute as since kernel 6.5 the VXLAN driver
> enforces strict validation. However, it's not the case:
[...]
This should be solved if there is a new keyword. If we do not introduce
a new keyword, this means querying the current state before setting the
new state as we need to know what the previous policy was.
> Regarding the comment about the
> "inherit-during-the-day-fixed-during-the-night" policy, I'm familiar
> with at least one hardware implementation that supports a policy of
> "inherit flow label when IPv6, otherwise set flow label to X" and it
> indeed won't be possible to express it with the single keyword approach.
Good example (better than mine).
next prev parent reply other threads:[~2024-01-28 14:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-20 12:44 [PATCH iproute2] vxlan: add support for flowlab inherit Alce Lafranque
2024-01-22 12:24 ` Ido Schimmel
2024-01-22 21:11 ` Vincent Bernat
2024-01-23 0:10 ` Stephen Hemminger
2024-01-23 0:29 ` David Ahern
2024-01-23 0:41 ` David Ahern
2024-01-23 7:58 ` Vincent Bernat
2024-01-23 16:19 ` David Ahern
2024-01-24 22:00 ` Vincent Bernat
2024-01-25 15:50 ` David Ahern
2024-01-26 6:28 ` Vincent Bernat
2024-01-26 17:17 ` David Ahern
2024-01-28 12:35 ` Ido Schimmel
2024-01-28 14:28 ` Vincent Bernat [this message]
2024-01-29 18:44 ` David Ahern
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=d03e0741-e90a-4def-81ae-e9382164e032@bernat.ch \
--to=vincent@bernat$(echo .)ch \
--cc=alce@lafranque$(echo .)net \
--cc=dsahern@gmail$(echo .)com \
--cc=idosch@idosch$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=stephen@networkplumber$(echo .)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