Re: [PATCH v5 00/26] New fast registration API
On Sun, Nov 1, 2015 at 11:56 PM, Stephen Rothwell wrote: > On Sun, 1 Nov 2015 17:00:22 +0200 Or Gerlitz wrote: >> Stephen, is the framework for linux-next merge tests OK with this tag? >> can you confirm that the-next bits of the rdma tree are covered fine? > linux-next fetches the "for-next" tag for that tree. Good! Doug, did you also manage to register this tag habit to the 0-day framework? we want all our subsystem patches to go through 0-day before they hit upstream, both rc fixes and next bits. Also, Doug, how do you suggest someone that wants to automatically track rc fixes branch? can you make another flying "for-rc" tag? Alaa, lets set our internal build system to follow on this tag too and let Doug know if we fail so he can coach us further. Or. -- 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
Re: [PATCH v5 00/26] New fast registration API
Hi, On Sun, 1 Nov 2015 17:00:22 +0200 Or Gerlitz wrote: > > Stephen, is the framework for linux-next merge tests OK with this tag? > can you confirm that the > -next bits of the rdma tree are covered fine? linux-next fetches the "for-next" tag for that tree. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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
Re: [PATCH v5 00/26] New fast registration API
hi On 11/1/2015 17:00, Or Gerlitz wrote: > On Thu, Oct 29, 2015 at 4:16 PM, Doug Ledford wrote: >> On 10/29/2015 01:42 AM, Or Gerlitz wrote: >>> On Thu, Oct 29, 2015 at 4:34 AM, Doug Ledford wrote: Yes, I've pulled this in for 4.4. Thanks! >>> Doug, we want to run regression over the 4.4 bits, when do you expect >>> for them to show up @ your kernel.org tree? >> Sorry, when the fast registration API caused compile failure yesterday I >> stopped at it and forgot to push the result out. So, I've removed the >> last patch of that series so it resolves the build breakage for now. We >> can add the last patch back in after the staging drivers are fixed up. >> The result has been pushed to both github and k.o. >> >>> some of them are there but >>> @ least 3-4 series which you said "applied" aren't, AFAIR last time it >>> was only about whole ten days after the merge window opened. Also, >>> without the patches being there the code isn't subject to linux-next >>> merge test (also after being there neither, since the branch name >>> changes for each release and I didn't see you setting a flying tag, or >>> you did so?) >> Yes, I set a flying tag as you call it. > Doug, can you please re-spare few words on how this works? > > Stephen, is the framework for linux-next merge tests OK with this tag? > can you confirm that the > -next bits of the rdma tree are covered fine? > > Alaa, are you managing to follow on this tag for the MLNX internal > builds? or you use manually the k.o/4.4 branch? > > Or. > Currently, I take the k.o/for-4.4 branch. Alaa -- 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
Re: [PATCH v5 00/26] New fast registration API
On Thu, Oct 29, 2015 at 4:16 PM, Doug Ledford wrote: > On 10/29/2015 01:42 AM, Or Gerlitz wrote: >> On Thu, Oct 29, 2015 at 4:34 AM, Doug Ledford wrote: >>> Yes, I've pulled this in for 4.4. Thanks! >> >> Doug, we want to run regression over the 4.4 bits, when do you expect >> for them to show up @ your kernel.org tree? > > Sorry, when the fast registration API caused compile failure yesterday I > stopped at it and forgot to push the result out. So, I've removed the > last patch of that series so it resolves the build breakage for now. We > can add the last patch back in after the staging drivers are fixed up. > The result has been pushed to both github and k.o. > >> some of them are there but >> @ least 3-4 series which you said "applied" aren't, AFAIR last time it >> was only about whole ten days after the merge window opened. Also, >> without the patches being there the code isn't subject to linux-next >> merge test (also after being there neither, since the branch name >> changes for each release and I didn't see you setting a flying tag, or >> you did so?) > > Yes, I set a flying tag as you call it. Doug, can you please re-spare few words on how this works? Stephen, is the framework for linux-next merge tests OK with this tag? can you confirm that the -next bits of the rdma tree are covered fine? Alaa, are you managing to follow on this tag for the MLNX internal builds? or you use manually the k.o/4.4 branch? Or. -- 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
Re: [PATCH v5 00/26] New fast registration API
On 10/29/2015 11:24 AM, Sagi Grimberg wrote: > >>> I can provide a patch for hfi, anything else needed? >> >> It breaks all of them in staging, not just hgi1. So, hfi1, amso1100, >> ipath, and ehca. > > hfi1: Does not support FRWR at all, there are just some copy-paste > sections that supposedly handle it - so I'll drop any sign of it from > the code. We'll add this support to the generic for qib, hfi, softroce. > > ipath: same > > amso1100 & ehca: it does not have FRWR at all - no sign of it in terms > of code... did they really break? I can't say for sure now. The compile history has scrolled out of that terminal. I knew it was more than one driver, but I didn't write down if it was all of them for sure. But that's not really my point, it was more that I needed you to look at them all and make sure the compile won't break for any of them ;-) > I'll send a patch for hfi1 and ipath. Thanks! -- Doug Ledford GPG KeyID: 0E572FDD signature.asc Description: OpenPGP digital signature
Re: [PATCH v5 00/26] New fast registration API
I can provide a patch for hfi, anything else needed? It breaks all of them in staging, not just hgi1. So, hfi1, amso1100, ipath, and ehca. hfi1: Does not support FRWR at all, there are just some copy-paste sections that supposedly handle it - so I'll drop any sign of it from the code. We'll add this support to the generic for qib, hfi, softroce. ipath: same amso1100 & ehca: it does not have FRWR at all - no sign of it in terms of code... did they really break? I'll send a patch for hfi1 and ipath. Sagi. -- 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
Re: [PATCH v5 00/26] New fast registration API
On 10/29/2015 10:33 AM, Sagi Grimberg wrote: > > > On 29/10/2015 16:16, Doug Ledford wrote: >> On 10/29/2015 01:42 AM, Or Gerlitz wrote: >>> On Thu, Oct 29, 2015 at 4:34 AM, Doug Ledford >>> wrote: Yes, I've pulled this in for 4.4. Thanks! >>> >>> Doug, we want to run regression over the 4.4 bits, when do you expect >>> for them to show up @ your kernel.org tree? >> >> Sorry, when the fast registration API caused compile failure yesterday I >> stopped at it and forgot to push the result out. So, I've removed the >> last patch of that series so it resolves the build breakage for now. We >> can add the last patch back in after the staging drivers are fixed up. >> The result has been pushed to both github and k.o. > > I can provide a patch for hfi, anything else needed? It breaks all of them in staging, not just hgi1. So, hfi1, amso1100, ipath, and ehca. -- Doug Ledford GPG KeyID: 0E572FDD signature.asc Description: OpenPGP digital signature
Re: [PATCH v5 00/26] New fast registration API
On 29/10/2015 16:16, Doug Ledford wrote: On 10/29/2015 01:42 AM, Or Gerlitz wrote: On Thu, Oct 29, 2015 at 4:34 AM, Doug Ledford wrote: Yes, I've pulled this in for 4.4. Thanks! Doug, we want to run regression over the 4.4 bits, when do you expect for them to show up @ your kernel.org tree? Sorry, when the fast registration API caused compile failure yesterday I stopped at it and forgot to push the result out. So, I've removed the last patch of that series so it resolves the build breakage for now. We can add the last patch back in after the staging drivers are fixed up. The result has been pushed to both github and k.o. I can provide a patch for hfi, anything else needed? -- 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
Re: [PATCH v5 00/26] New fast registration API
On 10/29/2015 01:42 AM, Or Gerlitz wrote: > On Thu, Oct 29, 2015 at 4:34 AM, Doug Ledford wrote: >> Yes, I've pulled this in for 4.4. Thanks! > > Doug, we want to run regression over the 4.4 bits, when do you expect > for them to show up @ your kernel.org tree? Sorry, when the fast registration API caused compile failure yesterday I stopped at it and forgot to push the result out. So, I've removed the last patch of that series so it resolves the build breakage for now. We can add the last patch back in after the staging drivers are fixed up. The result has been pushed to both github and k.o. > some of them are there but > @ least 3-4 series which you said "applied" aren't, AFAIR last time it > was only about whole ten days after the merge window opened. Also, > without the patches being there the code isn't subject to linux-next > merge test (also after being there neither, since the branch name > changes for each release and I didn't see you setting a flying tag, or > you did so?) Yes, I set a flying tag as you call it. -- Doug Ledford GPG KeyID: 0E572FDD signature.asc Description: OpenPGP digital signature
Re: [PATCH v5 00/26] New fast registration API
On Thu, Oct 29, 2015 at 4:34 AM, Doug Ledford wrote: > Yes, I've pulled this in for 4.4. Thanks! Doug, we want to run regression over the 4.4 bits, when do you expect for them to show up @ your kernel.org tree? some of them are there but @ least 3-4 series which you said "applied" aren't, AFAIR last time it was only about whole ten days after the merge window opened. Also, without the patches being there the code isn't subject to linux-next merge test (also after being there neither, since the branch name changes for each release and I didn't see you setting a flying tag, or you did so?) Or. -- 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
Re: [PATCH v5 00/26] New fast registration API
On 10/20/2015 07:33 AM, Sagi Grimberg wrote: > Doug, are you planning on taking this for 4.4? > > I think this set has converged towards inclusion. > > Reminder, this series goes on top of Christoph's > wr_cleanup patches and iser bounce buffering cleanup. Yes, I've pulled this in for 4.4. Thanks! -- Doug Ledford GPG KeyID: 0E572FDD signature.asc Description: OpenPGP digital signature
Re: [PATCH v5 00/26] New fast registration API
Doug, are you planning on taking this for 4.4? I think this set has converged towards inclusion. Reminder, this series goes on top of Christoph's wr_cleanup patches and iser bounce buffering cleanup. Sagi. -- 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
[PATCH v5 00/26] New fast registration API
Hi all, As discussed on the linux-rdma list, there is plenty of room for improvement in our memory registration APIs. We keep finding ULPs that are duplicating code, sometimes use wrong strategies and mis-use our current API. As a first step, this patch set replaces the fast registration API to accept a kernel common struct scatterlist and takes care of the page vector construction in the core layer with hooks for the drivers HW specific assignments. This allows to remove a common code duplication as it was done in each and every ULP driver. Changes from v4: - Changed ib_map_mr_sg() sg_nents arg to by signed integer to avoid signed/unsigned comparison (Chuck) Changes from v3: - Addressed some xprtrdma comments (Chuck) - Removed xprtrdma change-log paragraph (Or) Changes from v2: - Fixed alignment for page lists allocations in mlx4, mlx5 (Bart) - Rebased against Doug's for-4.4 tree (4.3.0-rc1) + 4.3-rc fixes - Added Acked/Tested tags Changes from v1: - Add ib_map_mr_sg_zbva() for RDS which uses it (preferred it over polluting the API). - Replaced coherent allocations in mlx4, mlx5 with DMA streaming APIs (Bart) - Changed ib_map_mr_sg description (Bart) - Split SRP driver patches (Bart) - Added missing wr->next = NULL from various ULPs (Steve, Santosh) - Fixed 0-day testing errors in nes driver, xprtrdma and svcrdma - Fixed checkpatch issues Changes from v0: - Rebased on top of 4.3-rc1 + Christoph's ib_send_wr conversion patches - Allow the ULP to pass page_size argument to ib_map_mr_sg in order to have it work better in some specific workloads. This suggestion came from Bart Van Assche which pointed out that some applications might use page sizes significantly smaller than the system PAGE_SIZE of specific architectures - Fixed some logical bugs in ib_sg_to_pages - Added a set_page function pointer for drivers to pass to ib_sg_to_pages so some drivers (e.g mlx4, mlx5, nes) can avoid keeping a second page vector and/or re-iterate on the page vector in order to perform HW specific assignments (big/little endian conversion, extra flags) - Converted SRP initiator and RDS iwarp ULPs to the new API - Removed fast registration code from hfi1 driver (as it isn't supported anyway). I assume that the correct place to get the support back would be in a shared SW library (hfi1, qib, rxe). - Updated the change logs The code is available at: https://github.com/sagigrimberg/linux reg_api.6 Sagi Grimberg (26): IB/core: Introduce new fast registration API IB/mlx5: Remove dead fmr code IB/mlx5: Support the new memory registration API IB/mlx4: Support the new memory registration API RDMA/ocrdma: Support the new memory registration API RDMA/cxgb3: Support the new memory registration API iw_cxgb4: Support the new memory registration API IB/qib: Support the new memory registration API RDMA/nes: Support the new memory registration API IB/iser: Port to new fast registration API iser-target: Port to new memory registration API xprtrdma: Port to new memory registration API svcrdma: Port to new memory registration API RDS/IW: Convert to new memory registration API IB/srp: Split srp_map_sg IB/srp: Convert to new registration API IB/srp: Remove srp_finish_mapping IB/srp: Dont allocate a page vector when using fast_reg IB/mlx5: Remove old FRWR API support IB/mlx4: Remove old FRWR API support RDMA/ocrdma: Remove old FRWR API RDMA/cxgb3: Remove old FRWR API iw_cxgb4: Remove old FRWR API IB/qib: Remove old FRWR API RDMA/nes: Remove old FRWR API IB/core: Remove old fast registration API drivers/infiniband/core/verbs.c | 132 +++--- drivers/infiniband/hw/cxgb3/iwch_cq.c | 2 +- drivers/infiniband/hw/cxgb3/iwch_provider.c | 39 +++-- drivers/infiniband/hw/cxgb3/iwch_provider.h | 2 + drivers/infiniband/hw/cxgb3/iwch_qp.c | 37 ++-- drivers/infiniband/hw/cxgb4/cq.c| 2 +- drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 25 +-- drivers/infiniband/hw/cxgb4/mem.c | 61 +++ drivers/infiniband/hw/cxgb4/provider.c | 3 +- drivers/infiniband/hw/cxgb4/qp.c| 47 +++-- drivers/infiniband/hw/mlx4/cq.c | 2 +- drivers/infiniband/hw/mlx4/main.c | 3 +- drivers/infiniband/hw/mlx4/mlx4_ib.h| 25 ++- drivers/infiniband/hw/mlx4/mr.c | 149 ++-- drivers/infiniband/hw/mlx4/qp.c | 34 ++-- drivers/infiniband/hw/mlx5/cq.c | 4 +- drivers/infiniband/hw/mlx5/main.c | 3 +- drivers/infiniband/hw/mlx5/mlx5_ib.h| 48 +- drivers/infiniband/hw/mlx5/mr.c | 135 ++- drivers/infiniband/hw/mlx5/qp.c | 140 +++ drivers/infiniband/hw/nes/nes_hw.h | 6 - drivers/infiniband/hw/nes/nes_verbs.c | 163 +++--- drivers/infiniband/hw/nes/nes_verbs.h | 4 + drivers/infiniband/hw/ocrdma/ocrdma.h | 2 + drivers/infinib