On Fri, Mar 13, 2020 at 10:53:03AM -0300, Jason Gunthorpe wrote: > On Tue, Mar 10, 2020 at 11:14:27AM +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro@xxxxxxxxxxxx> > > > > Changelog: > > v1: Dropped field_avail patch in favor of mass conversion to use function > > which already exists in the kernel code. > > v0: https://lore.kernel.org/lkml/20200305150105.207959-1-leon@xxxxxxxxxx > > > > Enhanced Connection Established or ECE is new negotiation scheme > > introduced in IBTA v1.4 to exchange extra information about nodes > > capabilities and later negotiate them at the connection establishment > > phase. > > > > The RDMA-CM messages (REQ, REP, SIDR_REQ and SIDR_REP) were extended > > to carry two fields, one new and another gained new functionality: > > * VendorID is a new field that indicates that common subset of vendor > > option bits are supported as indicated by that VendorID. > > * AttributeModifier already exists, but overloaded to indicate which > > vendor options are supported by this VendorID. > > > > This is kernel part of such functionality which is responsible to get data > > from librdmacm and properly create and handle RDMA-CM messages. > > > > Thanks > > > > Leon Romanovsky (11): > > RDMA/mlx4: Delete duplicated offsetofend implementation > > RDMA/mlx5: Use offsetofend() instead of duplicated variant > > RDMA/cm: Delete not implemented CM peer to peer communication > > These ones applied to for-next Thanks > > > RDMA/efa: Use in-kernel offsetofend() to check field availability > > This needs resending I'm not convinced yet. > > > RDMA/cm: Add Enhanced Connection Establishment (ECE) bits > > RDMA/uapi: Add ECE definitions to UCMA > > RDMA/ucma: Extend ucma_connect to receive ECE parameters > > RDMA/ucma: Deliver ECE parameters through UCMA events > > RDMA/cm: Send and receive ECE parameter over the wire > > RDMA/cma: Connect ECE to rdma_accept > > RDMA/cma: Provide ECE reject reason > > These need userspace to not be RFC Sure, thanks. > > Jason