----- shmulik.ladk...@gmail.com wrote: > On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon > <liran.a...@oracle.com> wrote: > > ----- shmulik.ladk...@gmail.com wrote: > > > > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon > > > <liran.a...@oracle.com> wrote: > > > > > > > > I still think that default behavior should be to zero skb->mark > only > > > when skb > > > > cross netdevs in different netns. > > > > > > But the previous default was scrub the mark in *both* xnet and > > > non-xnet > > > situations. > > > > > > Therefore, there might be users which RELY on this (strange) > default > > > behavior in their same-netns-veth-pair setups. > > > Meaning, changing the default behavior might break their apps > relying > > > on > > > the former default behavior. > > > > > > This is why the "disable mark scrubbing in non-xnet case" should > be > > > opt-in. > > > > We think the same. > > The only difference is that I think this for now should be > controllable > > by a global /proc/sys/net/core file instead of giving a flexible > per-netdev > > control. > > Because that is a larger change that could be done later. > > A flags attribute to veth newlink is a very scoped change. > User controls this per veth creation. > This is way more neat than /proc/sys/net and provides the desired > granular > control. > > Also, scoping this to veth has the advantage of not affecting the many > other > dev_forward_skb callers.
Agreed. But isn't this an issue also for the many others (& future) callers of dev_forward_skb()? This seems problematic to me. This will kinda leave a kernel interface with broken default behavior for backwards comparability. A flag to netdev or /proc/sys/net/core to "fix" default behavior will avoid this. > > Regards, > Shmulik
