Re: [net-next V2 01/17] net/mlx5: E-Switch, Refactor setting source port

On Tue, Feb 09, 2021 at 06:10:59PM +0200, Or Gerlitz wrote:

On Tue, Feb 9, 2021 at 4:26 PM Vlad Buslov [off-list ref] wrote:

quoted

On Mon 08 Feb 2021 at 22:22, Jakub Kicinski [off-list ref] wrote:

quoted

On Mon, 8 Feb 2021 10:21:21 +0200 Vlad Buslov wrote:

quoted

quoted

quoted

quoted

These operations imply that 7.7.7.5 is configured on some interface on
the host. Most likely the VF representor itself, as that aids with ARP
resolution. Is that so?

quoted

quoted

quoted

The tunnel endpoint IP address is configured on VF that is represented
by enp8s0f0_0 representor in example rules. The VF is on host.

quoted

quoted

This is very confusing, are you saying that the 7.7.7.5 is configured
both on VF and VFrep? Could you provide a full picture of the config
with IP addresses and routing?

quoted

No, tunnel IP is configured on VF. That particular VF is in host [..]

What's the motivation for that? isn't that introducing 3x slow down?

Vlad please correct me if I'm wrong.

I think this boils down to not using the uplink representor as a real
interface. This way, the host can make use of 7.7.7.5 for other stuff
as well without passing (heavy) traffic through representor ports,
which are not meant for it.

So the host can have the IP 7.7.7.5 and also decapsulate vxlan traffic
on it, which wouldn't be possible/recommended otherwise.

Another moment that this gets visible is with VF LAG. When we bond the
uplink representors, add an IP to it and do vxlan decap, that IP is
meant only for the decap process and shouldn't be used for heavier
traffic as its passing through representor ports.

Then, tc config for decap need to be done on VF0rep and not on VF0
itself because that would be a security problem: one VF (which could
be on a netns) could steer packets to another VF at will.