----- shmulik.ladkani@gmail.com wrote:
On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon
[off-list ref] wrote:
quoted
I still think that default behavior should be to zero skb->mark only
when skb
quoted
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.
Regards,
Shmulik
On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon [off-list ref] wrote:
----- shmulik.ladkani@gmail.com wrote:
quoted
On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon
[off-list ref] wrote:
quoted
I still think that default behavior should be to zero skb->mark only
when skb
quoted
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.
Regards,
Shmulik