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

[Saeed Mahameed <saeed@kernel.org>]

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.