[RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1

[ira.weiny]

Greg, Doug,

As mentioned below, these patches depend on the new rdmavt library submitted to
Doug on linux-rdma.

We continue to identify (and rework) patches by our other developers which can
be submitted without conflicts with this series.  Furthermore, We have, as much
as possible, placed fixes directly into rdmavt such that those changes can be
dropped from hfi1.  But at this point, we need to know if and where these are
going to land so that we can start reworking as appropriate.

Therefore, I would like to discuss plans to get hfi1 under the same maintainer
to work through this transitional period.

Basically, At what point should we stop submitting patches to Greg and start
submitting to Doug?

Should we consider the merge window itself as the swap over point and submit
changes to Doug at that point?  If so, should we continue to submit what we can
to Greg until then (and continue rebase'ing the series below on that work)?  Or
given Gregs backlog, should we stop submitting to Greg sometime prior to the
merge window?

That brings up my final question, at the point of swap over I assume anything
not accepted by Greg should be considered rejected and we need to resubmit to
Doug?

Thanks in advance for any guidance,
Ira


On Mon, Dec 14, 2015 at 12:27:49PM -0500, Dalessandro, Dennis wrote:
> This patch series is being submitted as a Request For Comment only. It depends
> on code submitted to the rdma subsystem [1].
> 
> This work is the first submission aimed to satisfy the TODO item for removing
> duplicated code in hfi1. At the time of submission hfi1 and qib contained alot
> of duplicated verbs processing code. The qib driver is having similar changes
> made to use rdmavt. This will result in a common code base that both drivers and
> future drivers such as soft-roce can use.
> 
> Note that due to the ongoing submission of hfi1 improvement patches, there will
> likely be a number of conflicts which will still need to be resolved.
> 
> We also are still faced with the issue of separate trees for this work as was
> discussed previously [2]. The result of that conversation was to keep the
> drivers in separate trees until the 4.5 merge window. We are hoping that after
> this merge window a single maintainer can take control of hfi1, qib, and rdmavt
> so that these patches can move forward and be applied.
> 
> For now though we would like to get feedback on these patches with more to
> follow.
> 
> [1] https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg30074.html
> [2] https://www.mail-archive.com/linux-rdma%40vger.kernel.org/msg29360.html
> 
> ---
> 
> Dennis Dalessandro (15):
>       IB/hfi1: Begin to use rdmavt for verbs
>       IB/hfi1: Add basic rdmavt capability flags for hfi1
>       IB/hfi1: Consolidate dma ops for hfi1
>       IB/hfi1: Use rdmavt protection domain
>       IB/hfi1: Remove MR data structures from hfi1
>       IB/hfi1: Remove driver specific members from hfi1 qp type
>       IB/hfi1: Add device specific info prints
>       IB/hfi1: Use correct rdmavt header files after move.
>       IB/hfi1: Use address handle in rdmavt and remove from hfi1
>       IB/hfi1: Implement hfi1 support for AH notification
>       IB/hfi1: Remove hfi1 MR and hfi1 specific qp type
>       IB/hfi1: Remove srq from hfi1
>       IB/hfi1: Remove ibport and use rdmavt version
>       IB/hfi1: Remove mmap from hfi1
>       IB/hfi1: Use rdmavt pkey verbs function
> 
> 
>  drivers/staging/rdma/hfi1/Kconfig       |    2 
>  drivers/staging/rdma/hfi1/Makefile      |    4 
>  drivers/staging/rdma/hfi1/chip.c        |   36 +-
>  drivers/staging/rdma/hfi1/common.h      |    2 
>  drivers/staging/rdma/hfi1/cq.c          |   20 +
>  drivers/staging/rdma/hfi1/diag.c        |   13 -
>  drivers/staging/rdma/hfi1/driver.c      |   31 +-
>  drivers/staging/rdma/hfi1/hfi.h         |   27 +-
>  drivers/staging/rdma/hfi1/init.c        |    5 
>  drivers/staging/rdma/hfi1/intr.c        |    2 
>  drivers/staging/rdma/hfi1/keys.c        |  356 ---------------------
>  drivers/staging/rdma/hfi1/mad.c         |  163 +++++-----
>  drivers/staging/rdma/hfi1/mmap.c        |  192 -----------
>  drivers/staging/rdma/hfi1/mr.c          |  522 ------------------------------
>  drivers/staging/rdma/hfi1/pio.c         |   10 -
>  drivers/staging/rdma/hfi1/qp.c          |  214 +++++++-----
>  drivers/staging/rdma/hfi1/qp.h          |   44 +--
>  drivers/staging/rdma/hfi1/rc.c          |  155 +++++----
>  drivers/staging/rdma/hfi1/ruc.c         |  161 +++++----
>  drivers/staging/rdma/hfi1/sdma.h        |    8 
>  drivers/staging/rdma/hfi1/srq.c         |   58 ++-
>  drivers/staging/rdma/hfi1/sysfs.c       |   18 +
>  drivers/staging/rdma/hfi1/trace.h       |   22 +
>  drivers/staging/rdma/hfi1/uc.c          |   19 +
>  drivers/staging/rdma/hfi1/ud.c          |   91 +++--
>  drivers/staging/rdma/hfi1/verbs.c       |  526 +++++++++++--------------------
>  drivers/staging/rdma/hfi1/verbs.h       |  531 ++++---------------------------
>  drivers/staging/rdma/hfi1/verbs_mcast.c |   36 +-
>  28 files changed, 843 insertions(+), 2425 deletions(-)
>  delete mode 100644 drivers/staging/rdma/hfi1/keys.c
>  delete mode 100644 drivers/staging/rdma/hfi1/mmap.c
>  delete mode 100644 drivers/staging/rdma/hfi1/mr.c
> 
> --
> -Denny
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html