Re: [net-next V2 01/17] net/mlx5: E-Switch, Refactor setting source port
From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-02-09 18:21:47
On Tue, 9 Feb 2021 16:22:26 +0200 Vlad Buslov wrote:
No, tunnel IP is configured on VF. That particular VF is in host
namespace. When mlx5 resolves tunneling the code checks if tunnel
endpoint IP address is on such mlx5 VF, since the VF is in same
namespace as eswitch manager (e.g. on host) and route returned by
ip_route_output_key() is resolved through rt->dst.dev==tunVF device.
After establishing that tunnel is on VF the goal is to process two
resulting TC rules (in both directions) fully in hardware without
exposing the packet on tunneling device or tunnel VF in sw, which is
implemented with all the infrastructure from this series.
So, to summarize with IP addresses from TC examples presented in cover letter,
we have underlay network 7.7.7.0/24 in host namespace with tunnel endpoint IP
address on VF:
$ ip a show dev enp8s0f0v0
1537: enp8s0f0v0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 52:e5:6d:f2:00:69 brd ff:ff:ff:ff:ff:ff
altname enp8s0f0np0v0
inet 7.7.7.5/24 scope global enp8s0f0v0
valid_lft forever preferred_lft forever
inet6 fe80::50e5:6dff:fef2:69/64 scope link
valid_lft forever preferred_lft forever
Isn't this 100% the wrong way around. Disable the offloads. Does the
traffic hit the VF encapsulated?
IIUC SW will do this:
PHY port
|
device | ,-----.
-----------|------------|-------|----------
kernel | | |
(UL/PF) (VFr) (VF)
| | |
[TC ing]>redir -` V
And the packet never hits encap.