On Tue, 24 Nov 2020 14:02:10 -0400 Jason Gunthorpe wrote: > On Tue, Nov 24, 2020 at 09:12:19AM -0800, Jakub Kicinski wrote: > > On Sun, 22 Nov 2020 08:41:58 +0200 Eli Cohen wrote: > > > On Sat, Nov 21, 2020 at 04:01:55PM -0800, Jakub Kicinski wrote: > > > > On Fri, 20 Nov 2020 15:03:34 -0800 Saeed Mahameed wrote: > > > > > From: Eli Cohen <eli@xxxxxxxxxxxx> > > > > > > > > > > Add a new namespace type to the NIC RX root namespace to allow for > > > > > inserting VDPA rules before regular NIC but after bypass, thus allowing > > > > > DPDK to have precedence in packet processing. > > > > > > > > How does DPDK and VDPA relate in this context? > > > > > > mlx5 steering is hierarchical and defines precedence amongst namespaces. > > > Up till now, the VDPA implementation would insert a rule into the > > > MLX5_FLOW_NAMESPACE_BYPASS hierarchy which is used by DPDK thus taking > > > all the incoming traffic. > > > > > > The MLX5_FLOW_NAMESPACE_VDPA hirerachy comes after > > > MLX5_FLOW_NAMESPACE_BYPASS. > > > > Our policy was no DPDK driver bifurcation. There's no asterisk saying > > "unless you pretend you need flow filters for RDMA, get them upstream > > and then drop the act". > > Huh? > > mlx5 DPDK is an *RDMA* userspace application. Forgive me for my naiveté. Here I thought the RDMA subsystem is for doing RDMA. I'm sure if you start doing crypto over ibverbs crypto people will want to have a look. > libibverbs. It runs on the RDMA stack. It uses RDMA flow filtering and > RDMA raw ethernet QPs. I'm not saying that's not the case. I'm saying I don't think this was something that netdev developers signed-off on. And our policy on DPDK is pretty widely known. Would you mind pointing us to the introduction of raw Ethernet QPs? Is there any production use for that without DPDK? > It has been like this for years, it is not some "act". > > It is long standing uABI that accelerators like RDMA/etc get to take > the traffic before netdev. This cannot be reverted. I don't really > understand what you are expecting here? Same. I don't really know what you expect me to do either. I don't think I can sign-off on kernel changes needed for DPDK.
