[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZRv0IolLA28HlIkP@shredder>
Date: Tue, 3 Oct 2023 13:59:46 +0300
From: Ido Schimmel <idosch@...dia.com>
To: Alce Lafranque <alce@...ranque.net>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
vincent@...nat.ch
Subject: Re: [PATCH net-next] vxlan: add support for flowlabel inherit
On Sat, Sep 30, 2023 at 09:28:19AM -0500, Alce Lafranque wrote:
> By default, VXLAN encapsulation over IPv6 sets the flow label to 0, with an
> option for a fixed value. This commits add the ability to inherit the flow
> label from the inner packet, like for other tunnel implementations.
Please add motivation to the commit message. At first glance it's not
clear why this is needed given that the entropy is encoded in the UDP
source port (unlike ip6gre, for example). I assume the motivation is
related to devices that can't calculate ECMP/RSS hash based on L4
headers, but I prefer not to guess :)
Regarding the netlink interface, I think we should introduce a new u8
attribute that encodes the flow label policy:
0 - Fixed. Taken from IFLA_VXLAN_LABEL. This is the default.
1 - Inherit. Copy if packet is IPv6, otherwise set to 0.
This will allow us to add more policies in the future:
2 - Hash. Set the flow label according to the hash of the inner packet.
Useful when inner packet is not IPv6.
3 - Inherit with hash fallback. Copy if packet is IPv6, otherwise set
according to the hash of the inner packet.
This already exists in at least one hardware implementation that I'm
familiar with, so I see no reason not to create provisions for this in a
software implementation. We can implement the last two policies if/when
someone asks for them.
The command line interface can remain as you have it now:
# ip link add vxlan1 type vxlan id 100 flowlabel inherit remote 2001:db8::1 local 2001:db8::2
But unlike the current implementation, user space will be able to change
it on the fly:
# ip link set vxlan1 type vxlan flowlabel 5
# ip link set vxlan1 type vxlan flowlabel inherit
Unless iproute2 is taught to probe for the new policy attribute, then
when setting the flow label to a fixed value iproute2 shouldn't default
to sending the new attribute as it will be rejected by old kernels.
Instead, the kernel can be taught that the presence of IFLA_VXLAN_LABEL
implies the default policy.
The JSON output can mimic the netlink structure and add a new key for
the new policy attribute.
Thanks
Powered by blists - more mailing lists