netdev - Re: pull-request: mlx5-next 2023-01-24 V2

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Y91pJHDYRXIb3rXe@x130>
Date:   Fri, 3 Feb 2023 12:05:56 -0800
From:   Saeed Mahameed <saeed@...nel.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Leon Romanovsky <leon@...nel.org>,
        Jason Gunthorpe <jgg@...dia.com>,
        "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Saeed Mahameed <saeedm@...dia.com>, linux-rdma@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: pull-request: mlx5-next 2023-01-24 V2

On 02 Feb 10:30, Jakub Kicinski wrote:
>On Thu, 2 Feb 2023 10:15:57 -0800 Saeed Mahameed wrote:
>> It's a reality that mlx5_core is serving both netdev and rdma, it's not
>> about who has the keys for approving, it's that the fact the mlx5_core is
>> not just a netdev driver
>
>Nah, nah, nah, don't play with me. You put in "full IPsec offload"
>with little netdev use, then start pushing RDMA IPsec patches.
>Don't make it sound like netdev and rdma are separate entities which
>just share the HW when you're using APIs of one to configure the other.
>If RDMA invented its own API for IPsec without touching xfrm, we would
>not be having this conversation. That'd be fine by me.
>
>You used our APIs to make your proprietary thing easier to integrate and
>configure - now you have to find someone who will pull the PR and still
>sleep at night. Not me.

I don't agree, RDMA isn't proprietary, and I wish not to go into this
political discussion, as this series isn't the right place for that.

To summarize, mlx5_core is doing RoCE traffic processing and directs it to
mlx5_ib driver (a standard rdma stack), in this series we add RoCE ipsec
traffic processing as we do for all other RoCE traffic.

   net/mlx5: Implement new destination type TABLE_TYPE
   net/mlx5: Add IPSec priorities in RDMA namespaces
   net/mlx5: Configure IPsec steering for ingress RoCEv2 traffic
   net/mlx5: Configure IPsec steering for egress RoCEv2 traffic

The last two patches are literally just adding the steering rules
corresponding to ingress and egress RoCE traffic in mlx5_core steering
tables.