Re: [PATCH v5 00/26] New fast registration API

[Or Gerlitz]

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

[Alaa Hleihel]

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

[Stephen Rothwell]

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

[Doug Ledford]

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

[Doug Ledford]

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

[Doug Ledford]

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

[Sagi Grimberg]

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

[Doug Ledford]

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

[Or Gerlitz]

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

[Sagi Grimberg]

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

[Sagi Grimberg]

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 +