On Sun, Nov 10, 2024 at 8:59 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Fri, 8 Nov 2024 14:44:37 +0800 Xiao Liang wrote: > > > On Fri, 8 Nov 2024 00:53:55 +0800 Xiao Liang wrote: > > > > IMO, this is about driver capability, not about user requests. > > > > > > The bit is a driver capability, that's fine. But the question was how > > > to achieve backward compatibility. A flag in user request shifts the > > > responsibility of ensuring all services are compatible to whoever > > > spawns the interfaces. Which will probably be some network management > > > daemon. > > > > OK. So I think we can change the driver capability indicator in rtnl_ops > > to a tristate field, say, "linkns_support". > > If it is > > - not supported, then keep the old behavior > > - supported (vlan, macvlan, etc.), then change to the new behavior > > - compat-mode (ip_tunnel), default to old behavior and can be changed > > via an IFLA flag. > > Is this reasonable? > > Let's start with annotating the drivers which need the old behavior. > It seems like something that was done as a workaround for old drivers, > maybe there isn't that many of them and we can convert them all in one > series. I'd like to clarify a bit here. Link netns is closely coupled with source netns, as it's passed to drivers as source netns. Without introducing a flag, after applying the logic in this patchset, drivers won't be able to distinguish the two: 1) ip -n ns1 link add netns ns2 ... 2) ip link add netns ns2 link-netns ns1 ... There's no problem for drivers that already handle source netns. But it changes the semantics of 1) for ip tunnels silently. The effective link-netns is ns2 before, and will be changed to ns1 afterwards, which will almost certainly affect some users. Is this acceptable? On the other hand, do we need to deal with out-of-tree drivers?
