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.
