Liran Alon <liran.a...@oracle.com> writes: > ----- 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.
I don't believe the current behavior is a bug. I looked through the history. Basically skb_scrub_packet started out as the scrubbing needed for crossing network namespaces. Then tunnels which needed 90% of the functionality started calling it, with the xnet flag added. Because the tunnels needed to preserve their historic behavior. Then dev_forward_skb started calling skb_scrub_packet. A veth pair is supposed to give the same behavior as a cross-over cable plugged into two local nics. A cross over cable won't preserve things like the skb mark. So I don't see why anyone would expect a veth pair to preserve the mark. Right now I don't see the point of handling packets that don't cross network namespace boundaries specially, other than to preserve backwards compatibility. Eric
