* Re: [PATCH RFC v2 1/3] rdma_cm: add rdma_reject_msg() helper function
From: Sagi Grimberg @ 2016-10-21 21:43 UTC (permalink / raw)
To: Steve Wise, 'Christoph Hellwig'
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, axboe-b10kYP2dOMg
In-Reply-To: <005d01d22ba4$672effd0$358cff70$@opengridcomputing.com>
Looks good to me either way,
Reviewed-by: Sagi Grimberg <sagi-NQWnxTmZq1alnMjI0IkVqw@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: Introduction of libqedr to the Consolidated Userspace RDMA Library Repo
From: Doug Ledford @ 2016-10-21 20:52 UTC (permalink / raw)
To: Amrani, Ram, Jason Gunthorpe
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Elior, Ariel,
Kalderon, Michal, Borundia, Rajesh
In-Reply-To: <30ac13b7-f9e7-e08f-5f12-e6517117f2ba-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1501 bytes --]
On 10/21/2016 4:10 PM, Doug Ledford wrote:
> On 10/20/2016 2:16 AM, Amrani, Ram wrote:
>>> You also need to make sure it builds, Travis says the 32 bit builds are no good
>>> (look at the pull request and click on the red X)
>>
>> That's true, I haven't checked those. I will.
>>
>>> The github process from here is to make changes and then update your branch
>>> on your github, that will reflect in the pull request. Eg you can immediately fix
>>> the 32 bit issues and see that travis goes green.
>>
>> OK
>>
>>> I left some minor notes for you on github, the build system stuff looks fine to
>>> me, and I didn't notice anything too unusual in a casual browse. Didn't check if
>>> the code was any good..
>>
>> OK
>
> I saw you fixed up the things Jason had referred to. I merged your
> request, but there is still an outstanding build issue (I couldn't get
> to the travis logs to see it at the time, but Jason let me know it was a
> real issue, not an issue with Travis CI). Please get that fixed up as
> soon as possible. As soon as the build fix is available we need to get
> it merged in too.
>
>
And for those that don't know, the Internet is down for many of us today
:-/. A DDoS has been undergoing against Level3 Network's distributed
DNS system, taking out many services, including github.com.
http://thehackernews.com/2016/10/dyn-dns-ddos.html
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: Introduction of libqedr to the Consolidated Userspace RDMA Library Repo
From: Doug Ledford @ 2016-10-21 20:10 UTC (permalink / raw)
To: Amrani, Ram, Jason Gunthorpe
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Elior, Ariel,
Kalderon, Michal, Borundia, Rajesh
In-Reply-To: <SN1PR07MB22076159E666B8836BBB3455F8D50-mikhvbZlbf8TSoR2DauN2+FPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1162 bytes --]
On 10/20/2016 2:16 AM, Amrani, Ram wrote:
>> You also need to make sure it builds, Travis says the 32 bit builds are no good
>> (look at the pull request and click on the red X)
>
> That's true, I haven't checked those. I will.
>
>> The github process from here is to make changes and then update your branch
>> on your github, that will reflect in the pull request. Eg you can immediately fix
>> the 32 bit issues and see that travis goes green.
>
> OK
>
>> I left some minor notes for you on github, the build system stuff looks fine to
>> me, and I didn't notice anything too unusual in a casual browse. Didn't check if
>> the code was any good..
>
> OK
I saw you fixed up the things Jason had referred to. I merged your
request, but there is still an outstanding build issue (I couldn't get
to the travis logs to see it at the time, but Jason let me know it was a
real issue, not an issue with Travis CI). Please get that fixed up as
soon as possible. As soon as the build fix is available we need to get
it merged in too.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] build: Fix build script to use correct cmake cmd
From: Jason Gunthorpe @ 2016-10-21 19:30 UTC (permalink / raw)
To: Doug Ledford; +Cc: Dennis Dalessandro, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <9745f6c7-8d09-8bed-d04c-78f610330ead-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Fri, Oct 21, 2016 at 03:03:23PM -0400, Doug Ledford wrote:
> According to github, this change broke the travis CI build on your pull
> request when the previous patches all worked. However, travis is down
> right now, so I suspect this didn't *actually* break it, that the travis
> CI was down anyway and github logged a failure.
Yes, travis does not use build.sh
Maybe this is a good time to ask if anyone is interested in the docker
stuff I have - eg should I make it pushable? It is easy to use, but
you need to have docker installed.
There are several other container/chroot/docker based toolkits out
there for doing this sort of work, but I haven't studied that area in
a while to see if there is something workable.
The docker script is able to run almost-travis locally, as well as do
clean package builds for all distros.
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] build: Fix build script to use correct cmake cmd
From: Doug Ledford @ 2016-10-21 19:03 UTC (permalink / raw)
To: Jason Gunthorpe, Dennis Dalessandro; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161021180523.GA554-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 964 bytes --]
On 10/21/2016 2:05 PM, Jason Gunthorpe wrote:
> On Fri, Oct 21, 2016 at 10:27:28AM -0700, Dennis Dalessandro wrote:
>> The build script does not use the variable it sets up for cmake. Fix it
>> so it does.
>
> Yep, my bad. I put this with the other minor fixes that came by
> lately:
>
> https://github.com/linux-rdma/rdma-core/pull/25
>
> 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
>
According to github, this change broke the travis CI build on your pull
request when the previous patches all worked. However, travis is down
right now, so I suspect this didn't *actually* break it, that the travis
CI was down anyway and github logged a failure.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] build: Fix build script to use correct cmake cmd
From: Jason Gunthorpe @ 2016-10-21 18:05 UTC (permalink / raw)
To: Dennis Dalessandro; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161021172728.27367.86783.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org>
On Fri, Oct 21, 2016 at 10:27:28AM -0700, Dennis Dalessandro wrote:
> The build script does not use the variable it sets up for cmake. Fix it
> so it does.
Yep, my bad. I put this with the other minor fixes that came by
lately:
https://github.com/linux-rdma/rdma-core/pull/25
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 v6 00/16] Add Paravirtual RDMA Driver
From: Adit Ranadive @ 2016-10-21 17:49 UTC (permalink / raw)
To: Leon Romanovsky
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
pv-drivers-pghWNbHTmq7QT0dZR+AlfA, jhansen-pghWNbHTmq7QT0dZR+AlfA,
asarwade-pghWNbHTmq7QT0dZR+AlfA,
georgezhang-pghWNbHTmq7QT0dZR+AlfA,
bryantan-pghWNbHTmq7QT0dZR+AlfA
In-Reply-To: <20161005134421.GI9282-2ukJVAZIZ/Y@public.gmane.org>
On Wed, Oct 05, 2016 at 4:44:21PM +0300, Leon Romanovsky wrote:
> On Sun, Oct 02, 2016 at 07:10:20PM -0700, Adit Ranadive wrote:
<snip>
> >
> > ---
> > Adit Ranadive (16):
> > vmxnet3: Move PCI Id to pci_ids.h
> > IB/pvrdma: Add user-level shared functions
> > IB/pvrdma: Add functions for ring traversal
> > IB/pvrdma: Add the paravirtual RDMA device specification
> > IB/pvrdma: Add functions for Verbs support
> > IB/pvrdma: Add paravirtual rdma device
> > IB/pvrdma: Add helper functions
> > IB/pvrdma: Add device command support
> > IB/pvrdma: Add support for Completion Queues
> > IB/pvrdma: Add UAR support
> > IB/pvrdma: Add support for memory regions
> > IB/pvrdma: Add Queue Pair support
> > IB/pvrdma: Add the main driver module for PVRDMA
> > IB/pvrdma: Add Kconfig and Makefile
> > IB: Add PVRDMA driver
> > MAINTAINERS: Update for PVRDMA driver
> >
> > MAINTAINERS | 7 +
> > drivers/infiniband/Kconfig | 1 +
> > drivers/infiniband/hw/Makefile | 1 +
> > drivers/infiniband/hw/pvrdma/Kconfig | 7 +
> > drivers/infiniband/hw/pvrdma/Makefile | 3 +
> > drivers/infiniband/hw/pvrdma/pvrdma.h | 474 ++++++++++
> > drivers/infiniband/hw/pvrdma/pvrdma_cmd.c | 119 +++
> > drivers/infiniband/hw/pvrdma/pvrdma_cq.c | 425 +++++++++
> > drivers/infiniband/hw/pvrdma/pvrdma_dev_api.h | 586 ++++++++++++
> > drivers/infiniband/hw/pvrdma/pvrdma_doorbell.c | 127 +++
> > drivers/infiniband/hw/pvrdma/pvrdma_main.c | 1211 ++++++++++++++++++++++++
> > drivers/infiniband/hw/pvrdma/pvrdma_misc.c | 304 ++++++
> > drivers/infiniband/hw/pvrdma/pvrdma_mr.c | 334 +++++++
> > drivers/infiniband/hw/pvrdma/pvrdma_qp.c | 972 +++++++++++++++++++
> > drivers/infiniband/hw/pvrdma/pvrdma_ring.h | 131 +++
> > drivers/infiniband/hw/pvrdma/pvrdma_verbs.c | 577 +++++++++++
> > drivers/infiniband/hw/pvrdma/pvrdma_verbs.h | 435 +++++++++
> > drivers/net/vmxnet3/vmxnet3_int.h | 3 +-
> > include/linux/pci_ids.h | 1 +
> > include/uapi/rdma/Kbuild | 2 +
> > include/uapi/rdma/pvrdma-abi.h | 289 ++++++
> > 21 files changed, 6007 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/infiniband/hw/pvrdma/Kconfig
> > create mode 100644 drivers/infiniband/hw/pvrdma/Makefile
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma.h
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_cmd.c
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_cq.c
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_dev_api.h
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_doorbell.c
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_main.c
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_misc.c
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_mr.c
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_qp.c
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_ring.h
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_verbs.c
> > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_verbs.h
> > create mode 100644 include/uapi/rdma/pvrdma-abi.h
>
> Except patch 02, looks good to me.
> Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Thanks
Doug, have you had a chance to look at this patch series?
Since this didnt make it into 4.9 what are your plans for
this patch series?
Thanks to Yuval, Leon who have already reviewed these patches.
The PCI related change was also acked by Bjorn[1].
Thanks,
Adit
[1] http://marc.info/?l=linux-rdma&m=147370089824083&w=2
--
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] build: Fix build script to use correct cmake cmd
From: Dennis Dalessandro @ 2016-10-21 17:27 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
The build script does not use the variable it sets up for cmake. Fix it
so it does.
Signed-off-by: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
build.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/build.sh b/build.sh
index 9006030..10518d8 100755
--- a/build.sh
+++ b/build.sh
@@ -23,9 +23,9 @@ fi
cd "$BUILDDIR"
if [ "x$NINJA" == "x" ]; then
- cmake ..
+ $CMAKE ..
make
else
- cmake -GNinja ..
+ $CMAKE -GNinja ..
$NINJA
fi
--
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 net-next v2 7/9] net: use core MTU range checking in misc drivers
From: Sebastian Reichel @ 2016-10-21 16:22 UTC (permalink / raw)
To: Jarod Wilson
Cc: linux-kernel, netdev, linux-rdma, Stefan Richter, Faisal Latif,
Cliff Whickman, Robin Holt, Jes Sorensen, Marek Lindner,
Simon Wunderlich, Antonio Quartulli, Sathya Prakash, Chaitra P B,
Suganath Prabu Subramani, MPT-FusionLinux.pdl, Felipe Balbi,
Arvid Brodin, Remi Denis-Courmont
In-Reply-To: <20161020175524.6184-8-jarod@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 228 bytes --]
Hi,
On Thu, Oct 20, 2016 at 01:55:22PM -0400, Jarod Wilson wrote:
> hsi/clients/ssi_protocol:
> - use core MTU range checking
> - remove now redundant ssip_pn_set_mtu
Acked-By: Sebastian Reichel <sre@kernel.org>
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v2 2/3] rdma_cm: add rdma_consumer_reject() helper function
From: Parav Pandit @ 2016-10-21 15:50 UTC (permalink / raw)
To: Steve Wise
Cc: Christoph Hellwig, Doug Ledford, Hefty, Sean, linux-rdma,
Bart Van Assche, linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, axboe-b10kYP2dOMg
In-Reply-To: <005f01d22ba4$aeadeab0$0c09c010$@opengridcomputing.com>
On Fri, Oct 21, 2016 at 7:39 PM, Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> wrote:
>>
>> On Thu, Oct 20, 2016 at 03:40:26PM -0700, Steve Wise wrote:
>> > Return true if the peer consumer application rejected the
>> > connection attempt.
>> >
>> > Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>> > ---
>> > drivers/infiniband/core/cma.c | 13 +++++++++++++
>> > include/rdma/ib_cm.h | 9 +++++++++
>> > include/rdma/iw_cm.h | 9 +++++++++
>> > include/rdma/rdma_cm.h | 6 ++++++
>> > 4 files changed, 37 insertions(+)
>> >
>> > diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
>> > index 7cc7346..4ec16a3 100644
>> > --- a/drivers/infiniband/core/cma.c
>> > +++ b/drivers/infiniband/core/cma.c
>> > @@ -114,6 +114,19 @@ const char *__attribute_const__
>> rdma_reject_msg(struct rdma_cm_id *id,
>> > }
>> > EXPORT_SYMBOL(rdma_reject_msg);
>> >
>> > +bool rdma_consumer_reject(struct rdma_cm_id *id, int reason)
>> > +{
>> > + if (rdma_ib_or_roce(id->device, id->port_num))
>> > + return ib_consumer_reject(reason);
>> > +
>> > + if (rdma_protocol_iwarp(id->device, id->port_num))
>> > + return iw_consumer_reject(reason);
>> > +
>> > + /* FIXME should we WARN_ONCE() here? */
>> > + return false;
>>
>> Yes. Also I'd just inline the ib_consumer_reject and iw_consumer_reject
>> helpers here.
>>
>> Aso wouldn't it be better named rdma_consumer_is_reject or similar
>> given that we don't reject anything here, but check if the request
>> has been rejected?
>
> How about rdma_rejected_by_consumer()?
>
How about rdma_reject_by_ulp()?
We have ulp directory holding iser, srp etc.
--
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 RFC v2 2/3] rdma_cm: add rdma_consumer_reject() helper function
From: Steve Wise @ 2016-10-21 14:09 UTC (permalink / raw)
To: 'Christoph Hellwig'
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, axboe-b10kYP2dOMg
In-Reply-To: <20161021121428.GB17028-jcswGhMUV9g@public.gmane.org>
>
> On Thu, Oct 20, 2016 at 03:40:26PM -0700, Steve Wise wrote:
> > Return true if the peer consumer application rejected the
> > connection attempt.
> >
> > Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
> > ---
> > drivers/infiniband/core/cma.c | 13 +++++++++++++
> > include/rdma/ib_cm.h | 9 +++++++++
> > include/rdma/iw_cm.h | 9 +++++++++
> > include/rdma/rdma_cm.h | 6 ++++++
> > 4 files changed, 37 insertions(+)
> >
> > diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
> > index 7cc7346..4ec16a3 100644
> > --- a/drivers/infiniband/core/cma.c
> > +++ b/drivers/infiniband/core/cma.c
> > @@ -114,6 +114,19 @@ const char *__attribute_const__
> rdma_reject_msg(struct rdma_cm_id *id,
> > }
> > EXPORT_SYMBOL(rdma_reject_msg);
> >
> > +bool rdma_consumer_reject(struct rdma_cm_id *id, int reason)
> > +{
> > + if (rdma_ib_or_roce(id->device, id->port_num))
> > + return ib_consumer_reject(reason);
> > +
> > + if (rdma_protocol_iwarp(id->device, id->port_num))
> > + return iw_consumer_reject(reason);
> > +
> > + /* FIXME should we WARN_ONCE() here? */
> > + return false;
>
> Yes. Also I'd just inline the ib_consumer_reject and iw_consumer_reject
> helpers here.
>
> Aso wouldn't it be better named rdma_consumer_is_reject or similar
> given that we don't reject anything here, but check if the request
> has been rejected?
How about rdma_rejected_by_consumer()?
--
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 RFC v2 1/3] rdma_cm: add rdma_reject_msg() helper function
From: Steve Wise @ 2016-10-21 14:07 UTC (permalink / raw)
To: 'Christoph Hellwig'
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, axboe-b10kYP2dOMg
In-Reply-To: <20161021121234.GA17028-jcswGhMUV9g@public.gmane.org>
>
> > +const char *__attribute_const__ ib_reject_msg(int reason)
> > +{
> > + size_t index = reason;
> > +
> > + return (index < ARRAY_SIZE(ib_rej_reason_strs) &&
> > + ib_rej_reason_strs[index]) ?
> > + ib_rej_reason_strs[index] : "unrecognized reason";
> > +}
> > +EXPORT_SYMBOL(ib_reject_msg);
>
> This looks a bit odd, why not something like:
>
> const char *__attribute_const__ ib_reject_msg(int reason)
> {
> if (reason >= ARRAY_SIZE(ib_rej_reason_strs) ||
> !ib_rej_reason_strs[reason])
> return "unrecognized reason";
> return ib_rej_reason_strs[reason];
> }
>
I copy/pasted from rdma_event_msg().
> > +const char *__attribute_const__ iw_reject_msg(int reason)
> > +{
> > + size_t index = -reason;
> > +
> > + /* iWARP uses negative errnos */
> > + index = -index;
> > + return (index < ARRAY_SIZE(iw_rej_reason_strs) &&
> > + iw_rej_reason_strs[index]) ?
> > + iw_rej_reason_strs[index] : "unrecognized reason";
> > +}
> > +EXPORT_SYMBOL(iw_reject_msg);
>
> Same here:
>
> const char *__attribute_const__ iw_reject_msg(int reason)
> {
> /* iWARP uses negative errnos */
> reason = -reason;
>
> if (reason >= ARRAY_SIZE(iw_rej_reason_strs) ||
> !iw_rej_reason_strs[reason])
> return "unrecognized reason";
> return iw_rej_reason_strs[reason];
> }
>
> Otherwise this looks good and very useful to me.
I will refactor as you suggest. You proposed logic is slightly more readable to
me...
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: [PATCH RFC v2 3/3] nvme-rdma: use rdma_reject_msg() to log connection rejects
From: Christoph Hellwig @ 2016-10-21 12:23 UTC (permalink / raw)
To: Steve Wise
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, hch-jcswGhMUV9g, axboe-b10kYP2dOMg
In-Reply-To: <60243a2ce17e08cdc93600b9998698dbd7f83306.1477003235.git.swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
On Thu, Oct 20, 2016 at 03:40:29PM -0700, Steve Wise wrote:
> @@ -1237,18 +1237,22 @@ out_destroy_queue_ib:
> static int nvme_rdma_conn_rejected(struct nvme_rdma_queue *queue,
> struct rdma_cm_event *ev)
> {
> + struct rdma_cm_id *cm_id = queue->cm_id;
> + int rdma_status = ev->status;
> + short nvme_status = -1;
> +
> + if (rdma_consumer_reject(cm_id, rdma_status) &&
> + ev->param.conn.private_data_len) {
> struct nvme_rdma_cm_rej *rej =
> (struct nvme_rdma_cm_rej *)ev->param.conn.private_data;
Given the nasty casting issues in the current RDMA/CM API maybe we should
actually expand the scope of the rdma_consumer_reject helper to include
the above check, e.g. check that there is a private data len and then
return a pointer to the private data?
Something like
static int nvme_rdma_conn_rejected(struct nvme_rdma_queue *queue,
struct rdma_cm_event *ev)
{
struct rdma_cm_id *cm_id = queue->cm_id;
struct nvme_rdma_cm_rej *rej
short nvme_status = -1;
rej = rdma_cm_reject_message(ev);
if (rej)
nvme_status = le16_to_cpu(rej->sts);
>
> + dev_err(queue->ctrl->ctrl.device, "Connect rejected: status %d (%s) "
> + "nvme status %d.\n", rdma_status,
> + rdma_reject_msg(cm_id, rdma_status), nvme_status);
And while we're pretty printing the rest it would be nice to pretty
print the NVMe status here as well.
--
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 RFC v2 2/3] rdma_cm: add rdma_consumer_reject() helper function
From: Christoph Hellwig @ 2016-10-21 12:14 UTC (permalink / raw)
To: Steve Wise
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, hch-jcswGhMUV9g, axboe-b10kYP2dOMg
In-Reply-To: <cb135696be86c21c144ef35a4d6f7f71394a3627.1477003235.git.swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
On Thu, Oct 20, 2016 at 03:40:26PM -0700, Steve Wise wrote:
> Return true if the peer consumer application rejected the
> connection attempt.
>
> Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
> ---
> drivers/infiniband/core/cma.c | 13 +++++++++++++
> include/rdma/ib_cm.h | 9 +++++++++
> include/rdma/iw_cm.h | 9 +++++++++
> include/rdma/rdma_cm.h | 6 ++++++
> 4 files changed, 37 insertions(+)
>
> diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
> index 7cc7346..4ec16a3 100644
> --- a/drivers/infiniband/core/cma.c
> +++ b/drivers/infiniband/core/cma.c
> @@ -114,6 +114,19 @@ const char *__attribute_const__ rdma_reject_msg(struct rdma_cm_id *id,
> }
> EXPORT_SYMBOL(rdma_reject_msg);
>
> +bool rdma_consumer_reject(struct rdma_cm_id *id, int reason)
> +{
> + if (rdma_ib_or_roce(id->device, id->port_num))
> + return ib_consumer_reject(reason);
> +
> + if (rdma_protocol_iwarp(id->device, id->port_num))
> + return iw_consumer_reject(reason);
> +
> + /* FIXME should we WARN_ONCE() here? */
> + return false;
Yes. Also I'd just inline the ib_consumer_reject and iw_consumer_reject
helpers here.
Aso wouldn't it be better named rdma_consumer_is_reject or similar
given that we don't reject anything here, but check if the request
has been rejected?
--
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 RFC v2 1/3] rdma_cm: add rdma_reject_msg() helper function
From: Christoph Hellwig @ 2016-10-21 12:12 UTC (permalink / raw)
To: Steve Wise
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, hch-jcswGhMUV9g, axboe-b10kYP2dOMg
In-Reply-To: <1360f08b7c25f3befcd6836b47af81e2ecb51b75.1477003235.git.swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
> +const char *__attribute_const__ ib_reject_msg(int reason)
> +{
> + size_t index = reason;
> +
> + return (index < ARRAY_SIZE(ib_rej_reason_strs) &&
> + ib_rej_reason_strs[index]) ?
> + ib_rej_reason_strs[index] : "unrecognized reason";
> +}
> +EXPORT_SYMBOL(ib_reject_msg);
This looks a bit odd, why not something like:
const char *__attribute_const__ ib_reject_msg(int reason)
{
if (reason >= ARRAY_SIZE(ib_rej_reason_strs) ||
!ib_rej_reason_strs[reason])
return "unrecognized reason";
return ib_rej_reason_strs[reason];
}
> +const char *__attribute_const__ iw_reject_msg(int reason)
> +{
> + size_t index = -reason;
> +
> + /* iWARP uses negative errnos */
> + index = -index;
> + return (index < ARRAY_SIZE(iw_rej_reason_strs) &&
> + iw_rej_reason_strs[index]) ?
> + iw_rej_reason_strs[index] : "unrecognized reason";
> +}
> +EXPORT_SYMBOL(iw_reject_msg);
Same here:
const char *__attribute_const__ iw_reject_msg(int reason)
{
/* iWARP uses negative errnos */
reason = -reason;
if (reason >= ARRAY_SIZE(iw_rej_reason_strs) ||
!iw_rej_reason_strs[reason])
return "unrecognized reason";
return iw_rej_reason_strs[reason];
}
Otherwise this looks good and very useful to me.
--
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 0/3] iopmem : A block device for PCIe memory
From: Dave Chinner @ 2016-10-21 11:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Stephen Bates, Dan Williams, linux-kernel@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-rdma, linux-block, Linux MM,
Ross Zwisler, Matthew Wilcox, jgunthorpe, haggaie, Jens Axboe,
Jonathan Corbet, jim.macdonald, sbates, Logan Gunthorpe,
David Woodhouse, Raj, Ashok
In-Reply-To: <20161021095714.GA12209@infradead.org>
On Fri, Oct 21, 2016 at 02:57:14AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 21, 2016 at 10:22:39AM +1100, Dave Chinner wrote:
> > You do realise that local filesystems can silently change the
> > location of file data at any point in time, so there is no such
> > thing as a "stable mapping" of file data to block device addresses
> > in userspace?
> >
> > If you want remote access to the blocks owned and controlled by a
> > filesystem, then you need to use a filesystem with a remote locking
> > mechanism to allow co-ordinated, coherent access to the data in
> > those blocks. Anything else is just asking for ongoing, unfixable
> > filesystem corruption or data leakage problems (i.e. security
> > issues).
>
> And at least for XFS we have such a mechanism :) E.g. I have a
> prototype of a pNFS layout that uses XFS+DAX to allow clients to do
> RDMA directly to XFS files, with the same locking mechanism we use
> for the current block and scsi layout in xfs_pnfs.c.
Oh, that's good to know - pNFS over XFS was exactly what I was
thinking of when I wrote my earlier reply. A few months ago someone
else was trying to use file mappings in userspace for direct remote
client access on fabric connected devices. I told them "pNFS on XFS
and write an efficient transport for you hardware"....
Now that I know we've got RDMA support for pNFS on XFS in the
pipeline, I can just tell them "just write an rdma driver for your
hardware" instead. :P
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH 0/3] iopmem : A block device for PCIe memory
From: Christoph Hellwig @ 2016-10-21 9:57 UTC (permalink / raw)
To: Dave Chinner
Cc: Stephen Bates, Dan Williams, linux-kernel@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-rdma, linux-block, Linux MM,
Ross Zwisler, Matthew Wilcox, jgunthorpe, haggaie,
Christoph Hellwig, Jens Axboe, Jonathan Corbet, jim.macdonald,
sbates, Logan Gunthorpe, David Woodhouse, Raj, Ashok
In-Reply-To: <20161020232239.GQ23194@dastard>
On Fri, Oct 21, 2016 at 10:22:39AM +1100, Dave Chinner wrote:
> You do realise that local filesystems can silently change the
> location of file data at any point in time, so there is no such
> thing as a "stable mapping" of file data to block device addresses
> in userspace?
>
> If you want remote access to the blocks owned and controlled by a
> filesystem, then you need to use a filesystem with a remote locking
> mechanism to allow co-ordinated, coherent access to the data in
> those blocks. Anything else is just asking for ongoing, unfixable
> filesystem corruption or data leakage problems (i.e. security
> issues).
And at least for XFS we have such a mechanism :) E.g. I have a
prototype of a pNFS layout that uses XFS+DAX to allow clients to do
RDMA directly to XFS files, with the same locking mechanism we use
for the current block and scsi layout in xfs_pnfs.c.
^ permalink raw reply
* Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers
From: Rémi Denis-Courmont @ 2016-10-21 6:52 UTC (permalink / raw)
To: Jarod Wilson
Cc: linux-kernel, netdev, linux-rdma, Stefan Richter, Faisal Latif,
Cliff Whickman, Robin Holt, Jes Sorensen, Marek Lindner,
Simon Wunderlich, Antonio Quartulli, Sathya Prakash, Chaitra P B,
Suganath Prabu Subramani, MPT-FusionLinux.pdl, Sebastian Reichel,
Felipe Balbi, Arvid Brodin, Remi Denis-Courmont
In-Reply-To: <20161020175524.6184-8-jarod@redhat.com>
Acked-by: Rémi Denis-Courmont <courmisch@gmail.com>
--
Rémi Denis-Courmont
http://www.remlab.net/CV.pdf
^ permalink raw reply
* Re: [PATCH] IB/hns: Move HNS RoCE user vendor structures
From: oulijun @ 2016-10-21 2:35 UTC (permalink / raw)
To: Leon Romanovsky, dledford-H+wXaHxf7aLQT0dZR+AlfA,
xavier.huwei-hv44wF8Li93QT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476897187-15991-1-git-send-email-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
在 2016/10/20 1:13, Leon Romanovsky 写道:
> This patch moves HNS vendor's specific structures to
> common UAPI folder which will be visible to all consumers.
>
> Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> drivers/infiniband/hw/hns/hns_roce_cq.c | 2 +-
> drivers/infiniband/hw/hns/hns_roce_main.c | 2 +-
> drivers/infiniband/hw/hns/hns_roce_qp.c | 2 +-
> include/uapi/rdma/Kbuild | 1 +
> .../hw/hns/hns_roce_user.h => include/uapi/rdma/hns-abi.h | 9 +++++----
> 5 files changed, 9 insertions(+), 7 deletions(-)
> rename drivers/infiniband/hw/hns/hns_roce_user.h => include/uapi/rdma/hns-abi.h (94%)
>
> diff --git a/drivers/infiniband/hw/hns/hns_roce_cq.c b/drivers/infiniband/hw/hns/hns_roce_cq.c
> index 0973659..d8a1764 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_cq.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_cq.c
> @@ -35,7 +35,7 @@
> #include "hns_roce_device.h"
> #include "hns_roce_cmd.h"
> #include "hns_roce_hem.h"
> -#include "hns_roce_user.h"
> +#include <rdma/hns-abi.h>
> #include "hns_roce_common.h"
>
> static void hns_roce_ib_cq_comp(struct hns_roce_cq *hr_cq)
> diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c
> index 764e35a..354f100 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_main.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_main.c
> @@ -37,7 +37,7 @@
> #include <rdma/ib_user_verbs.h>
> #include "hns_roce_common.h"
> #include "hns_roce_device.h"
> -#include "hns_roce_user.h"
> +#include <rdma/hns-abi.h>
> #include "hns_roce_hem.h"
>
> /**
> diff --git a/drivers/infiniband/hw/hns/hns_roce_qp.c b/drivers/infiniband/hw/hns/hns_roce_qp.c
> index e86dd8d..5d13b6b 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_qp.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_qp.c
> @@ -37,7 +37,7 @@
> #include "hns_roce_common.h"
> #include "hns_roce_device.h"
> #include "hns_roce_hem.h"
> -#include "hns_roce_user.h"
> +#include <rdma/hns-abi.h>
>
> #define SQP_NUM (2 * HNS_ROCE_MAX_PORTS)
>
> diff --git a/include/uapi/rdma/Kbuild b/include/uapi/rdma/Kbuild
> index f14ab7f..b54f10d 100644
> --- a/include/uapi/rdma/Kbuild
> +++ b/include/uapi/rdma/Kbuild
> @@ -14,3 +14,4 @@ header-y += mlx5-abi.h
> header-y += mthca-abi.h
> header-y += nes-abi.h
> header-y += ocrdma-abi.h
> +header-y += hns-abi.h
> diff --git a/drivers/infiniband/hw/hns/hns_roce_user.h b/include/uapi/rdma/hns-abi.h
> similarity index 94%
> rename from drivers/infiniband/hw/hns/hns_roce_user.h
> rename to include/uapi/rdma/hns-abi.h
> index a28f761..5d74019 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_user.h
> +++ b/include/uapi/rdma/hns-abi.h
> @@ -30,8 +30,10 @@
> * SOFTWARE.
> */
>
> -#ifndef _HNS_ROCE_USER_H
> -#define _HNS_ROCE_USER_H
> +#ifndef HNS_ABI_USER_H
> +#define HNS_ABI_USER_H
> +
> +#include <linux/types.h>
>
> struct hns_roce_ib_create_cq {
> __u64 buf_addr;
> @@ -49,5 +51,4 @@ struct hns_roce_ib_create_qp {
> struct hns_roce_ib_alloc_ucontext_resp {
> __u32 qp_tab_size;
> };
> -
> -#endif /*_HNS_ROCE_USER_H */
> +#endif /* HNS_ABI_USER_H */
>
ok, 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: [Test fail]//Re: some test question//Re: [For help] configure crossbar build tool in CMakelist.txt
From: oulijun @ 2016-10-21 1:42 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-rdma, Linuxarm
In-Reply-To: <20161020162955.GA7375-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
在 2016/10/21 0:29, Jason Gunthorpe 写道:
> On Thu, Oct 20, 2016 at 03:50:07PM +0800, oulijun wrote:
>> 1. when set the VERBS_PROVIDER_DIR to empty, the
>> sizeof(VERBS_PROVIDER_DIR) should be 0 and the branch should not be
>> run
>
> This is a mistake, sizeof('') is 1, so the if should be (> 1)' I will
> fix it.
>
>> 2. the value of so_name should be /libhisi-rdmav2.so in @1 and
>> libhisi-rdmav2.so in @2. in fact, the value of so_name is /libhisi
>> and libhisi
>>
>> the test print log as follows:
>>
>> -rdmav2.soer, 218] so_name: /libhisi
>> [load_driver, 219] so_name: -rdmav2.so
>> -rdmav2.soer, 229] so_name: libhisi
>> [load_driver, 230] so_name: -rdmav2.so
>
> If you notice the -rdmav2.so has been placed at the start of the line,
> this suggest you have a spurious '\r' character. This would come from
> the .driver file.
>
> Since you did not use the cmake install process you must have written
> the .driver file yourself and used a DOS text editor. UNIX line
> endings are required.
>
> Jason
>
Thanks, i see it.
> .
>
--
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 0/3] iopmem : A block device for PCIe memory
From: Dave Chinner @ 2016-10-20 23:22 UTC (permalink / raw)
To: Stephen Bates
Cc: Dan Williams, linux-kernel@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-rdma, linux-block, Linux MM,
Ross Zwisler, Matthew Wilcox, jgunthorpe, haggaie,
Christoph Hellwig, Jens Axboe, Jonathan Corbet, jim.macdonald,
sbates, Logan Gunthorpe, David Woodhouse, Raj, Ashok
In-Reply-To: <20161019184814.GC16550@cgy1-donard.priv.deltatee.com>
On Wed, Oct 19, 2016 at 12:48:14PM -0600, Stephen Bates wrote:
> On Tue, Oct 18, 2016 at 08:51:15PM -0700, Dan Williams wrote:
> > [ adding Ashok and David for potential iommu comments ]
> >
>
> Hi Dan
>
> Thanks for adding Ashok and David!
>
> >
> > I agree with the motivation and the need for a solution, but I have
> > some questions about this implementation.
> >
> > >
> > > Consumers
> > > ---------
> > >
> > > We provide a PCIe device driver in an accompanying patch that can be
> > > used to map any PCIe BAR into a DAX capable block device. For
> > > non-persistent BARs this simply serves as an alternative to using
> > > system memory bounce buffers. For persistent BARs this can serve as an
> > > additional storage device in the system.
> >
> > Why block devices? I wonder if iopmem was initially designed back
> > when we were considering enabling DAX for raw block devices. However,
> > that support has since been ripped out / abandoned. You currently
> > need a filesystem on top of a block-device to get DAX operation.
> > Putting xfs or ext4 on top of PCI-E memory mapped range seems awkward
> > if all you want is a way to map the bar for another PCI-E device in
> > the topology.
> >
> > If you're only using the block-device as a entry-point to create
> > dax-mappings then a device-dax (drivers/dax/) character-device might
> > be a better fit.
> >
>
> We chose a block device because we felt it was intuitive for users to
> carve up a memory region but putting a DAX filesystem on it and creating
> files on that DAX aware FS. It seemed like a convenient way to
> partition up the region and to be easily able to get the DMA address
> for the memory backing the device.
You do realise that local filesystems can silently change the
location of file data at any point in time, so there is no such
thing as a "stable mapping" of file data to block device addresses
in userspace?
If you want remote access to the blocks owned and controlled by a
filesystem, then you need to use a filesystem with a remote locking
mechanism to allow co-ordinated, coherent access to the data in
those blocks. Anything else is just asking for ongoing, unfixable
filesystem corruption or data leakage problems (i.e. security
issues).
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH RFC v2 0/3] connect reject event helpers
From: Steve Wise @ 2016-10-20 22:40 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, hch-jcswGhMUV9g, axboe-b10kYP2dOMg
While reviewing:
http://lists.infradead.org/pipermail/linux-nvme/2016-October/006681.html
I decided to propose transport-agnostic helper functions to better
handle connection reject event information. I've included a nvme_rdma
patch to utilize the new helpers.
Thoughts?
Changes since v1:
- moved reject logic to cm.c and iwcm.c.
- added rdma_consumer_reject() helper.
- added nvme-rdma change to utilize the new helpers.
Steve Wise (3):
rdma_cm: add rdma_reject_msg() helper function
rdma_cm: add rdma_consumer_reject() helper function
nvme-rdma: use rdma_reject_msg() to log connection rejects
drivers/infiniband/core/cm.c | 46 ++++++++++++++++++++++++++++++++++++++++++
drivers/infiniband/core/cma.c | 26 ++++++++++++++++++++++++
drivers/infiniband/core/iwcm.c | 18 +++++++++++++++++
drivers/nvme/host/rdma.c | 18 ++++++++++-------
include/rdma/ib_cm.h | 15 ++++++++++++++
include/rdma/iw_cm.h | 15 ++++++++++++++
include/rdma/rdma_cm.h | 14 +++++++++++++
7 files changed, 145 insertions(+), 7 deletions(-)
--
2.7.0
--
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 RFC v2 3/3] nvme-rdma: use rdma_reject_msg() to log connection rejects
From: Steve Wise @ 2016-10-20 22:40 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, hch-jcswGhMUV9g, axboe-b10kYP2dOMg
In-Reply-To: <cover.1477003235.git.swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/nvme/host/rdma.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 601aecf..6319c26 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -1237,18 +1237,22 @@ out_destroy_queue_ib:
static int nvme_rdma_conn_rejected(struct nvme_rdma_queue *queue,
struct rdma_cm_event *ev)
{
- if (ev->param.conn.private_data_len) {
+ struct rdma_cm_id *cm_id = queue->cm_id;
+ int rdma_status = ev->status;
+ short nvme_status = -1;
+
+ if (rdma_consumer_reject(cm_id, rdma_status) &&
+ ev->param.conn.private_data_len) {
struct nvme_rdma_cm_rej *rej =
(struct nvme_rdma_cm_rej *)ev->param.conn.private_data;
- dev_err(queue->ctrl->ctrl.device,
- "Connect rejected, status %d.", le16_to_cpu(rej->sts));
- /* XXX: Think of something clever to do here... */
- } else {
- dev_err(queue->ctrl->ctrl.device,
- "Connect rejected, no private data.\n");
+ nvme_status = le16_to_cpu(rej->sts);
}
+ dev_err(queue->ctrl->ctrl.device, "Connect rejected: status %d (%s) "
+ "nvme status %d.\n", rdma_status,
+ rdma_reject_msg(cm_id, rdma_status), nvme_status);
+
return -ECONNRESET;
}
--
2.7.0
--
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 RFC v2 2/3] rdma_cm: add rdma_consumer_reject() helper function
From: Steve Wise @ 2016-10-20 22:40 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, hch-jcswGhMUV9g, axboe-b10kYP2dOMg
In-Reply-To: <cover.1477003235.git.swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
Return true if the peer consumer application rejected the
connection attempt.
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/core/cma.c | 13 +++++++++++++
include/rdma/ib_cm.h | 9 +++++++++
include/rdma/iw_cm.h | 9 +++++++++
include/rdma/rdma_cm.h | 6 ++++++
4 files changed, 37 insertions(+)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 7cc7346..4ec16a3 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -114,6 +114,19 @@ const char *__attribute_const__ rdma_reject_msg(struct rdma_cm_id *id,
}
EXPORT_SYMBOL(rdma_reject_msg);
+bool rdma_consumer_reject(struct rdma_cm_id *id, int reason)
+{
+ if (rdma_ib_or_roce(id->device, id->port_num))
+ return ib_consumer_reject(reason);
+
+ if (rdma_protocol_iwarp(id->device, id->port_num))
+ return iw_consumer_reject(reason);
+
+ /* FIXME should we WARN_ONCE() here? */
+ return false;
+}
+EXPORT_SYMBOL(rdma_consumer_reject);
+
static void cma_add_one(struct ib_device *device);
static void cma_remove_one(struct ib_device *device, void *client_data);
diff --git a/include/rdma/ib_cm.h b/include/rdma/ib_cm.h
index af193b7..5595529 100644
--- a/include/rdma/ib_cm.h
+++ b/include/rdma/ib_cm.h
@@ -609,4 +609,13 @@ int ib_send_cm_sidr_rep(struct ib_cm_id *cm_id,
*/
const char *__attribute_const__ ib_reject_msg(int reason);
+/**
+ * ib_consumer_reject - return true if the user rejected the connection.
+ * @reason: Value returned in the REJECT event status field.
+ */
+static inline bool ib_consumer_reject(int reason)
+{
+ return reason == IB_CM_REJ_CONSUMER_DEFINED;
+};
+
#endif /* IB_CM_H */
diff --git a/include/rdma/iw_cm.h b/include/rdma/iw_cm.h
index 15b437e..1e5bd33 100644
--- a/include/rdma/iw_cm.h
+++ b/include/rdma/iw_cm.h
@@ -259,4 +259,13 @@ int iw_cm_init_qp_attr(struct iw_cm_id *cm_id, struct ib_qp_attr *qp_attr,
*/
const char *__attribute_const__ iw_reject_msg(int reason);
+/**
+ * iw_consumer_reject - return true if the consumer rejected the connection.
+ * @reason: Value returned in the REJECT event status field.
+ */
+static inline bool iw_consumer_reject(int reason)
+{
+ return reason == -ECONNREFUSED;
+}
+
#endif /* IW_CM_H */
diff --git a/include/rdma/rdma_cm.h b/include/rdma/rdma_cm.h
index 712a70c..058dfbb 100644
--- a/include/rdma/rdma_cm.h
+++ b/include/rdma/rdma_cm.h
@@ -395,5 +395,11 @@ __be64 rdma_get_service_id(struct rdma_cm_id *id, struct sockaddr *addr);
*/
const char *__attribute_const__ rdma_reject_msg(struct rdma_cm_id *id,
int reason);
+/**
+ * rdma_consumer_reject - return true if the consumer rejected the connection.
+ * @id: Communication identifier that received the REJECT event
+ * @reason: Value returned in the REJECT event status field.
+ */
+bool rdma_consumer_reject(struct rdma_cm_id *id, int reason);
#endif /* RDMA_CM_H */
--
2.7.0
--
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 RFC v2 1/3] rdma_cm: add rdma_reject_msg() helper function
From: Steve Wise @ 2016-10-20 22:40 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sagig-NQWnxTmZq1alnMjI0IkVqw, hch-jcswGhMUV9g, axboe-b10kYP2dOMg
In-Reply-To: <cover.1477003235.git.swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
rdma_reject_msg() returns a pointer to a string message associated with
the transport reject reason codes.
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/core/cm.c | 46 ++++++++++++++++++++++++++++++++++++++++++
drivers/infiniband/core/cma.c | 13 ++++++++++++
drivers/infiniband/core/iwcm.c | 18 +++++++++++++++++
include/rdma/ib_cm.h | 6 ++++++
include/rdma/iw_cm.h | 6 ++++++
include/rdma/rdma_cm.h | 8 ++++++++
6 files changed, 97 insertions(+)
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index c995255..0918c17 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -57,6 +57,52 @@ MODULE_AUTHOR("Sean Hefty");
MODULE_DESCRIPTION("InfiniBand CM");
MODULE_LICENSE("Dual BSD/GPL");
+static const char * const ib_rej_reason_strs[] = {
+ [IB_CM_REJ_NO_QP] = "no qp",
+ [IB_CM_REJ_NO_EEC] = "no eec",
+ [IB_CM_REJ_NO_RESOURCES] = "no resources",
+ [IB_CM_REJ_TIMEOUT] = "timeout",
+ [IB_CM_REJ_UNSUPPORTED] = "unsupported",
+ [IB_CM_REJ_INVALID_COMM_ID] = "invalid comm id",
+ [IB_CM_REJ_INVALID_COMM_INSTANCE] = "invalid comm instance",
+ [IB_CM_REJ_INVALID_SERVICE_ID] = "invalid service id",
+ [IB_CM_REJ_INVALID_TRANSPORT_TYPE] = "invalid transport type",
+ [IB_CM_REJ_STALE_CONN] = "stale conn",
+ [IB_CM_REJ_RDC_NOT_EXIST] = "rdc not exist",
+ [IB_CM_REJ_INVALID_GID] = "invalid gid",
+ [IB_CM_REJ_INVALID_LID] = "invalid lid",
+ [IB_CM_REJ_INVALID_SL] = "invalid sl",
+ [IB_CM_REJ_INVALID_TRAFFIC_CLASS] = "invalid traffic class",
+ [IB_CM_REJ_INVALID_HOP_LIMIT] = "invalid hop limit",
+ [IB_CM_REJ_INVALID_PACKET_RATE] = "invalid packet rate",
+ [IB_CM_REJ_INVALID_ALT_GID] = "invalid alt gid",
+ [IB_CM_REJ_INVALID_ALT_LID] = "invalid alt lid",
+ [IB_CM_REJ_INVALID_ALT_SL] = "invalid alt sl",
+ [IB_CM_REJ_INVALID_ALT_TRAFFIC_CLASS] = "invalid alt traffic class",
+ [IB_CM_REJ_INVALID_ALT_HOP_LIMIT] = "invalid alt hop limit",
+ [IB_CM_REJ_INVALID_ALT_PACKET_RATE] = "invalid alt packet rate",
+ [IB_CM_REJ_PORT_CM_REDIRECT] = "port cm redirect",
+ [IB_CM_REJ_PORT_REDIRECT] = "port redirect",
+ [IB_CM_REJ_INVALID_MTU] = "invalid mtu",
+ [IB_CM_REJ_INSUFFICIENT_RESP_RESOURCES] = "insufficient resp resources",
+ [IB_CM_REJ_CONSUMER_DEFINED] = "consumer defined",
+ [IB_CM_REJ_INVALID_RNR_RETRY] = "invalid rnr retry",
+ [IB_CM_REJ_DUPLICATE_LOCAL_COMM_ID] = "duplicate local comm id",
+ [IB_CM_REJ_INVALID_CLASS_VERSION] = "invalid class version",
+ [IB_CM_REJ_INVALID_FLOW_LABEL] = "invalid flow label",
+ [IB_CM_REJ_INVALID_ALT_FLOW_LABEL] = "invalid alt flow label",
+};
+
+const char *__attribute_const__ ib_reject_msg(int reason)
+{
+ size_t index = reason;
+
+ return (index < ARRAY_SIZE(ib_rej_reason_strs) &&
+ ib_rej_reason_strs[index]) ?
+ ib_rej_reason_strs[index] : "unrecognized reason";
+}
+EXPORT_SYMBOL(ib_reject_msg);
+
static void cm_add_one(struct ib_device *device);
static void cm_remove_one(struct ib_device *device, void *client_data);
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 5f65a78..7cc7346 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -101,6 +101,19 @@ const char *__attribute_const__ rdma_event_msg(enum rdma_cm_event_type event)
}
EXPORT_SYMBOL(rdma_event_msg);
+const char *__attribute_const__ rdma_reject_msg(struct rdma_cm_id *id,
+ int reason)
+{
+ if (rdma_ib_or_roce(id->device, id->port_num))
+ return ib_reject_msg(reason);
+
+ if (rdma_protocol_iwarp(id->device, id->port_num))
+ return iw_reject_msg(reason);
+
+ return "unrecognized reason";
+}
+EXPORT_SYMBOL(rdma_reject_msg);
+
static void cma_add_one(struct ib_device *device);
static void cma_remove_one(struct ib_device *device, void *client_data);
diff --git a/drivers/infiniband/core/iwcm.c b/drivers/infiniband/core/iwcm.c
index 357624f..588a31d 100644
--- a/drivers/infiniband/core/iwcm.c
+++ b/drivers/infiniband/core/iwcm.c
@@ -59,6 +59,24 @@ MODULE_AUTHOR("Tom Tucker");
MODULE_DESCRIPTION("iWARP CM");
MODULE_LICENSE("Dual BSD/GPL");
+static const char * const iw_rej_reason_strs[] = {
+ [ECONNRESET] = "reset by remote host",
+ [ECONNREFUSED] = "refused by remote application",
+ [ETIMEDOUT] = "setup timeout",
+};
+
+const char *__attribute_const__ iw_reject_msg(int reason)
+{
+ size_t index = -reason;
+
+ /* iWARP uses negative errnos */
+ index = -index;
+ return (index < ARRAY_SIZE(iw_rej_reason_strs) &&
+ iw_rej_reason_strs[index]) ?
+ iw_rej_reason_strs[index] : "unrecognized reason";
+}
+EXPORT_SYMBOL(iw_reject_msg);
+
static struct ibnl_client_cbs iwcm_nl_cb_table[] = {
[RDMA_NL_IWPM_REG_PID] = {.dump = iwpm_register_pid_cb},
[RDMA_NL_IWPM_ADD_MAPPING] = {.dump = iwpm_add_mapping_cb},
diff --git a/include/rdma/ib_cm.h b/include/rdma/ib_cm.h
index 92a7d85..af193b7 100644
--- a/include/rdma/ib_cm.h
+++ b/include/rdma/ib_cm.h
@@ -603,4 +603,10 @@ struct ib_cm_sidr_rep_param {
int ib_send_cm_sidr_rep(struct ib_cm_id *cm_id,
struct ib_cm_sidr_rep_param *param);
+/**
+ * ib_reject_msg - return a pointer to a reject message string.
+ * @reason: Value returned in the REJECT event status field.
+ */
+const char *__attribute_const__ ib_reject_msg(int reason);
+
#endif /* IB_CM_H */
diff --git a/include/rdma/iw_cm.h b/include/rdma/iw_cm.h
index 6d0065c..15b437e 100644
--- a/include/rdma/iw_cm.h
+++ b/include/rdma/iw_cm.h
@@ -253,4 +253,10 @@ int iw_cm_disconnect(struct iw_cm_id *cm_id, int abrupt);
int iw_cm_init_qp_attr(struct iw_cm_id *cm_id, struct ib_qp_attr *qp_attr,
int *qp_attr_mask);
+/**
+ * iw_reject_msg - return a pointer to a reject message string.
+ * @reason: Value returned in the REJECT event status field.
+ */
+const char *__attribute_const__ iw_reject_msg(int reason);
+
#endif /* IW_CM_H */
diff --git a/include/rdma/rdma_cm.h b/include/rdma/rdma_cm.h
index 81fb1d1..712a70c 100644
--- a/include/rdma/rdma_cm.h
+++ b/include/rdma/rdma_cm.h
@@ -388,4 +388,12 @@ int rdma_set_afonly(struct rdma_cm_id *id, int afonly);
*/
__be64 rdma_get_service_id(struct rdma_cm_id *id, struct sockaddr *addr);
+/**
+ * rdma_reject_msg - return a pointer to a reject message string.
+ * @id: Communication identifier that received the REJECT event
+ * @reason: Value returned in the REJECT event status field.
+ */
+const char *__attribute_const__ rdma_reject_msg(struct rdma_cm_id *id,
+ int reason);
+
#endif /* RDMA_CM_H */
--
2.7.0
--
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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox