Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
* Re: capturing the error log from rdma-core
From: Jason Gunthorpe @ 2016-10-10 16:44 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161010161659.GA2219-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

On Mon, Oct 10, 2016 at 09:16:59AM -0700, Christoph Hellwig wrote:
> > If I understand you, you want to split STDOUT and STDERR because
> > sparse puts differentiated output on each FD?
> 
> No, sparse only outputs to SDTERR.  But for some reason the rdma-core
> build system multiplexes this back into STDOUT.

Right, ninja puts everything onto STDOUT as part of 'output-sync'
operation. That is usually not a problem..

If you are asking for the 'quietest' build then this hack will do it:

$ ninja | grep -v "^\["

Jason
--
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

^ permalink raw reply

* Re: [PATCH] add a build.sh helper to allow for a one-stop build
From: Bart Van Assche @ 2016-10-10 16:17 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161010155949.GA20091-jcswGhMUV9g@public.gmane.org>

On 10/10/16 08:59, Christoph Hellwig wrote:
> On Mon, Oct 10, 2016 at 08:56:33AM -0700, Bart Van Assche wrote:
>> Have you considered to make this script stop immediately if one of the
>> steps fails, e.g. as follows?
>
> How about just ading a
>
> set -e
>
> to the beginning to get this automatically?

That would also work. But if there is a space anywhere in the path in 
which the rdma-core repository exists, mkdir $BUILDDIR will have to be 
changed into mkdir "$BUILDDIR".

Bart.

--
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

^ permalink raw reply

* Re: capturing the error log from rdma-core
From: Christoph Hellwig @ 2016-10-10 16:16 UTC (permalink / raw)
  To: Jason Gunthorpe; +Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161010161246.GB26805-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>

On Mon, Oct 10, 2016 at 10:12:46AM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 10, 2016 at 08:30:13AM -0700, Christoph Hellwig wrote:
> 
> > what's the best way to generate a log of the compiler errors with the
> > shiny new rdma-core build system?  With make I'd do make 2>err.log
> > but with the new build system the verbose build output and the errors
> > are mixed in the same stream, so this isn't possible anymore.
> 
> If I understand you, you want to split STDOUT and STDERR because
> sparse puts differentiated output on each FD?

No, sparse only outputs to SDTERR.  But for some reason the rdma-core
build system multiplexes this back into STDOUT.

> I think the simplest approach for you will be to use make when doing
> this kind of work:
> 
> $ mkdir build-make
> $ cd build-make
> $ CC=cgcc cmake
> $ make 1> a 2> b

Ok..
--
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

^ permalink raw reply

* Re: capturing the error log from rdma-core
From: Jason Gunthorpe @ 2016-10-10 16:12 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161010153013.GA22997-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

On Mon, Oct 10, 2016 at 08:30:13AM -0700, Christoph Hellwig wrote:

> what's the best way to generate a log of the compiler errors with the
> shiny new rdma-core build system?  With make I'd do make 2>err.log
> but with the new build system the verbose build output and the errors
> are mixed in the same stream, so this isn't possible anymore.

If I understand you, you want to split STDOUT and STDERR because
sparse puts differentiated output on each FD?

There is a thread on the ninja list about fixing this, and here is a
proposed patch

https://github.com/dendy/ninja/commit/62564251afdafd9926fde363035807fb482ab0b9

But looks like it is not in main line.

I think the simplest approach for you will be to use make when doing
this kind of work:

$ mkdir build-make
$ cd build-make
$ CC=cgcc cmake
$ make 1> a 2> b

Jason
--
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

^ permalink raw reply

* Re: [PATCH] add a build.sh helper to allow for a one-stop build
From: Christoph Hellwig @ 2016-10-10 15:59 UTC (permalink / raw)
  To: Bart Van Assche
  Cc: Christoph Hellwig, jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <c2d80cd4-74b8-8391-1855-3c666f611d91-HInyCGIudOg@public.gmane.org>

On Mon, Oct 10, 2016 at 08:56:33AM -0700, Bart Van Assche wrote:
> Have you considered to make this script stop immediately if one of the 
> steps fails, e.g. as follows?

How about just ading a 

set -e

to the beginning to get this automatically?
--
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

^ permalink raw reply

* Re: [PATCH] add a build.sh helper to allow for a one-stop build
From: Bart Van Assche @ 2016-10-10 15:56 UTC (permalink / raw)
  To: Christoph Hellwig, jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476113282-19194-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>

On 10/10/16 08:28, Christoph Hellwig wrote:
>  *build/bin* will contain the sample programs and *build/lib* will contain the
> diff --git a/build.sh b/build.sh
> new file mode 100755
> index 0000000..e3d85eb
> --- /dev/null
> +++ b/build.sh
> @@ -0,0 +1,12 @@
> +#!/bin/sh
> +
> +SRCDIR=`dirname $0`
> +BUILDDIR="$SRCDIR/build"
> +
> +if [ ! -d "$BUILDDIR" ]; then
> +    mkdir $BUILDDIR
> +fi
> +
> +cd $BUILDDIR
> +cmake -GNinja ..
> +ninja

Hello Christoph,

Have you considered to make this script stop immediately if one of the 
steps fails, e.g. as follows?

mkdir -p "$BUILDDIR" &&
cd build &&
cmake -G Ninja .. &&
ninja

Thanks,

Bart.
--
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

^ permalink raw reply

* Re: Patches for librxe-dev
From: Bart Van Assche @ 2016-10-10 15:49 UTC (permalink / raw)
  To: diegocg-Re5JQEeQqe8AvxtiuMwx3w; +Cc: Henrique Almeida, linux-rdma
In-Reply-To: <CAP_Z8ckRONhy5Fy6VEYbfk5KVa5mbES1wyfPfsEX3fY=LOn=hw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 10/10/16 07:12, Henrique Almeida wrote:
> 2016-10-10 11:00 GMT-03:00 Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>:
>> On 10/10/16 06:49, Henrique Almeida wrote:
>>>
>>> Hello, how can I send patches for SoftRoCE library ? Last week I
>>> tried sending a pull request on github, but it looks like no one is
>>> watching it.
>>
>>
>> Maybe the README of the librxe-dev project should be updated to indicate
>> that that project has been superseded by the rdma-core project and that new
>> contributions should be submitted to the latter project
>> (https://github.com/linux-rdma/rdma-core)?
 >
 > Ok, but I think the SoftRoCE repository is mentioned in
 > kernelnewbies.
 >
 > 
https://kernelnewbies.org/Linux_4.8#head-d5eeeba16221162ce670139e945ab118b2aa772a

Hello Diego,

Do you perhaps have edit rights for that kernel newbies page? If so, can 
you correct the information about the SoftRoCE driver? The SoftRoCE 
driver went upstream in kernel v4.8 so I think the reference to the 
out-of-tree https://github.com/SoftRoCE/rxe-dev kernel driver should be 
removed. And since the https://github.com/SoftRoCE/librxe-dev repository 
has been superseded by the https://github.com/linux-rdma/rdma-core 
repository, please change the reference to https://github.com/SoftRoCE/ 
into https://github.com/linux-rdma/rdma-core.

PS: the linux-rdma mailing list is the mailing list on which the 
SoftRoCE driver was discussed before it was accepted upstream.

Thanks,

Bart.
--
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

^ permalink raw reply

* build failure on linus' latest master branch
From: Steve Wise @ 2016-10-10 15:41 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hey Leon, I hit this trying to compile Linus' latest master branch.
 
 CC [M]  drivers/net/ethernet/mellanox/mlx5/core/pagealloc.o
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function
âreclaim_pages_cmd.clone.0â:
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:347: error: call to
â__compiletime_assert_347â declared with attribute error: BUILD_BUG_ON failed:
__mlx5_bit_off(manage_pages_out, pas[i]) % 64
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function âgive_pagesâ:
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:290: error: call to
â__compiletime_assert_290â declared with attribute error: BUILD_BUG_ON failed:
__mlx5_bit_off(manage_pages_in, pas[i]) % 64
make[5]: *** [drivers/net/ethernet/mellanox/mlx5/core/pagealloc.o] Error 1

Is there a fix for this?

Thanks,

Steve.

--
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

^ permalink raw reply

* capturing the error log from rdma-core
From: Christoph Hellwig @ 2016-10-10 15:30 UTC (permalink / raw)
  To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

Hi Jason,

what's the best way to generate a log of the compiler errors with the
shiny new rdma-core build system?  With make I'd do make 2>err.log
but with the new build system the verbose build output and the errors
are mixed in the same stream, so this isn't possible anymore.

With the fairly large number of warnings from sparse this is rather
annoying.
--
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

^ permalink raw reply

* [PATCH] add a build.sh helper to allow for a one-stop build
From: Christoph Hellwig @ 2016-10-10 15:28 UTC (permalink / raw)
  To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA

This allows for a quick build instead of typing the whole mkdir, cd,
cmake and ninja sequence.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 README.md |  5 +----
 build.sh  | 12 ++++++++++++
 2 files changed, 13 insertions(+), 4 deletions(-)
 create mode 100755 build.sh

diff --git a/README.md b/README.md
index 98ec5a7..2ddecc3 100644
--- a/README.md
+++ b/README.md
@@ -36,10 +36,7 @@ Additional service daemons are provided for:
 This project uses a cmake based build system. Quick start:
 
 ```sh
-$ mkdir build
-$ cd build
-$ cmake -GNinja ..
-$ ninja
+$ sh build.sh
 ```
 
 *build/bin* will contain the sample programs and *build/lib* will contain the
diff --git a/build.sh b/build.sh
new file mode 100755
index 0000000..e3d85eb
--- /dev/null
+++ b/build.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+SRCDIR=`dirname $0`
+BUILDDIR="$SRCDIR/build"
+
+if [ ! -d "$BUILDDIR" ]; then
+    mkdir $BUILDDIR
+fi
+
+cd $BUILDDIR
+cmake -GNinja ..
+ninja
-- 
2.10.1.382.ga23ca1b

--
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

^ permalink raw reply related

* [PATCH] cxgb4: missing dereference in poll_cq
From: Christoph Hellwig @ 2016-10-10 15:27 UTC (permalink / raw)
  To: swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA

Sparse complains about using plain integer as NULL pointer here, but
I suspect we really want to check the value anyway, and Steve
confirmed that's indeed the case.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Acked-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
 providers/cxgb4/cq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/providers/cxgb4/cq.c b/providers/cxgb4/cq.c
index 1ed7dfd..3c8dd26 100644
--- a/providers/cxgb4/cq.c
+++ b/providers/cxgb4/cq.c
@@ -438,7 +438,7 @@ static int poll_cq(struct t4_wq *wq, struct t4_cq *cq, struct t4_cqe *cqe,
 		if (!*cqe_flushed && CQE_STATUS(hw_cqe))
 			dump_cqe(hw_cqe);
 
-		BUG_ON((cqe_flushed == 0) && !SW_CQE(hw_cqe));
+		BUG_ON((*cqe_flushed == 0) && !SW_CQE(hw_cqe));
 		goto proc_cqe;
 	}
 
-- 
2.10.1.382.ga23ca1b

--
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

^ permalink raw reply related

* RE: [PATCH rdma-core 1/5] Pull uninitialized_var into util/compiler.h
From: Steve Wise @ 2016-10-10 15:18 UTC (permalink / raw)
  To: 'Jason Gunthorpe', 'Doug Ledford',
	linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1475879772-29458-2-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>

> The new common definition turns it off for new compilers since
> it is not needed and is too easy to abuse.
> 
> Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>


Reviewed-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>

--
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

^ permalink raw reply

* Re: [PATCH infiniband-diags v2] ibportstate: Fixed switch peer port probing when using DR routing
From: Hal Rosenstock @ 2016-10-10 14:57 UTC (permalink / raw)
  To: Knut Omang, Ira Weiny
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Line Holen, Dag Moxnes
In-Reply-To: <8d3851995d389220a979543740862bd8884cacac.1476089300.git-series.knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>

On 10/10/2016 4:50 AM, Knut Omang wrote:
> From: Dag Moxnes <dag.moxnes-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> 
> ibportstate queries to a remote peer port on a switch using direct
> routing would result in timeouts. The reason for this is that the
> DR path was not correctly constructed.

Should the following be added here to make it clearer:
in case where local LID for switch port 0 is not yet configured.
?

> 
> Signed-off-by: Dag Moxnes <dag.moxnes-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Line Holen <line.holen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>

Reviewed-by: Hal Rosenstock <hal-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
--
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

^ permalink raw reply

* RE: [PULL REQUEST] Please pull rdma.git (tag for-linus)
From: Steve Wise @ 2016-10-10 14:40 UTC (permalink / raw)
  To: 'Linus Torvalds', 'Doug Ledford'; +Cc: 'linux-rdma'
In-Reply-To: <CA+55aFw5tftp1Da5Hs8ks+=hiodZ_NTCH3Z9efPxDVo7h75RAw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

> 
> On Fri, Oct 7, 2016 at 3:24 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > 1) cxgb4 - keep the head version in your tree, my tree and the common
> > ancestor were prior to a refactoring in your tree that moved uld_attach
> > from cxgb4_main.c to cxgb4_uld.c
> 
> Hmm. As far as I can tell, a proper merge also involves adding the line
> 
>         lld->fr_nsmr_tpte_wr_support = adap->params.fr_nsmr_tpte_wr_support;
> 
> to uld_init() in cxgb4_uld.c.
> 
> I did so, and it all seems to build find for me, but I obviously
> cannot do any testing. Somebody with the proper cxgb4 hardware should
> verify.
> 
> Of course, it only affects the very special IB_WR_REG_MR fastpath
> case, so maybe nobody much cares. Adding Steve Wise to the cc, to make
> sure somebody actually tests this.
>

