Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1
> > > > > > > > > > If Doug accepts the library changes, let me know that public git > > > > > commit > > > > > and I can pull it into the staging-next branch and you can continue to > > > > > send me staging patches that way. > > > > > > > > Won't this cause a conflict during the merge window? > > > > > > No, git is good :) > > > > > > > How do we handle changes which affect both qib and hfi1? > > > > > > I don't know, now this gets messy... > > > > > > > Agreed and this is what we are worried about. > > > > Can we do what Dan and Doug have proposed in the past and have Doug take > > over > > the staging/rdma sub-tree? > > > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html > > > > I think the upcoming merge window is a reasonable time for him to do that. > > Ok, but keeping on top of all of the generic staging patches that come > in is a tough thing to do, that's up to Doug, if he is ready for it... > Greg, Forgive me for not knowing how multiple maintainers deal with hand offs like this. I'm hoping you, and/or Doug, can answer some questions for me. Am I correct in assuming the merge window will be open on Monday? If so, when will Linus pull the staging tree? Then at what point will Doug get the hfi1 changes which have already been accepted? Are you going to be able to review the outstanding patches for staging/rdma/hfi1 before the merge window? Or should we consider them dropped and resubmit to Doug to apply after he has merged the latest hfi1 code from Linus? Doug, At what point should we start submitting additional patches to you which we have queued up but are not yet submitted to Greg? So far we have been cross posting to linux-rdma for feedback and I see that the patches have been dropped from patchworks. I assume you dropped them from patchworks because you knew that Greg was handling them? Thanks, Ira ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1
On Tue, Dec 22, 2015 at 06:27:57PM -0800, gre...@linuxfoundation.org wrote: > On Tue, Dec 22, 2015 at 02:15:08PM -0500, ira.weiny wrote: > > On Mon, Dec 21, 2015 at 05:01:48PM -0800, gre...@linuxfoundation.org wrote: [snip] > > > > > > No, git is good :) > > > > > > > How do we handle changes which affect both qib and hfi1? > > > > > > I don't know, now this gets messy... > > > > > > > Agreed and this is what we are worried about. > > > > Can we do what Dan and Doug have proposed in the past and have Doug take > > over > > the staging/rdma sub-tree? > > > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html > > > > I think the upcoming merge window is a reasonable time for him to do that. > > Ok, but keeping on top of all of the generic staging patches that come > in is a tough thing to do, that's up to Doug, if he is ready for it... > To help this process, once the change over happens, we will help to monitor driverdev-devel for anything submitted to staging/rdma. If something is submitted which was not to Doug and linux-rdma we can handle alerting the submitter to make sure it gets submitted to Doug as per the current MAINTAINERS file. Hope this helps, Ira ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1
On Tue, Dec 22, 2015 at 02:15:08PM -0500, ira.weiny wrote: > On Mon, Dec 21, 2015 at 05:01:48PM -0800, gre...@linuxfoundation.org wrote: > > On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote: > > > On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org > > > wrote: > > > > On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote: > > > > > 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? > > > > > > > > If Doug accepts the library changes, let me know that public git commit > > > > and I can pull it into the staging-next branch and you can continue to > > > > send me staging patches that way. > > > > > > Won't this cause a conflict during the merge window? > > > > No, git is good :) > > > > > How do we handle changes which affect both qib and hfi1? > > > > I don't know, now this gets messy... > > > > Agreed and this is what we are worried about. > > Can we do what Dan and Doug have proposed in the past and have Doug take over > the staging/rdma sub-tree? > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html > > I think the upcoming merge window is a reasonable time for him to do that. Ok, but keeping on top of all of the generic staging patches that come in is a tough thing to do, that's up to Doug, if he is ready for it... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1
On Mon, Dec 21, 2015 at 05:01:48PM -0800, gre...@linuxfoundation.org wrote: > On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote: > > On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org wrote: > > > On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote: > > > > 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? > > > > > > If Doug accepts the library changes, let me know that public git commit > > > and I can pull it into the staging-next branch and you can continue to > > > send me staging patches that way. > > > > Won't this cause a conflict during the merge window? > > No, git is good :) > > > How do we handle changes which affect both qib and hfi1? > > I don't know, now this gets messy... > Agreed and this is what we are worried about. Can we do what Dan and Doug have proposed in the past and have Doug take over the staging/rdma sub-tree? http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-November/081922.html I think the upcoming merge window is a reasonable time for him to do that. Ira ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1
On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org wrote: > On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote: > > 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? > > If Doug accepts the library changes, let me know that public git commit > and I can pull it into the staging-next branch and you can continue to > send me staging patches that way. Won't this cause a conflict during the merge window? How do we handle changes which affect both qib and hfi1? Ira > > That's the easiest thing to do usually. > > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1
On Mon, Dec 21, 2015 at 07:19:43PM -0500, ira.weiny wrote: > On Mon, Dec 21, 2015 at 02:02:35PM -0800, gre...@linuxfoundation.org wrote: > > On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote: > > > 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? > > > > If Doug accepts the library changes, let me know that public git commit > > and I can pull it into the staging-next branch and you can continue to > > send me staging patches that way. > > Won't this cause a conflict during the merge window? No, git is good :) > How do we handle changes which affect both qib and hfi1? I don't know, now this gets messy... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1
On Mon, Dec 21, 2015 at 01:12:14AM -0500, ira.weiny wrote: > 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? If Doug accepts the library changes, let me know that public git commit and I can pull it into the staging-next branch and you can continue to send me staging patches that way. That's the easiest thing to do usually. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 00/15] staging/rdma/hfi1: Initial patches to add rdmavt support in HFI1
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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
