> I must disagree. You made this claim back when we submitted the IB
> core patch which adds support for signature, protection etc offloads
> (commit 1b01d33560e7 "IB/core: Introduce signature verbs API" and the
> detailed replied you got were explaining that
And I'll continue to make this claim because it is true.
> Very similar arguments would apply to the ODP submission.
Yes - ODP will _have_ to change the core. USNIC had to change the core, and had changes rejected that made perfect sense conceptually. This is part of the problem!!! If you disagree, then submit patches that don't touch the core.
> So examples please!
Sure - this is from Somnath's latest patch series:
Matan Barak (14):
IB/core: Add RoCE GID cache
IB/core: Add kref to IB devices
IB/core: Add RoCE GID population
IB/core: Add default GID for RoCE GID Cache
net/bonding: make DRV macros private
net: Add info for NETDEV_CHANGEUPPER event
IB/core: Add RoCE cache bonding support
IB/core: GID attribute should be returned from verbs API and cache API
IB/core: Report gid_type and gid_ndev through sysfs
IB/core: Support find sgid index using a filter function
IB/core: Modify ib_verbs and cma in order to use roce_gid_cache
IB/core: Add gid_type to path and rdma_id_private
IB/core: Add rdma_network_type to wc
IB/cma: Add configfs for rdma_cm
Moni Shoua (13):
IB/mlx4: Remove gid table management for RoCE
IB/mlx4: Replace spin_lock with rw_semaphore
IB/mlx4: Lock with RCU instead of RTNL
net/mlx4: Postpone the registration of net_device
IB/mlx4: Advertise RoCE support in port capabilities
IB/mlx4: Implement ib_device callback - get_netdev
IB/mlx4: Implement ib_device callback - modify_gid
IB/mlx4: Configure device to work in RoCEv2
IB/mlx4: Translate cache gid index to real index
IB/core: Initialize UD header structure with IP and UDP headers
IB/mlx4: Enable send of RoCE QP1 packets with IP/UDP headers
IB/mlx4: Create and use another QP1 for RoCEv2
IB/cma: Join and leave multicast groups with IGMP
That's a significant number of patches that modify the core rdma layer. NFSoRDMA had 5 different ways to register memory.
I agree that Roland's response time is ridiculously slow. But he does tend to merge in new drivers and updates that only touch a single vendor's driver fairly quickly. It's the thrashing on the core that sees significant delays.
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
