Re: [PATCH rdma-next 0/6] Enhanced mode for IPoIB driver

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 6366 bytes --]

On Tue, Apr 04, 2017 at 07:50:21PM +0000, Weiny, Ira wrote:
> >
> > Hi Doug,
> >
> > This patchset mostly comes from Erez with one exception in the first patch.
> >
> > That patch origins from two different commits, first from Niranjana who added
> > RDMA netdev interface and second from Erez who added IPoIB support.
> >
> > During the preparation to submission, I squashed their commits into one and
> > refactored code to allow submission as a standalone topic without creating
> > dependecies between different submissions. This caused to change in author
> > line.
> > I hope that it doesn't really matter and it won't stop you from merging it.
>
> I'm confused by how you expect Niranjana's patch to be merged in this situation?
>
> Doug, will you take care of the conflict between these 2 submitted patches?
>
> [PATCH 02/11] IB/opa-vnic: Virtual Network Interface Controller (VNIC) interface
> And
> [PATCH rdma-next 1/6] IB/IPoIB: Introduce RDMA netdev interface and IPoIB structs

Ira,

The IPoIB and HFI-VNIC are independent series, so topics should be
self-contained. If the merge conflict worries you, Niranjana or me could
easily base our patch sets on another topic, but we need to know
the acceptance (yes/no) and order between them.

Thanks

>
> Ira
>
> >
> > Per-your request, I based this patch set on v4.11-rc3.
> >
> > Thanks,
> > 	Leon
> >
> > CC: Niranjana Vishwanathapura <niranjana.vishwanathapura-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > CC: Alex Vesker <valex-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > ---
> >
> > The rest comes from Erez:
> >
> >     The IPoIB protocol encapsulates IP packets over Infiniband datagrams.
> >     As a direct RDMA Upper Layer Protocol (ULP), IPoIB cannot support HW
> >     features that are specific to the IP protocol stack.
> >
> >     Nevertheless, RDMA interfaces have been extended to support some of the
> >     prominent IP offload features, such as TCP/UDP checksum and TSO.
> >     This provided reasonable performance gain for IPoIB but is still
> >     insufficient to cope with the increasing network bandwidth demand.
> >
> >     However, New features are exisiting in common network interfaces that
> >     are very hard to implement in IPoIB interfaces while it uses the RDMA
> >     layer, examples include TSS and RSS, tunneling offloads, and XDP.
> >     Rather than continuously porting IP network interface developments into
> >     the RDMA stack, we propose adding an abstract network data-path
> >     interfaces to RDMA devices.
> >
> >     In order to present a consistent interface to users, the IPoIB ULP
> >     continues to represent the network device to the IP stack.
> >     The common code also manages the IPoIB control plane, such as resolving
> >     path queries and registering to multicast groups.
> >     Data path operations are forwarded to devices that implement the new
> >     API, or fallback to the standard implementation otherwise.
> >     Using the forgoing approach, we show how IPoIB closes the performance
> >     gap compared to state-of-the-art Ethernet network interfaces.
> >
> >     The implementation idea is to use the api of
> >     alloc_rdma_netdev/free_rdma_netdev to expose a struct that has data
> >     members and set of functions that are used for IB network interfaces,
> >     like attach/detach multicast to qp, and send IB packet.
> >
> >     The functions are specific for IB operations and are not part of the
> >     common api the the netdev struct exposes via the ndo functions.
> >     1. multicast handling - attach/detach
> >     2. send operation - the ndo start_xmit has only 2 parameters and the IB
> >     send needs the destination qp and the ah object, there were few options
> >     to handle it via the netdev ndo, but they don't make more sense than
> >     using a specific send function (we are rdma_netdev after all)
> >
> >     The IPoIB code will be adapted to enable the option of accelerating the
> >     network interface, but the code will work as before if the HW below
> >     doesn't support the acceleration.
> >     That means that in the default mode of ipoib I tried to keep it as much
> >     as it was before, not to force it to adopt the new api, where there is
> >     no code sharing between the ipoib and the vnic/hfi.
> >     The default code uses the controll and the data, the accelerator uses
> >     only the control flows andstructors.
> >     The changes of the default ipoib can be made on top of that series.
> >
> >     Each HW vendor can supply the acceleration for the IPoIB or to leave
> >     IPoIB to work as before.
> >
> > Thanks,
> > 	Erez
> >
> > Erez Shitrit (5):
> >   IB/IPoIB: Separate control and data related initializations
> >   IB/IPoIB: Separate control from HW operation on ipoib_open/stop ndo
> >   IB/IPoIB: Rename qpn to be dqpn in ipoib_send and post_send functions
> >   IB/IPoIB: Formatting before adding accelerator to driver
> >   IB/IPoIB: Support acceleration options callbacks
> >
> > Leon Romanovsky (1):
> >   IB/IPoIB: Introduce RDMA netdev interface and IPoIB structs
> >
> >  drivers/infiniband/ulp/ipoib/ipoib.h           |  40 +--
> >  drivers/infiniband/ulp/ipoib/ipoib_cm.c        |  66 ++---
> >  drivers/infiniband/ulp/ipoib/ipoib_ethtool.c   |   6 +-
> >  drivers/infiniband/ulp/ipoib/ipoib_fs.c        |   4 +-
> >  drivers/infiniband/ulp/ipoib/ipoib_ib.c        | 339 +++++++++++++------------
> >  drivers/infiniband/ulp/ipoib/ipoib_main.c      | 312 +++++++++++++++++------
> >  drivers/infiniband/ulp/ipoib/ipoib_multicast.c |  39 +--
> >  drivers/infiniband/ulp/ipoib/ipoib_netlink.c   |  12 +-
> >  drivers/infiniband/ulp/ipoib/ipoib_verbs.c     |  64 ++---
> >  drivers/infiniband/ulp/ipoib/ipoib_vlan.c      |   9 +-
> >  include/rdma/ib_verbs.h                        |  41 +++
> >  11 files changed, 565 insertions(+), 367 deletions(-)
> >
> > --
> > 2.12.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body
> > of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]