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.