I will test/verify this today.  
 
Steve

--
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

^ permalink raw reply

* Re: Patches for librxe-dev
From: Henrique Almeida @ 2016-10-10 14:12 UTC (permalink / raw)
  To: Bart Van Assche; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4c6c926d-d5a4-7149-c3dc-b0945b134da0-HInyCGIudOg@public.gmane.org>

 Ok, but I think the SoftRoCE repository is mentioned in kernelnewbies.

 https://kernelnewbies.org/Linux_4.8#head-d5eeeba16221162ce670139e945ab118b2aa772a


2016-10-10 11:00 GMT-03:00 Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>:
> On 10/10/16 06:49, Henrique Almeida wrote:
>>
>> Hello, how can I send patches for SoftRoCE library ? Last week I
>> tried sending a pull request on github, but it looks like no one is
>> watching it.
>
>
> Maybe the README of the librxe-dev project should be updated to indicate
> that that project has been superseded by the rdma-core project and that new
> contributions should be submitted to the latter project
> (https://github.com/linux-rdma/rdma-core)?
>
> Bart.
>
--
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

^ permalink raw reply

* Re: switch iwpm to ccan list.h
From: Bart Van Assche @ 2016-10-10 14:07 UTC (permalink / raw)
  To: Christoph Hellwig, Tatyana.E.Nikolova-ral2JQCrhuEAvxtiuMwx3w,
	swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW,
	robert.o.sharp-ral2JQCrhuEAvxtiuMwx3w
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476092514-18188-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>

On 10/10/16 02:41, Christoph Hellwig wrote:
> I've started running sparse on the rdma-core code, and one of the
> worst offenders is the iwpmd list code, so this (untested) patch
> set converts it over to the ccan list.h helpers.  Reviews and
> testing appreciated.

For the whole series:

Reviewed-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
--
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

^ permalink raw reply

* Re: Patches for librxe-dev
From: Bart Van Assche @ 2016-10-10 14:00 UTC (permalink / raw)
  To: Henrique Almeida, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAP_Z8c=zx-DL1yFTZSRy=myQ1n4pqkcfH+Zi1MLDeHPEwDGRQw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 10/10/16 06:49, Henrique Almeida wrote:
> Hello, how can I send patches for SoftRoCE library ? Last week I
> tried sending a pull request on github, but it looks like no one is
> watching it.

Maybe the README of the librxe-dev project should be updated to indicate 
that that project has been superseded by the rdma-core project and that 
new contributions should be submitted to the latter project 
(https://github.com/linux-rdma/rdma-core)?

Bart.

--
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

^ permalink raw reply

* Patches for librxe-dev
From: Henrique Almeida @ 2016-10-10 13:49 UTC (permalink / raw)
  To: linux-rdma-u79uwXL29TY76Z2rM5mHXA

 Hello, how can I send patches for SoftRoCE library ? Last week I
tried sending a pull request on github, but it looks like no one is
watching it.

 Thanks,
--
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

^ permalink raw reply

* Re: [PATCHv12 0/3] rdmacg: IB/core: rdma controller support
From: Parav Pandit @ 2016-10-10 13:32 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Leon Romanovsky, cgroups-u79uwXL29TY76Z2rM5mHXA, linux-rdma,
	Li Zefan, Johannes Weiner, Doug Ledford, Christoph Hellwig,
	Liran Liss, Hefty, Sean, Jason Gunthorpe, Haggai Eran,
	james.l.morris-QHcLZuEGTsvQT0dZR+AlfA, Or Gerlitz, Matan Barak
In-Reply-To: <20161010132014.GD29742-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>

Hi Tejun,

On Mon, Oct 10, 2016 at 6:50 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hello, Parav.
>
> On Mon, Oct 10, 2016 at 06:43:59PM +0530, Parav Pandit wrote:
>> > Also, I don't get what you mean by using percentage and when people
>> > brought up this idea, it always has been stemming from
>> > misunderstanding.  Can you please elaborate how percentage based
>> > proportional control would work?  What would 100% mean when cgroups
>> > can come and go?
>>
>> When 100% is given to one cgroup, all resources of all type can be
>> charged by processes of that cgroup.
>> Resources are stateful resource. So when cgroup goes away, they go
>> back to global pool (or hw).
>> Giving 100% to two cgroups is configuration error anyway (or without config).
>
> That isn't proportional control.  That's using percentage as the unit
> to implement absolute limits.  Proportional control implies work
> conservation.
>
>> As you know weight configuration allows automatic increase/decrease of
>> resource to other cgroups when one of them go away, as opposed to
>> absolute value. How this is going to work in exact terms for stateful
>
> Hmm.... so are you saying that ti'd be work-conserving?
They cannot be work conversing.

> But what does
> it mean to say "30%" and then have it all resources when there are no
> other users.  Also, is it even possible to take back what have already
> been allocated and are in use?
>
Most resources that I know of, and whats described in current
cgroup_rdma.h are not work conversing, therefore it cannot be taken
back.

>> Nop. Thats not true.
>> (a) Every new resource has to be defined in cgroup_rdma.h
>> (b) charge()/uncharge() has to happen by the cgroup for each.
>> (c) Letting drivers do will make things fall apart. There are no APIs
>> exposed either to let drivers know process cgroup either. There is no
>> intention either.
>>
>> (d) ratio means -if adapter has
>> 100 resources of type - A,
>> 80 resource of type - B,
>>
>> 10% for cgroup-1 means,
>> 10 resource of type - A
>> 8 resource of type - B
>
> So, this is not work-conserving.  There's too much confusion here.

Give me some more time, I will think more and take feeback from Leon
and others on
(a) how can we implement or want to implement weight like
functionality for non-work-conversing resource
(b) what could be its acceptable limitations of that interface would be
before we propose you.

At minimum we would need to expose actual value in rdma.max in
subsequent patch, instead of exposing just "max" string. I don't want
to complicate this discussion but similar functionality is needed for
pid controller as well to expose actual value.

>
> Thanks.
>
> --
> tejun
--
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

^ permalink raw reply

* Re: [PATCHv12 0/3] rdmacg: IB/core: rdma controller support
From: Tejun Heo @ 2016-10-10 13:20 UTC (permalink / raw)
  To: Parav Pandit
  Cc: Leon Romanovsky, cgroups-u79uwXL29TY76Z2rM5mHXA, linux-rdma,
	Li Zefan, Johannes Weiner, Doug Ledford, Christoph Hellwig,
	Liran Liss, Hefty, Sean, Jason Gunthorpe, Haggai Eran,
	james.l.morris-QHcLZuEGTsvQT0dZR+AlfA, Or Gerlitz, Matan Barak
In-Reply-To: <CAG53R5V5yE4PsDBjP9BieG_=39M0G1kx-AfBEzWK4LUCxNnYBA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hello, Parav.

On Mon, Oct 10, 2016 at 06:43:59PM +0530, Parav Pandit wrote:
> > Also, I don't get what you mean by using percentage and when people
> > brought up this idea, it always has been stemming from
> > misunderstanding.  Can you please elaborate how percentage based
> > proportional control would work?  What would 100% mean when cgroups
> > can come and go?
>
> When 100% is given to one cgroup, all resources of all type can be
> charged by processes of that cgroup.
> Resources are stateful resource. So when cgroup goes away, they go
> back to global pool (or hw).
> Giving 100% to two cgroups is configuration error anyway (or without config).

That isn't proportional control.  That's using percentage as the unit
to implement absolute limits.  Proportional control implies work
conservation.

> As you know weight configuration allows automatic increase/decrease of
> resource to other cgroups when one of them go away, as opposed to
> absolute value. How this is going to work in exact terms for stateful

Hmm.... so are you saying that ti'd be work-conserving?  But what does
it mean to say "30%" and then have it all resources when there are no
other users.  Also, is it even possible to take back what have already
been allocated and are in use?

> Nop. Thats not true.
> (a) Every new resource has to be defined in cgroup_rdma.h
> (b) charge()/uncharge() has to happen by the cgroup for each.
> (c) Letting drivers do will make things fall apart. There are no APIs
> exposed either to let drivers know process cgroup either. There is no
> intention either.
> 
> (d) ratio means -if adapter has
> 100 resources of type - A,
> 80 resource of type - B,
> 
> 10% for cgroup-1 means,
> 10 resource of type - A
> 8 resource of type - B

So, this is not work-conserving.  There's too much confusion here.

Thanks.

-- 
tejun
--
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

^ permalink raw reply

* [PATCH 6/6] IB/hfi1: Fix integrity check flags default values
From: Dennis Dalessandro @ 2016-10-10 13:14 UTC (permalink / raw)
  To: dledford-H+wXaHxf7aLQT0dZR+AlfA
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Dean Luick, Jakub Pawlak
In-Reply-To: <20161010131249.17586.23789.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org>

From: Jakub Pawlak <jakub.pawlak-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Prevent setting up integrity check flags when module is loaded
with NO_INTEGRITY capability.

Reviewed-by: Dean Luick <dean.luick-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Jakub Pawlak <jakub.pawlak-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/hw/hfi1/hfi.h  |   40 +++++++++++++++++++++++++------------
 drivers/infiniband/hw/hfi1/pio.c  |   13 +++---------
 drivers/infiniband/hw/hfi1/sdma.c |   19 ++----------------
 3 files changed, 32 insertions(+), 40 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/hfi.h b/drivers/infiniband/hw/hfi1/hfi.h
index 7eef11b..3c06d20 100644
--- a/drivers/infiniband/hw/hfi1/hfi.h
+++ b/drivers/infiniband/hw/hfi1/hfi.h
@@ -1848,7 +1848,13 @@ extern struct mutex hfi1_mutex;
 static inline u64 hfi1_pkt_default_send_ctxt_mask(struct hfi1_devdata *dd,
 						  u16 ctxt_type)
 {
-	u64 base_sc_integrity =
+	u64 base_sc_integrity;
+
+	/* No integrity checks if HFI1_CAP_NO_INTEGRITY is set */
+	if (HFI1_CAP_IS_KSET(NO_INTEGRITY))
+		return 0;
+
+	base_sc_integrity =
 	SEND_CTXT_CHECK_ENABLE_DISALLOW_BYPASS_BAD_PKT_LEN_SMASK
 	| SEND_CTXT_CHECK_ENABLE_DISALLOW_PBC_STATIC_RATE_CONTROL_SMASK
 	| SEND_CTXT_CHECK_ENABLE_DISALLOW_TOO_LONG_BYPASS_PACKETS_SMASK
@@ -1863,7 +1869,6 @@ static inline u64 hfi1_pkt_default_send_ctxt_mask(struct hfi1_devdata *dd,
 	| SEND_CTXT_CHECK_ENABLE_CHECK_VL_MAPPING_SMASK
 	| SEND_CTXT_CHECK_ENABLE_CHECK_OPCODE_SMASK
 	| SEND_CTXT_CHECK_ENABLE_CHECK_SLID_SMASK
-	| SEND_CTXT_CHECK_ENABLE_CHECK_JOB_KEY_SMASK
 	| SEND_CTXT_CHECK_ENABLE_CHECK_VL_SMASK
 	| SEND_CTXT_CHECK_ENABLE_CHECK_ENABLE_SMASK;
 
@@ -1872,18 +1877,23 @@ static inline u64 hfi1_pkt_default_send_ctxt_mask(struct hfi1_devdata *dd,
 	else
 		base_sc_integrity |= HFI1_PKT_KERNEL_SC_INTEGRITY;
 
-	if (is_ax(dd))
-		/* turn off send-side job key checks - A0 */
-		return base_sc_integrity &
-		       ~SEND_CTXT_CHECK_ENABLE_CHECK_JOB_KEY_SMASK;
+	/* turn on send-side job key checks if !A0 */
+	if (!is_ax(dd))
+		base_sc_integrity |= SEND_CTXT_CHECK_ENABLE_CHECK_JOB_KEY_SMASK;
+
 	return base_sc_integrity;
 }
 
 static inline u64 hfi1_pkt_base_sdma_integrity(struct hfi1_devdata *dd)
 {
-	u64 base_sdma_integrity =
+	u64 base_sdma_integrity;
+
+	/* No integrity checks if HFI1_CAP_NO_INTEGRITY is set */
+	if (HFI1_CAP_IS_KSET(NO_INTEGRITY))
+		return 0;
+
+	base_sdma_integrity =
 	SEND_DMA_CHECK_ENABLE_DISALLOW_BYPASS_BAD_PKT_LEN_SMASK
-	| SEND_DMA_CHECK_ENABLE_DISALLOW_PBC_STATIC_RATE_CONTROL_SMASK
 	| SEND_DMA_CHECK_ENABLE_DISALLOW_TOO_LONG_BYPASS_PACKETS_SMASK
 	| SEND_DMA_CHECK_ENABLE_DISALLOW_TOO_LONG_IB_PACKETS_SMASK
 	| SEND_DMA_CHECK_ENABLE_DISALLOW_BAD_PKT_LEN_SMASK
@@ -1895,14 +1905,18 @@ static inline u64 hfi1_pkt_base_sdma_integrity(struct hfi1_devdata *dd)
 	| SEND_DMA_CHECK_ENABLE_CHECK_VL_MAPPING_SMASK
 	| SEND_DMA_CHECK_ENABLE_CHECK_OPCODE_SMASK
 	| SEND_DMA_CHECK_ENABLE_CHECK_SLID_SMASK
-	| SEND_DMA_CHECK_ENABLE_CHECK_JOB_KEY_SMASK
 	| SEND_DMA_CHECK_ENABLE_CHECK_VL_SMASK
 	| SEND_DMA_CHECK_ENABLE_CHECK_ENABLE_SMASK;
 
-	if (is_ax(dd))
-		/* turn off send-side job key checks - A0 */
-		return base_sdma_integrity &
-		       ~SEND_DMA_CHECK_ENABLE_CHECK_JOB_KEY_SMASK;
+	if (!HFI1_CAP_IS_KSET(STATIC_RATE_CTRL))
+		base_sdma_integrity |=
+		SEND_DMA_CHECK_ENABLE_DISALLOW_PBC_STATIC_RATE_CONTROL_SMASK;
+
+	/* turn on send-side job key checks if !A0 */
+	if (!is_ax(dd))
+		base_sdma_integrity |=
+			SEND_DMA_CHECK_ENABLE_CHECK_JOB_KEY_SMASK;
+
 	return base_sdma_integrity;
 }
 
diff --git a/drivers/infiniband/hw/hfi1/pio.c b/drivers/infiniband/hw/hfi1/pio.c
index 385e4dc..e60fe3e 100644
--- a/drivers/infiniband/hw/hfi1/pio.c
+++ b/drivers/infiniband/hw/hfi1/pio.c
@@ -668,19 +668,12 @@ void sc_set_cr_threshold(struct send_context *sc, u32 new_threshold)
 void set_pio_integrity(struct send_context *sc)
 {
 	struct hfi1_devdata *dd = sc->dd;
-	u64 reg = 0;
 	u32 hw_context = sc->hw_context;
 	int type = sc->type;
 
-	/*
-	 * No integrity checks if HFI1_CAP_NO_INTEGRITY is set, or if
-	 * we're snooping.
-	 */
-	if (likely(!HFI1_CAP_IS_KSET(NO_INTEGRITY)) &&
-	    dd->hfi1_snoop.mode_flag != HFI1_PORT_SNOOP_MODE)
-		reg = hfi1_pkt_default_send_ctxt_mask(dd, type);
-
-	write_kctxt_csr(dd, hw_context, SC(CHECK_ENABLE), reg);
+	write_kctxt_csr(dd, hw_context,
+			SC(CHECK_ENABLE),
+			hfi1_pkt_default_send_ctxt_mask(dd, type));
 }
 
 static u32 get_buffers_allocated(struct send_context *sc)
diff --git a/drivers/infiniband/hw/hfi1/sdma.c b/drivers/infiniband/hw/hfi1/sdma.c
index 7102a07..1d81cac 100644
--- a/drivers/infiniband/hw/hfi1/sdma.c
+++ b/drivers/infiniband/hw/hfi1/sdma.c
@@ -2009,11 +2009,6 @@ static void sdma_hw_start_up(struct sdma_engine *sde)
 	write_sde_csr(sde, SD(ENG_ERR_CLEAR), reg);
 }
 
-#define CLEAR_STATIC_RATE_CONTROL_SMASK(r) \
-(r &= ~SEND_DMA_CHECK_ENABLE_DISALLOW_PBC_STATIC_RATE_CONTROL_SMASK)
-
-#define SET_STATIC_RATE_CONTROL_SMASK(r) \
-(r |= SEND_DMA_CHECK_ENABLE_DISALLOW_PBC_STATIC_RATE_CONTROL_SMASK)
 /*
  * set_sdma_integrity
  *
@@ -2022,19 +2017,9 @@ static void sdma_hw_start_up(struct sdma_engine *sde)
 static void set_sdma_integrity(struct sdma_engine *sde)
 {
 	struct hfi1_devdata *dd = sde->dd;
-	u64 reg;
-
-	if (unlikely(HFI1_CAP_IS_KSET(NO_INTEGRITY)))
-		return;
-
-	reg = hfi1_pkt_base_sdma_integrity(dd);
-
-	if (HFI1_CAP_IS_KSET(STATIC_RATE_CTRL))
-		CLEAR_STATIC_RATE_CONTROL_SMASK(reg);
-	else
-		SET_STATIC_RATE_CONTROL_SMASK(reg);
 
-	write_sde_csr(sde, SD(CHECK_ENABLE), reg);
+	write_sde_csr(sde, SD(CHECK_ENABLE),
+		      hfi1_pkt_base_sdma_integrity(dd));
 }
 
 static void init_sdma_regs(

--
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

^ permalink raw reply related

* [PATCH 5/6] IB/hfi1: Remove redundant sysfs irq affinity entry
From: Dennis Dalessandro @ 2016-10-10 13:14 UTC (permalink / raw)
  To: dledford-H+wXaHxf7aLQT0dZR+AlfA
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Jianxin Xiong, Tadeusz Struk
In-Reply-To: <20161010131249.17586.23789.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org>

From: Tadeusz Struk <tadeusz.struk-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

The IRQ affinity entry is not needed after the irq notifier patch has been
added to the hfi1 driver.
The irq affinity settings for SDMA engine should be set using the standard
/proc/irq/<N>/ interface.

Reviewed-by: Jianxin Xiong <jianxin.xiong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Tadeusz Struk <tadeusz.struk-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/hw/hfi1/affinity.c |   72 ---------------------------------
 drivers/infiniband/hw/hfi1/affinity.h |    4 --
 drivers/infiniband/hw/hfi1/sysfs.c    |   25 -----------
 3 files changed, 0 insertions(+), 101 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/affinity.c b/drivers/infiniband/hw/hfi1/affinity.c
index a26a9a0..67ea85a 100644
--- a/drivers/infiniband/hw/hfi1/affinity.c
+++ b/drivers/infiniband/hw/hfi1/affinity.c
@@ -775,75 +775,3 @@ void hfi1_put_proc_affinity(int cpu)
 	}
 	mutex_unlock(&affinity->lock);
 }
-
-int hfi1_set_sdma_affinity(struct hfi1_devdata *dd, const char *buf,
-			   size_t count)
-{
-	struct hfi1_affinity_node *entry;
-	cpumask_var_t mask;
-	int ret, i;
-
-	mutex_lock(&node_affinity.lock);
-	entry = node_affinity_lookup(dd->node);
-
-	if (!entry) {
-		ret = -EINVAL;
-		goto unlock;
-	}
-
-	ret = zalloc_cpumask_var(&mask, GFP_KERNEL);
-	if (!ret) {
-		ret = -ENOMEM;
-		goto unlock;
-	}
-
-	ret = cpulist_parse(buf, mask);
-	if (ret)
-		goto out;
-
-	if (!cpumask_subset(mask, cpu_online_mask) || cpumask_empty(mask)) {
-		dd_dev_warn(dd, "Invalid CPU mask\n");
-		ret = -EINVAL;
-		goto out;
-	}
-
-	/* reset the SDMA interrupt affinity details */
-	init_cpu_mask_set(&entry->def_intr);
-	cpumask_copy(&entry->def_intr.mask, mask);
-
-	/* Reassign the affinity for each SDMA interrupt. */
-	for (i = 0; i < dd->num_msix_entries; i++) {
-		struct hfi1_msix_entry *msix;
-
-		msix = &dd->msix_entries[i];
-		if (msix->type != IRQ_SDMA)
-			continue;
-
-		ret = get_irq_affinity(dd, msix);
-
-		if (ret)
-			break;
-	}
-out:
-	free_cpumask_var(mask);
-unlock:
-	mutex_unlock(&node_affinity.lock);
-	return ret ? ret : strnlen(buf, PAGE_SIZE);
-}
-
-int hfi1_get_sdma_affinity(struct hfi1_devdata *dd, char *buf)
-{
-	struct hfi1_affinity_node *entry;
-
-	mutex_lock(&node_affinity.lock);
-	entry = node_affinity_lookup(dd->node);
-
-	if (!entry) {
-		mutex_unlock(&node_affinity.lock);
-		return -EINVAL;
-	}
-
-	cpumap_print_to_pagebuf(true, buf, &entry->def_intr.mask);
-	mutex_unlock(&node_affinity.lock);
-	return strnlen(buf, PAGE_SIZE);
-}
diff --git a/drivers/infiniband/hw/hfi1/affinity.h b/drivers/infiniband/hw/hfi1/affinity.h
index b89ea3c..42e6331 100644
--- a/drivers/infiniband/hw/hfi1/affinity.h
+++ b/drivers/infiniband/hw/hfi1/affinity.h
@@ -102,10 +102,6 @@ int hfi1_get_proc_affinity(int);
 /* Release a CPU used by a user process. */
 void hfi1_put_proc_affinity(int);
 
-int hfi1_get_sdma_affinity(struct hfi1_devdata *dd, char *buf);
-int hfi1_set_sdma_affinity(struct hfi1_devdata *dd, const char *buf,
-			   size_t count);
-
 struct hfi1_affinity_node {
 	int node;
 	struct cpu_mask_set def_intr;
diff --git a/drivers/infiniband/hw/hfi1/sysfs.c b/drivers/infiniband/hw/hfi1/sysfs.c
index edba224..919a547 100644
--- a/drivers/infiniband/hw/hfi1/sysfs.c
+++ b/drivers/infiniband/hw/hfi1/sysfs.c
@@ -49,7 +49,6 @@
 #include "hfi.h"
 #include "mad.h"
 #include "trace.h"
-#include "affinity.h"
 
 /*
  * Start of per-port congestion control structures and support code
@@ -623,27 +622,6 @@ static ssize_t show_tempsense(struct device *device,
 	return ret;
 }
 
-static ssize_t show_sdma_affinity(struct device *device,
-				  struct device_attribute *attr, char *buf)
-{
-	struct hfi1_ibdev *dev =
-		container_of(device, struct hfi1_ibdev, rdi.ibdev.dev);
-	struct hfi1_devdata *dd = dd_from_dev(dev);
-
-	return hfi1_get_sdma_affinity(dd, buf);
-}
-
-static ssize_t store_sdma_affinity(struct device *device,
-				   struct device_attribute *attr,
-				   const char *buf, size_t count)
-{
-	struct hfi1_ibdev *dev =
-		container_of(device, struct hfi1_ibdev, rdi.ibdev.dev);
-	struct hfi1_devdata *dd = dd_from_dev(dev);
-
-	return hfi1_set_sdma_affinity(dd, buf, count);
-}
-
 /*
  * end of per-unit (or driver, in some cases, but replicated
  * per unit) functions
@@ -658,8 +636,6 @@ static DEVICE_ATTR(serial, S_IRUGO, show_serial, NULL);
 static DEVICE_ATTR(boardversion, S_IRUGO, show_boardversion, NULL);
 static DEVICE_ATTR(tempsense, S_IRUGO, show_tempsense, NULL);
 static DEVICE_ATTR(chip_reset, S_IWUSR, NULL, store_chip_reset);
-static DEVICE_ATTR(sdma_affinity, S_IWUSR | S_IRUGO, show_sdma_affinity,
-		   store_sdma_affinity);
 
 static struct device_attribute *hfi1_attributes[] = {
 	&dev_attr_hw_rev,
@@ -670,7 +646,6 @@ static struct device_attribute *hfi1_attributes[] = {
 	&dev_attr_boardversion,
 	&dev_attr_tempsense,
 	&dev_attr_chip_reset,
-	&dev_attr_sdma_affinity,
 };
 
 int hfi1_create_port_files(struct ib_device *ibdev, u8 port_num,

--
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

^ permalink raw reply related

* [PATCH 4/6] IB/rdmavt: rdmavt can handle non aligned page maps
From: Dennis Dalessandro @ 2016-10-10 13:14 UTC (permalink / raw)
  To: dledford-H+wXaHxf7aLQT0dZR+AlfA
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Mike Marciniszyn, Stable
In-Reply-To: <20161010131249.17586.23789.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org>

The initial code for rdmavt carried with it a restriction that was a
vestige from the qib driver, that to dma map a page it had to be less
than a page size. This is not the case on modern hardware, both qib and
hfi1 will be just fine with unaligned map requests.

This fixes a 4.8 regression where by an IPoIB transfer of > PAGE_SIZE
will hang because the dma map page call always fails. This was
introduced after commit 5faba5469522 ("IB/ipoib: Report SG feature
regardless of HW UD CSUM capability") added the capability to use SG by
default. Rather than override this, the HW supports it, so allow SG.

Cc: Stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # 4.8
Reviewed-by: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/sw/rdmavt/dma.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/sw/rdmavt/dma.c b/drivers/infiniband/sw/rdmavt/dma.c
index 01f71ca..f2cefb0 100644
--- a/drivers/infiniband/sw/rdmavt/dma.c
+++ b/drivers/infiniband/sw/rdmavt/dma.c
@@ -90,9 +90,6 @@ static u64 rvt_dma_map_page(struct ib_device *dev, struct page *page,
 	if (WARN_ON(!valid_dma_direction(direction)))
 		return BAD_DMA_ADDRESS;
 
-	if (offset + size > PAGE_SIZE)
-		return BAD_DMA_ADDRESS;
-
 	addr = (u64)page_address(page);
 	if (addr)
 		addr += offset;

--
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

^ permalink raw reply related

* [PATCH 3/6] IB/hfi1: Optimize lkey validation structures
From: Dennis Dalessandro @ 2016-10-10 13:14 UTC (permalink / raw)
  To: dledford-H+wXaHxf7aLQT0dZR+AlfA
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Mike Marciniszyn,
	Sebastian Sanchez
In-Reply-To: <20161010131249.17586.23789.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org>

From: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Profiling shows that the key validation is susceptible
to cache line trading when accessing the lkey table.

Fix by separating out the read mostly fields from the write
fields.   In addition the shift amount, which is function
of the lkey table size, is precomputed and stored with the
table pointer.   Since both the shift and table pointer
are in the same read mostly cacheline, this saves a cache
line in this hot path.

Reviewed-by: Sebastian Sanchez <sebastian.sanchez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/sw/rdmavt/mr.c |   10 +++++-----
 include/rdma/rdmavt_mr.h          |   10 +++++++---
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/infiniband/sw/rdmavt/mr.c b/drivers/infiniband/sw/rdmavt/mr.c
index 46b6497..4acf179 100644
--- a/drivers/infiniband/sw/rdmavt/mr.c
+++ b/drivers/infiniband/sw/rdmavt/mr.c
@@ -84,6 +84,7 @@ int rvt_driver_mr_init(struct rvt_dev_info *rdi)
 		lkey_table_size = rdi->dparms.lkey_table_size;
 	}
 	rdi->lkey_table.max = 1 << lkey_table_size;
+	rdi->lkey_table.shift = 32 - lkey_table_size;
 	lk_tab_size = rdi->lkey_table.max * sizeof(*rdi->lkey_table.table);
 	rdi->lkey_table.table = (struct rvt_mregion __rcu **)
 			       vmalloc_node(lk_tab_size, rdi->dparms.node);
@@ -774,7 +775,6 @@ int rvt_lkey_ok(struct rvt_lkey_table *rkt, struct rvt_pd *pd,
 	struct rvt_mregion *mr;
 	unsigned n, m;
 	size_t off;
-	struct rvt_dev_info *dev = ib_to_rvt(pd->ibpd.device);
 
 	/*
 	 * We use LKEY == zero for kernel virtual addresses
@@ -782,6 +782,8 @@ int rvt_lkey_ok(struct rvt_lkey_table *rkt, struct rvt_pd *pd,
 	 */
 	rcu_read_lock();
 	if (sge->lkey == 0) {
+		struct rvt_dev_info *dev = ib_to_rvt(pd->ibpd.device);
+
 		if (pd->user)
 			goto bail;
 		mr = rcu_dereference(dev->dma_mr);
@@ -798,8 +800,7 @@ int rvt_lkey_ok(struct rvt_lkey_table *rkt, struct rvt_pd *pd,
 		isge->n = 0;
 		goto ok;
 	}
-	mr = rcu_dereference(
-		rkt->table[(sge->lkey >> (32 - dev->dparms.lkey_table_size))]);
+	mr = rcu_dereference(rkt->table[sge->lkey >> rkt->shift]);
 	if (unlikely(!mr || atomic_read(&mr->lkey_invalid) ||
 		     mr->lkey != sge->lkey || mr->pd != &pd->ibpd))
 		goto bail;
@@ -899,8 +900,7 @@ int rvt_rkey_ok(struct rvt_qp *qp, struct rvt_sge *sge,
 		goto ok;
 	}
 
-	mr = rcu_dereference(
-		rkt->table[(rkey >> (32 - dev->dparms.lkey_table_size))]);
+	mr = rcu_dereference(rkt->table[rkey >> rkt->shift]);
 	if (unlikely(!mr || atomic_read(&mr->lkey_invalid) ||
 		     mr->lkey != rkey || qp->ibqp.pd != mr->pd))
 		goto bail;
diff --git a/include/rdma/rdmavt_mr.h b/include/rdma/rdmavt_mr.h
index 6b3c6c8..de59de2 100644
--- a/include/rdma/rdmavt_mr.h
+++ b/include/rdma/rdmavt_mr.h
@@ -90,11 +90,15 @@ struct rvt_mregion {
 #define RVT_MAX_LKEY_TABLE_BITS 23
 
 struct rvt_lkey_table {
-	spinlock_t lock; /* protect changes in this struct */
-	u32 next;               /* next unused index (speeds search) */
-	u32 gen;                /* generation count */
+	/* read mostly fields */
 	u32 max;                /* size of the table */
+	u32 shift;              /* lkey/rkey shift */
 	struct rvt_mregion __rcu **table;
+	/* writeable fields */
+	/* protect changes in this struct */
+	spinlock_t lock ____cacheline_aligned_in_smp;
+	u32 next;               /* next unused index (speeds search) */
+	u32 gen;                /* generation count */
 };
 
 /*

--
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

^ permalink raw reply related

* [PATCH 2/6] IB/hfi1: Inline sdma_txclean() for verbs pio
From: Dennis Dalessandro @ 2016-10-10 13:14 UTC (permalink / raw)
  To: dledford-H+wXaHxf7aLQT0dZR+AlfA
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Mike Marciniszyn,
	Sebastian Sanchez
In-Reply-To: <20161010131249.17586.23789.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org>

From: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Short circuit sdma_txclean() by adding an __sdma_txclean()
that is only called when the tx has sdma mappings.

Convert internal calls to __sdma_txclean().

This removes a call from the critical path.

Reviewed-by: Sebastian Sanchez <sebastian.sanchez-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/hw/hfi1/sdma.c |   18 +++++++++---------
 drivers/infiniband/hw/hfi1/sdma.h |   12 +++++++++---
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/sdma.c b/drivers/infiniband/hw/hfi1/sdma.c
index fd39bca..7102a07 100644
--- a/drivers/infiniband/hw/hfi1/sdma.c
+++ b/drivers/infiniband/hw/hfi1/sdma.c
@@ -375,7 +375,7 @@ static inline void complete_tx(struct sdma_engine *sde,
 			   sde->head_sn, tx->sn);
 	sde->head_sn++;
 #endif
-	sdma_txclean(sde->dd, tx);
+	__sdma_txclean(sde->dd, tx);
 	if (complete)
 		(*complete)(tx, res);
 	if (wait && iowait_sdma_dec(wait))
@@ -1643,7 +1643,7 @@ static inline u8 ahg_mode(struct sdma_txreq *tx)
 }
 
 /**
- * sdma_txclean() - clean tx of mappings, descp *kmalloc's
+ * __sdma_txclean() - clean tx of mappings, descp *kmalloc's
  * @dd: hfi1_devdata for unmapping
  * @tx: tx request to clean
  *
@@ -1653,7 +1653,7 @@ static inline u8 ahg_mode(struct sdma_txreq *tx)
  * The code can be called multiple times without issue.
  *
  */
-void sdma_txclean(
+void __sdma_txclean(
 	struct hfi1_devdata *dd,
 	struct sdma_txreq *tx)
 {
@@ -3080,7 +3080,7 @@ static int _extend_sdma_tx_descs(struct hfi1_devdata *dd, struct sdma_txreq *tx)
 		tx->descp[i] = tx->descs[i];
 	return 0;
 enomem:
-	sdma_txclean(dd, tx);
+	__sdma_txclean(dd, tx);
 	return -ENOMEM;
 }
 
@@ -3109,14 +3109,14 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata *dd, struct sdma_txreq *tx,
 
 	rval = _extend_sdma_tx_descs(dd, tx);
 	if (rval) {
-		sdma_txclean(dd, tx);
+		__sdma_txclean(dd, tx);
 		return rval;
 	}
 
 	/* If coalesce buffer is allocated, copy data into it */
 	if (tx->coalesce_buf) {
 		if (type == SDMA_MAP_NONE) {
-			sdma_txclean(dd, tx);
+			__sdma_txclean(dd, tx);
 			return -EINVAL;
 		}
 
@@ -3124,7 +3124,7 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata *dd, struct sdma_txreq *tx,
 			kvaddr = kmap(page);
 			kvaddr += offset;
 		} else if (WARN_ON(!kvaddr)) {
-			sdma_txclean(dd, tx);
+			__sdma_txclean(dd, tx);
 			return -EINVAL;
 		}
 
@@ -3154,7 +3154,7 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata *dd, struct sdma_txreq *tx,
 				      DMA_TO_DEVICE);
 
 		if (unlikely(dma_mapping_error(&dd->pcidev->dev, addr))) {
-			sdma_txclean(dd, tx);
+			__sdma_txclean(dd, tx);
 			return -ENOSPC;
 		}
 
@@ -3196,7 +3196,7 @@ int _pad_sdma_tx_descs(struct hfi1_devdata *dd, struct sdma_txreq *tx)
 	if ((unlikely(tx->num_desc == tx->desc_limit))) {
 		rval = _extend_sdma_tx_descs(dd, tx);
 		if (rval) {
-			sdma_txclean(dd, tx);
+			__sdma_txclean(dd, tx);
 			return rval;
 		}
 	}
diff --git a/drivers/infiniband/hw/hfi1/sdma.h b/drivers/infiniband/hw/hfi1/sdma.h
index 56257ea..21f1e28 100644
--- a/drivers/infiniband/hw/hfi1/sdma.h
+++ b/drivers/infiniband/hw/hfi1/sdma.h
@@ -667,7 +667,13 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata *dd, struct sdma_txreq *tx,
 			   int type, void *kvaddr, struct page *page,
 			   unsigned long offset, u16 len);
 int _pad_sdma_tx_descs(struct hfi1_devdata *, struct sdma_txreq *);
-void sdma_txclean(struct hfi1_devdata *, struct sdma_txreq *);
+void __sdma_txclean(struct hfi1_devdata *, struct sdma_txreq *);
+
+static inline void sdma_txclean(struct hfi1_devdata *dd, struct sdma_txreq *tx)
+{
+	if (tx->num_desc)
+		__sdma_txclean(dd, tx);
+}
 
 /* helpers used by public routines */
 static inline void _sdma_close_tx(struct hfi1_devdata *dd,
@@ -753,7 +759,7 @@ static inline int sdma_txadd_page(
 		       DMA_TO_DEVICE);
 
 	if (unlikely(dma_mapping_error(&dd->pcidev->dev, addr))) {
-		sdma_txclean(dd, tx);
+		__sdma_txclean(dd, tx);
 		return -ENOSPC;
 	}
 
@@ -834,7 +840,7 @@ static inline int sdma_txadd_kvaddr(
 		       DMA_TO_DEVICE);
 
 	if (unlikely(dma_mapping_error(&dd->pcidev->dev, addr))) {
-		sdma_txclean(dd, tx);
+		__sdma_txclean(dd, tx);
 		return -ENOSPC;
 	}
 

--
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

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox