On Wed, 2019-01-30 at 15:42 -0700, Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 12:36:49PM -0500, Doug Ledford wrote: > > On Wed, 2019-01-30 at 18:21 +0100, bmt@xxxxxxxxxxxxxx wrote: > > > From: Bernard Metzler <bmt@xxxxxxxxxxxxxx> > > > > > > This patch set contributes a new version of the SoftiWarp > > > driver, as originally introduced to the list Oct 6th, 2017. > > > SoftiWarp (siw) implements the iWarp RDMA protocol over > > > kernel TCP sockets. The driver integrates with the > > > linux-rdma framework. > > > > > > For this patch series, we aimed at fixing the main > > > obstacles, which prevented siw acceptance in the past: > > > > > > 1. siw now uses the recently extended rdma netlink protocol > > > for adding and removing siw devices. It became the > > > only way of managing siw devices. > > > > > > 2. The driver integrates with the currently reviewed > > > RDMA/IWPM patch series on introducing no port mapping > > > requirements. These patches as provided by Steve Wise > > > are a pre-requisit to run siw in an environment with > > > active iwpmd. > > > > > > The code has the following known limitations: > > > > > > 1. Only IPv4 addresses are supported / no IPv6 support. > > > > > > 2. All previously flexible module parameters are translated > > > into const values as defined in siw_main.c. We propose > > > another extension of the netlink protocol to make those > > > driver parameters dynamically settable. Ideally, we would > > > distinguish between link specific and connection specific > > > parameters. > > > > > > Currently, we would like to see the following parameters > > > settable: > > > o MPA peer-to-peer mode (boolean on/off) > > > o MPA CRC (boolean on/off) > > > o MPA CRC negotiation mode: accept different CRC setting > > > from peer (boolean on/off) > > > o TCP_NODELAY to control Nagle settings of TCP socket > > > (boolean on/off) > > > o MPA version (0, 1 or 2) > > > o Zerocopy to let TCP transmit out of application > > > buffers wr/o copying data (boolean on/off) > > > o GSO to select Generic Segementation Offload for > > > larger frames (one frame may span 1 .. n Ethernet > > > frames, if advertised by TCP socket) > > > > > > In principle, all of those parameters could be controlled > > > per connection. At least, dynamically setting those per > > > device is highly desirable. Please let's agree on the > > > most clean solution for that. > > > > > > We maintain a snapshot of the current code at > > > https://github.com/zrlio/softiwarp-for-linux-rdma.git > > > within branch 'siw-for-rdma-next-nvme-5.0'. > > > This branch is based on the rdma-next tree and additionally > > > includes the latest netlink and portmapper patches from > > > Steve Wise as well as the latest nvme-5.0 code changes from > > > git://git.infradead.org/nvme.git. We tested siw with > > > NVMeF host and target applications and therefor merged > > > with latest nvme development. > > > > > > The matching siw user library is maintained at > > > https://github.com/zrlio/softiwarp-user-for-linux-rdma.git. > > > It is based on rdma-core, and extended with Steve's patches > > > to both rdma netlink and portmapper. The relevant branch > > > name is 'siw-for-rdma-next'. > > > > > > > > > As always, we'd highly appreciate your code review. Thanks > > > very much for your time. > > > > > > Bernard > > > > Hi Bernard, > > > > I'm *thrilled* to see this updated submission at this point in time. I > > would love nothing more than to see this make the next merge window. > > It depends on two big series I haven't sent yet :( The cover letter only mentions the port mapper issue and that it was tested against the latest nvme tree (I assume that isn't needed for this code to actually work and that the nvme stuff was just pulled for interop testing). What two large series are you referring to as it needs to be clearly called out. -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
