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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 9 Feb 2021 10:05:04 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vlad Buslov <vladbu@...dia.com>
Cc:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
        Mark Bloch <mbloch@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>,
        Or Gerlitz <gerlitz.or@...il.com>
Subject: Re: [net-next V2 01/17] net/mlx5: E-Switch, Refactor setting source
 port

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.