* Re: [PATCH 1/3] IB/core: use IB_CQ_REPORT_MISSED_EVENTS to avoid missed CQ callbacks
From: Andy Grover @ 2010-04-02 19:54 UTC (permalink / raw)
To: Roland Dreier
Cc: Ralph Campbell,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <ada4ojwghey.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
(sorry to reply late -- bad mail rules.)
RDS used to do send and recv processing in the event handler.
It currently uses a tasklet for recv, and send is still in the event
handler. When we moved the recv processing to a tasklet, we poll the cq,
arm the cq, then poll it again, because it seems like 1) we want to do
as much work as possible before rearming the event and 2) we need to
poll after, to be sure to catch CQEs added between the time when the
handler exited and we've gotten to this point in the tasklet. How does
this approach (re-polling after calling notify_cq) compare with using
REPORT_MISSED_EVENTS? Maybe it's two different ways to do the same thing?
Anyways, this is off the point from your original patch that changed the
send cq handling, which is all done in the event handler. I don't have
an explanation for you seeing the 0xdeads, except that the comment above
that code that mentions racing cleanly with the send path makes my
antennae twitch a little bit...
Regards -- Andy
PS FWIW my dev branch moves RDS to a single CQ for send & recv events
similar to srp, except using a tasklet, and notify_cq(IB_CQ_SOLICITED),
and doing poll/arm/poll.
--
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 v3 0/2] Using multi-smps on the wire in libibnetdisc
From: Ira Weiny @ 2010-04-03 0:23 UTC (permalink / raw)
To: Ira Weiny
Cc: Sasha Khapyorsky,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Hal Rosenstock
In-Reply-To: <20100218124931.4d6ef34b.weiny2-i2BcT+NCU+M@public.gmane.org>
Sasha,
Have you had a chance to look at this yet? If you want I can resend the latest version of the patches.
Thanks,
Ira
On Thu, 18 Feb 2010 12:49:31 -0800
Ira Weiny <weiny2-i2BcT+NCU+M@public.gmane.org> wrote:
> After the discussion with Hal I decided it would be safer to just limit the number of outstanding MAD's to 2. This v3 version changes that. Patch 2/2 remains the same but I am just sending it to be complete.
>
> Thanks,
> Ira
>
--
Ira Weiny
Math Programmer/Computer Scientist
Lawrence Livermore National Lab
925-423-8008
weiny2-i2BcT+NCU+M@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
* [PATCH] svcrdma: RDMA support not yet compatible with RPC6
From: Tom Tucker @ 2010-04-03 13:27 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Chuck Lever, Steve Wise,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
RPC6 requires that it be possible to create endpoints that listen
exclusively for IPv4 or IPv6 connection requests. This is not currently
supported by the RDMA API.
Signed-off-by: Tom Tucker<tom-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
Tested-by: Steve Wise<swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
net/sunrpc/xprtrdma/svc_rdma_transport.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c
index 3fa5751..4e6bbf9 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
@@ -678,7 +678,10 @@ static struct svc_xprt *svc_rdma_create(struct svc_serv *serv,
int ret;
dprintk("svcrdma: Creating RDMA socket\n");
-
+ if (sa->sa_family != AF_INET) {
+ dprintk("svcrdma: Address family %d is not supported.\n", sa->sa_family);
+ return ERR_PTR(-EAFNOSUPPORT);
+ }
cma_xprt = rdma_create_xprt(serv, 1);
if (!cma_xprt)
return ERR_PTR(-ENOMEM);
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] infiniband: potential double free
From: Or Gerlitz @ 2010-04-03 22:34 UTC (permalink / raw)
To: Dan Carpenter
Cc: Thadeu Lima de Souza Cascardo, Roland Dreier, Or Gerlitz,
Jiri Kosina, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100316080925.GC5331@bicker>
On Tue, Mar 16, 2010 at 10:09 AM, Dan Carpenter <error27-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> We shouldn't free things here because we free them later. The call tree looks like this:
Hi Dan, Roland,
We're at a somehow high holiday (e.g Passover) season, and as such I
haven't resolve the issue Dan brought yet. However, all in all this is
--not-- a regression but rather a bug in the error handling code of a
path (synchronous connection establishment) which isn't used (e.g
non_blocking is always true when called by the iscsi stack).
I will make sure to fix the issue for the next merge window, and
actually queue a fixed/reviewed patch (e.g review what Dan works on)
way before that. So in that respect, Roland, you need not to deal with
this directly. Please make sure to cc linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org on
each related mail, thanks
Or.
--
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: umad_register_oui
From: Sasha Khapyorsky @ 2010-04-04 10:17 UTC (permalink / raw)
To: Sean Hefty; +Cc: linux-rdma
In-Reply-To: <3F5FB92A829547AF927C59B5649489B9-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
Hi Sean,
On 13:00 Fri 26 Mar , Sean Hefty wrote:
>
> We hit a bug in our windows implementation of libibumad that highlights an issue
> with the umad interface. umad_register_oui does not take the mgmt_class as
> input, where umad_register does. umad_register_oui assumes that the
> mgmt_version is 1. Not sure if or how you want to handle this.
Basically we could add another call umad_register_oui2() or so with all
needed parameters.
Sasha
--
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: umad_register_oui
From: Sean Hefty @ 2010-04-05 1:05 UTC (permalink / raw)
To: 'Sasha Khapyorsky'; +Cc: linux-rdma
In-Reply-To: <20100404101722.GO4808@me>
>Basically we could add another call umad_register_oui2() or so with all
>needed parameters.
In that case, we can probably delay adding the call until it's actually needed.
I only hit the issue because I implemented umad_register to call
umad_register_oui.
- Sean
--
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] svcrdma: RDMA support not yet compatible with RPC6
From: Chuck Lever @ 2010-04-05 14:55 UTC (permalink / raw)
To: Tom Tucker
Cc: J. Bruce Fields, Steve Wise,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4BB74241.4060308-/Yg/VP3ZvrM@public.gmane.org>
On 04/03/2010 09:27 AM, Tom Tucker wrote:
> RPC6 requires that it be possible to create endpoints that listen
> exclusively for IPv4 or IPv6 connection requests. This is not currently
> supported by the RDMA API.
>
> Signed-off-by: Tom Tucker<tom-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
> Tested-by: Steve Wise<swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
Reviewed-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> ---
>
> net/sunrpc/xprtrdma/svc_rdma_transport.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> index 3fa5751..4e6bbf9 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> @@ -678,7 +678,10 @@ static struct svc_xprt *svc_rdma_create(struct
> svc_serv *serv,
> int ret;
>
> dprintk("svcrdma: Creating RDMA socket\n");
> -
> + if (sa->sa_family != AF_INET) {
> + dprintk("svcrdma: Address family %d is not supported.\n", sa->sa_family);
> + return ERR_PTR(-EAFNOSUPPORT);
> + }
> cma_xprt = rdma_create_xprt(serv, 1);
> if (!cma_xprt)
> return ERR_PTR(-ENOMEM);
>
--
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] svcrdma: RDMA support not yet compatible with RPC6
From: J. Bruce Fields @ 2010-04-05 15:48 UTC (permalink / raw)
To: Chuck Lever
Cc: Tom Tucker, Steve Wise,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4BB9F9D0.1040203-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Mon, Apr 05, 2010 at 10:55:12AM -0400, Chuck Lever wrote:
> On 04/03/2010 09:27 AM, Tom Tucker wrote:
>> RPC6 requires that it be possible to create endpoints that listen
>> exclusively for IPv4 or IPv6 connection requests. This is not currently
>> supported by the RDMA API.
>>
>> Signed-off-by: Tom Tucker<tom-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>> Tested-by: Steve Wise<swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>
> Reviewed-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Thanks to all. I take it the problem began with 37498292a "NFSD: Create
PF_INET6 listener in write_ports"?
--b.
>
>> ---
>>
>> net/sunrpc/xprtrdma/svc_rdma_transport.c | 5 ++++-
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c
>> b/net/sunrpc/xprtrdma/svc_rdma_transport.c
>> index 3fa5751..4e6bbf9 100644
>> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
>> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
>> @@ -678,7 +678,10 @@ static struct svc_xprt *svc_rdma_create(struct
>> svc_serv *serv,
>> int ret;
>>
>> dprintk("svcrdma: Creating RDMA socket\n");
>> -
>> + if (sa->sa_family != AF_INET) {
>> + dprintk("svcrdma: Address family %d is not supported.\n", sa->sa_family);
>> + return ERR_PTR(-EAFNOSUPPORT);
>> + }
>> cma_xprt = rdma_create_xprt(serv, 1);
>> if (!cma_xprt)
>> return ERR_PTR(-ENOMEM);
>>
>
>
> --
> chuck[dot]lever[at]oracle[dot]com
--
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] svcrdma: RDMA support not yet compatible with RPC6
From: Chuck Lever @ 2010-04-05 15:49 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Tom Tucker, Steve Wise,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100405154850.GG16370-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On 04/05/2010 11:48 AM, J. Bruce Fields wrote:
> On Mon, Apr 05, 2010 at 10:55:12AM -0400, Chuck Lever wrote:
>> On 04/03/2010 09:27 AM, Tom Tucker wrote:
>>> RPC6 requires that it be possible to create endpoints that listen
>>> exclusively for IPv4 or IPv6 connection requests. This is not currently
>>> supported by the RDMA API.
>>>
>>> Signed-off-by: Tom Tucker<tom-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>>> Tested-by: Steve Wise<swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>>
>> Reviewed-by: Chuck Lever<chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>
> Thanks to all. I take it the problem began with 37498292a "NFSD: Create
> PF_INET6 listener in write_ports"?
I don't know exactly, but that would make sense.
--
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] svcrdma: RDMA support not yet compatible with RPC6
From: Tom Tucker @ 2010-04-05 15:50 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Chuck Lever, Tom Tucker, Steve Wise,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100405154850.GG16370-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
J. Bruce Fields wrote:
> On Mon, Apr 05, 2010 at 10:55:12AM -0400, Chuck Lever wrote:
>
>> On 04/03/2010 09:27 AM, Tom Tucker wrote:
>>
>>> RPC6 requires that it be possible to create endpoints that listen
>>> exclusively for IPv4 or IPv6 connection requests. This is not currently
>>> supported by the RDMA API.
>>>
>>> Signed-off-by: Tom Tucker<tom-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>>> Tested-by: Steve Wise<swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>>>
>> Reviewed-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>>
>
> Thanks to all. I take it the problem began with 37498292a "NFSD: Create
> PF_INET6 listener in write_ports"?
>
>
Yes.
Tom
> --b.
>
>
>>> ---
>>>
>>> net/sunrpc/xprtrdma/svc_rdma_transport.c | 5 ++++-
>>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c
>>> b/net/sunrpc/xprtrdma/svc_rdma_transport.c
>>> index 3fa5751..4e6bbf9 100644
>>> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
>>> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
>>> @@ -678,7 +678,10 @@ static struct svc_xprt *svc_rdma_create(struct
>>> svc_serv *serv,
>>> int ret;
>>>
>>> dprintk("svcrdma: Creating RDMA socket\n");
>>> -
>>> + if (sa->sa_family != AF_INET) {
>>> + dprintk("svcrdma: Address family %d is not supported.\n", sa->sa_family);
>>> + return ERR_PTR(-EAFNOSUPPORT);
>>> + }
>>> cma_xprt = rdma_create_xprt(serv, 1);
>>> if (!cma_xprt)
>>> return ERR_PTR(-ENOMEM);
>>>
>>>
>> --
>> chuck[dot]lever[at]oracle[dot]com
>>
> --
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] svcrdma: RDMA support not yet compatible with RPC6
From: J. Bruce Fields @ 2010-04-05 16:16 UTC (permalink / raw)
To: Tom Tucker
Cc: Chuck Lever, Tom Tucker, Steve Wise,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4BBA06B8.3090201-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
On Mon, Apr 05, 2010 at 10:50:16AM -0500, Tom Tucker wrote:
> J. Bruce Fields wrote:
>> On Mon, Apr 05, 2010 at 10:55:12AM -0400, Chuck Lever wrote:
>>
>>> On 04/03/2010 09:27 AM, Tom Tucker wrote:
>>>
>>>> RPC6 requires that it be possible to create endpoints that listen
>>>> exclusively for IPv4 or IPv6 connection requests. This is not currently
>>>> supported by the RDMA API.
>>>>
>>>> Signed-off-by: Tom Tucker<tom-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>>>> Tested-by: Steve Wise<swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>>>>
>>> Reviewed-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>>>
>>
>> Thanks to all. I take it the problem began with 37498292a "NFSD: Create
>> PF_INET6 listener in write_ports"?
>>
>>
>
> Yes.
Thanks. I'll pass along
git://linux-nfs.org/~bfields/linux.git for-2.6.34
soon.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] svcrdma: RDMA support not yet compatible with RPC6
From: Tom Tucker @ 2010-04-05 16:19 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Chuck Lever, Tom Tucker, Steve Wise,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100405162020.GJ16370-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
J. Bruce Fields wrote:
> On Mon, Apr 05, 2010 at 12:16:18PM -0400, J. Bruce Fields wrote:
>
>> On Mon, Apr 05, 2010 at 10:50:16AM -0500, Tom Tucker wrote:
>>
>>> J. Bruce Fields wrote:
>>>
>>>> On Mon, Apr 05, 2010 at 10:55:12AM -0400, Chuck Lever wrote:
>>>>
>>>>
>>>>> On 04/03/2010 09:27 AM, Tom Tucker wrote:
>>>>>
>>>>>
>>>>>> RPC6 requires that it be possible to create endpoints that listen
>>>>>> exclusively for IPv4 or IPv6 connection requests. This is not currently
>>>>>> supported by the RDMA API.
>>>>>>
>>>>>> Signed-off-by: Tom Tucker<tom-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>>>>>> Tested-by: Steve Wise<swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>>>>>>
>>>>>>
>>>>> Reviewed-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>>>>>
>>>>>
>>>> Thanks to all. I take it the problem began with 37498292a "NFSD: Create
>>>> PF_INET6 listener in write_ports"?
>>>>
>>>>
>>>>
>>> Yes.
>>>
>> Thanks. I'll pass along
>>
>> git://linux-nfs.org/~bfields/linux.git for-2.6.34
>>
>> soon.
>>
>
> And: sorry we didn't catch this when it happened. I have some of the
> equipment I'd need to do basic regression tests, but haven't set it up.
>
> I hope I get to it at some point.... For now I depend on others to
> catch even basic rdma regressions--let me know if there's some way I
> could make your testing easier.
>
>
We were focused on older kernels..and probably should have caught it
quicker. No worries. Thanks,
Tom
> --b.
>
--
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] svcrdma: RDMA support not yet compatible with RPC6
From: J. Bruce Fields @ 2010-04-05 16:20 UTC (permalink / raw)
To: Tom Tucker
Cc: Chuck Lever, Tom Tucker, Steve Wise,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100405161618.GI16370-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On Mon, Apr 05, 2010 at 12:16:18PM -0400, J. Bruce Fields wrote:
> On Mon, Apr 05, 2010 at 10:50:16AM -0500, Tom Tucker wrote:
> > J. Bruce Fields wrote:
> >> On Mon, Apr 05, 2010 at 10:55:12AM -0400, Chuck Lever wrote:
> >>
> >>> On 04/03/2010 09:27 AM, Tom Tucker wrote:
> >>>
> >>>> RPC6 requires that it be possible to create endpoints that listen
> >>>> exclusively for IPv4 or IPv6 connection requests. This is not currently
> >>>> supported by the RDMA API.
> >>>>
> >>>> Signed-off-by: Tom Tucker<tom-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
> >>>> Tested-by: Steve Wise<swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
> >>>>
> >>> Reviewed-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> >>>
> >>
> >> Thanks to all. I take it the problem began with 37498292a "NFSD: Create
> >> PF_INET6 listener in write_ports"?
> >>
> >>
> >
> > Yes.
>
> Thanks. I'll pass along
>
> git://linux-nfs.org/~bfields/linux.git for-2.6.34
>
> soon.
And: sorry we didn't catch this when it happened. I have some of the
equipment I'd need to do basic regression tests, but haven't set it up.
I hope I get to it at some point.... For now I depend on others to
catch even basic rdma regressions--let me know if there's some way I
could make your testing easier.
--b.
--
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
* NFS-RDMA on SLES 10 SP3
From: Justin Clift @ 2010-04-05 19:53 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hi all,
After discovering that ofa kernel doesn't compile any more (with 1.5.1
GA and 1.5.2 latest nightly) on SLES 11 with the latest patches, now
trying on SLES 10 SP3.
I'm attempting to try out NFS-RDMA, however on SLES 10 SP3 it's not
being presented as an option from the "Custom" list.
i.e.:
Install rds-tools? [y/N]:n
Install rnfs-utils? [y/N]:y <--- this line completely missing
Install ibutils? [y/N]: ...
Thought I'd better ask if this is expected behaviour before I file a bug
report, as SLES10 SP3 is specifically mentioned in the NFS-RDMA release
notes as being supported.
?
(I've worked around the above problem by just changing the install.pl
file. Compiles fine. But, thought it best to ask just in case.)
Regards and best wishes,
Justin Clift
--
Salasaga - Open Source eLearning IDE
http://www.salasaga.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
* [PATCH] RDMA/cxgb3: Don't free skbs on NET_XMIT_* indications from LLD.
From: Steve Wise @ 2010-04-05 19:59 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
The low level cxgb3 driver can return NET_XMIT_CN and friends.
The iw_cxgb3 driver should _not_ treat these as errors.
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb3/iwch_cm.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index d94388b..4953146 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -150,7 +150,7 @@ int iwch_l2t_send(struct t3cdev *tdev, struct sk_buff *skb, struct l2t_entry *l2
return -EIO;
}
error = l2t_send(tdev, skb, l2e);
- if (error)
+ if (error < 0)
kfree_skb(skb);
return error;
}
@@ -166,7 +166,7 @@ int iwch_cxgb3_ofld_send(struct t3cdev *tdev, struct sk_buff *skb)
return -EIO;
}
error = cxgb3_ofld_send(tdev, skb);
- if (error)
+ if (error < 0)
kfree_skb(skb);
return error;
}
--
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: NFS-RDMA on SLES 10 SP3
From: Steve Wise @ 2010-04-05 20:22 UTC (permalink / raw)
To: Justin Clift; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4BBA3FD5.8070005-oNuxUQfTmABg9hUCZPvPmw@public.gmane.org>
OFED-1.5.1 removed support for NFS-RDMA on SLES 10 SP3 due to stability
problems.
Justin Clift wrote:
> Hi all,
>
> After discovering that ofa kernel doesn't compile any more (with 1.5.1
> GA and 1.5.2 latest nightly) on SLES 11 with the latest patches, now
> trying on SLES 10 SP3.
>
> I'm attempting to try out NFS-RDMA, however on SLES 10 SP3 it's not
> being presented as an option from the "Custom" list.
>
> i.e.:
>
> Install rds-tools? [y/N]:n
> Install rnfs-utils? [y/N]:y <--- this line completely missing
> Install ibutils? [y/N]: ...
>
> Thought I'd better ask if this is expected behaviour before I file a
> bug report, as SLES10 SP3 is specifically mentioned in the NFS-RDMA
> release
> notes as being supported.
>
> ?
>
> (I've worked around the above problem by just changing the install.pl
> file. Compiles fine. But, thought it best to ask just in case.)
>
> Regards and best wishes,
>
> Justin Clift
>
--
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] RDMA/cxgb3: Don't free skbs on NET_XMIT_* indications from LLD.
From: Roland Dreier @ 2010-04-05 20:37 UTC (permalink / raw)
To: Steve Wise; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100405195956.28814.29311.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
Is this a regression fix for 2.6.34, or just something to queue for 2.6.35?
--
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: NFS-RDMA on SLES 10 SP3
From: Justin Clift @ 2010-04-05 20:40 UTC (permalink / raw)
To: Steve Wise; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4BBA4681.8020502-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
Steve Wise wrote:
> OFED-1.5.1 removed support for NFS-RDMA on SLES 10 SP3 due to stability
> problems.
No worries, thanks. :)
Regards and best wishes,
Justin Clift
--
Salasaga - Open Source eLearning IDE
http://www.salasaga.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] RDMA/cxgb3: Don't free skbs on NET_XMIT_* indications from LLD.
From: Steve Wise @ 2010-04-05 20:41 UTC (permalink / raw)
To: Roland Dreier; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <adapr2d7i1d.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
Roland Dreier wrote:
> Is this a regression fix for 2.6.34, or just something to queue for 2.6.35?
> --
> 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
>
Its not a regression. It was discovered by code inspection. 2.6.35 is
fine methinks.
--
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: umad_register_oui
From: Sasha Khapyorsky @ 2010-04-06 8:37 UTC (permalink / raw)
To: Sean Hefty; +Cc: linux-rdma
In-Reply-To: <14FF040973DD4244AAD62E2FCB4A4C3A-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
On 18:05 Sun 04 Apr , Sean Hefty wrote:
> >Basically we could add another call umad_register_oui2() or so with all
> >needed parameters.
>
> In that case, we can probably delay adding the call until it's actually needed.
>
> I only hit the issue because I implemented umad_register to call
> umad_register_oui.
Ok, I see.
Sasha
--
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: NFS-RDMA on SLES 10 SP3
From: Vladimir Sokolovsky @ 2010-04-06 8:54 UTC (permalink / raw)
To: Justin Clift; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4BBA3FD5.8070005-oNuxUQfTmABg9hUCZPvPmw@public.gmane.org>
Justin Clift wrote:
> Hi all,
>
> After discovering that ofa kernel doesn't compile any more (with 1.5.1
> GA and 1.5.2 latest nightly) on SLES 11 with the latest patches, now
> trying on SLES 10 SP3.
>
Hi Justin,
Can you send me the kernel version of SLES11 that you have and the ofa_kernel.rpmbuild.log?
Thanks,
Vladimir
--
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
* Ok to edit the OpenFabrics wiki?
From: Justin Clift @ 2010-04-06 10:18 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hi all,
Just went to update some of the info on the OpenFabrics wiki (ie
motherboard compatibility), plus remove some of the spam in comments
(ie. pr0n links).
However, after registering and confirming email address, the wiki
doesn't appear to be actually logging me in.
New problem, or do I need to be manually added to an approved editor
list or something? :)
Regards and best wishes,
Justin Clift
--
Salasaga - Open Source eLearning IDE
http://www.salasaga.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: Ok to edit the OpenFabrics wiki?
From: Justin Clift @ 2010-04-06 16:33 UTC (permalink / raw)
To: Jeff Becker; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <4BBB5083.6040401-NSQ8wuThN14@public.gmane.org>
Jeff Becker wrote:
<snip>
>
> Hi. I'm aware of the problem, and have verified it. Although I spent
> some time looking at it, I haven't been able to fix it yet. Part of the
> issue is that we have a new server ready to go, and I am awaiting
> instructions from an outside review panel (discussed at Sonoma) to
> proceed. If I get some free cycles, I'll take a look, but I expect the
> server (and wiki) move will happen soon, so the problem may be moot.
>
> Thanks.
No worries. I'll take a look again after the server + wiki move I
guess. Seems like the wiki could do with some freshening up, so I'll
see what spare time I have then.
Regards and best wishes,
Justin Clift
--
Salasaga - Open Source eLearning IDE
http://www.salasaga.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: Ok to edit the OpenFabrics wiki?
From: Smith, Stan @ 2010-04-06 16:42 UTC (permalink / raw)
To: Justin Clift, Jeff Becker
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <4BBB6248.2040307-oNuxUQfTmABg9hUCZPvPmw@public.gmane.org>
Justin Clift wrote:
> Jeff Becker wrote:
> <snip>
>>
>> Hi. I'm aware of the problem, and have verified it. Although I spent
>> some time looking at it, I haven't been able to fix it yet. Part of
>> the issue is that we have a new server ready to go, and I am awaiting
>> instructions from an outside review panel (discussed at Sonoma) to
>> proceed. If I get some free cycles, I'll take a look, but I expect
>> the server (and wiki) move will happen soon, so the problem may be
>> moot.
>>
>> Thanks.
>
> No worries. I'll take a look again after the server + wiki move I
> guess. Seems like the wiki could do with some freshening up, so I'll
> see what spare time I have then.
>
> Regards and best wishes,
>
> Justin Clift
>
> --
> Salasaga - Open Source eLearning IDE
> http://www.salasaga.org
FYI - OFA Windows Wiki pages have been in this inaccessible state for over 2 weeks.
--
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 9/26 v2] rdma/cm: set qkey for port space IB
From: Sean Hefty @ 2010-04-07 0:49 UTC (permalink / raw)
To: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <0B94CA7CD279474EAAF856BCEC45BDED-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
Allow the user to specify the qkey when using port space IB. The
qkey is added to struct rdma_ucm_conn_param in place of a reserved
field, but for backwards compatibility, is only accessed if the
associated rdma_cm_id is using the IB port space.
The qkey associated with an id is now set when sending or receiving the
SIDR REP. If the qkey is read before being set, to modify the QP
state early for example, it reverts to the default value.
Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
Changes from v1:
Allow the user to specify the QKey, rather than automatically using
the hard-coded RDMA_QKEY_UDP value.
drivers/infiniband/core/cma.c | 33 ++++++++++++++++++++-------------
drivers/infiniband/core/ucma.c | 11 ++++++++---
include/rdma/rdma_cm.h | 1 +
include/rdma/rdma_user_cm.h | 2 +-
4 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index ccf47c6..f8ca424 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -293,16 +293,25 @@ static void cma_detach_from_dev(struct rdma_id_private *id_priv)
id_priv->cma_dev = NULL;
}
-static int cma_set_qkey(struct rdma_id_private *id_priv)
+static int cma_set_qkey(struct rdma_id_private *id_priv, u32 qkey)
{
struct ib_sa_mcmember_rec rec;
int ret = 0;
- if (id_priv->qkey)
+ if (id_priv->qkey) {
+ if (qkey && id_priv->qkey != qkey)
+ return -EINVAL;
return 0;
+ }
+
+ if (qkey) {
+ id_priv->qkey = qkey;
+ return 0;
+ }
switch (id_priv->id.ps) {
case RDMA_PS_UDP:
+ case RDMA_PS_IB:
id_priv->qkey = RDMA_UDP_QKEY;
break;
case RDMA_PS_IPOIB:
@@ -565,7 +574,7 @@ static int cma_ib_init_qp_attr(struct rdma_id_private *id_priv,
*qp_attr_mask = IB_QP_STATE | IB_QP_PKEY_INDEX | IB_QP_PORT;
if (id_priv->id.qp_type == IB_QPT_UD) {
- ret = cma_set_qkey(id_priv);
+ ret = cma_set_qkey(id_priv, 0);
if (ret)
return ret;
@@ -2302,15 +2311,10 @@ static int cma_sidr_rep_handler(struct ib_cm_id *cm_id,
event.status = ib_event->param.sidr_rep_rcvd.status;
break;
}
- ret = cma_set_qkey(id_priv);
+ ret = cma_set_qkey(id_priv, rep->qkey);
if (ret) {
event.event = RDMA_CM_EVENT_ADDR_ERROR;
- event.status = -EINVAL;
- break;
- }
- if (id_priv->qkey != rep->qkey) {
- event.event = RDMA_CM_EVENT_UNREACHABLE;
- event.status = -EINVAL;
+ event.status = ret;
break;
}
ib_init_ah_from_path(id_priv->id.device, id_priv->id.port_num,
@@ -2583,7 +2587,7 @@ static int cma_accept_iw(struct rdma_id_private *id_priv,
}
static int cma_send_sidr_rep(struct rdma_id_private *id_priv,
- enum ib_cm_sidr_status status,
+ enum ib_cm_sidr_status status, u32 qkey,
const void *private_data, int private_data_len)
{
struct ib_cm_sidr_rep_param rep;
@@ -2592,7 +2596,7 @@ static int cma_send_sidr_rep(struct rdma_id_private *id_priv,
memset(&rep, 0, sizeof rep);
rep.status = status;
if (status == IB_SIDR_SUCCESS) {
- ret = cma_set_qkey(id_priv);
+ ret = cma_set_qkey(id_priv, qkey);
if (ret)
return ret;
rep.qp_num = id_priv->qp_num;
@@ -2622,6 +2626,7 @@ int rdma_accept(struct rdma_cm_id *id, struct rdma_conn_param *conn_param)
case RDMA_TRANSPORT_IB:
if (id->qp_type == IB_QPT_UD)
ret = cma_send_sidr_rep(id_priv, IB_SIDR_SUCCESS,
+ conn_param->qkey,
conn_param->private_data,
conn_param->private_data_len);
else if (conn_param)
@@ -2682,7 +2687,7 @@ int rdma_reject(struct rdma_cm_id *id, const void *private_data,
switch (rdma_node_get_transport(id->device->node_type)) {
case RDMA_TRANSPORT_IB:
if (id->qp_type == IB_QPT_UD)
- ret = cma_send_sidr_rep(id_priv, IB_SIDR_REJECT,
+ ret = cma_send_sidr_rep(id_priv, IB_SIDR_REJECT, 0,
private_data, private_data_len);
else
ret = ib_send_cm_rej(id_priv->cm_id.ib,
@@ -2743,6 +2748,8 @@ static int cma_ib_mc_handler(int status, struct ib_sa_multicast *multicast)
cma_disable_callback(id_priv, CMA_ADDR_RESOLVED))
return 0;
+ if (!status)
+ status = cma_set_qkey(id_priv, be32_to_cpu(multicast->rec.qkey));
mutex_lock(&id_priv->qp_mutex);
if (!status && id_priv->id.qp)
status = ib_attach_mcast(id_priv->id.qp, &multicast->rec.mgid,
diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
index 723fe83..07afd38 100644
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -655,7 +655,8 @@ out:
return ret;
}
-static void ucma_copy_conn_param(struct rdma_conn_param *dst,
+static void ucma_copy_conn_param(struct rdma_cm_id *id,
+ struct rdma_conn_param *dst,
struct rdma_ucm_conn_param *src)
{
dst->private_data = src->private_data;
@@ -667,6 +668,10 @@ static void ucma_copy_conn_param(struct rdma_conn_param *dst,
dst->rnr_retry_count = src->rnr_retry_count;
dst->srq = src->srq;
dst->qp_num = src->qp_num;
+ if (id->ps == RDMA_PS_IB)
+ dst->qkey = src->qkey;
+ else
+ dst->qkey = 0;
}
static ssize_t ucma_connect(struct ucma_file *file, const char __user *inbuf,
@@ -687,7 +692,7 @@ static ssize_t ucma_connect(struct ucma_file *file, const char __user *inbuf,
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ucma_copy_conn_param(&conn_param, &cmd.conn_param);
+ ucma_copy_conn_param(ctx->cm_id, &conn_param, &cmd.conn_param);
ret = rdma_connect(ctx->cm_id, &conn_param);
ucma_put_ctx(ctx);
return ret;
@@ -731,7 +736,7 @@ static ssize_t ucma_accept(struct ucma_file *file, const char __user *inbuf,
if (cmd.conn_param.valid) {
ctx->uid = cmd.uid;
- ucma_copy_conn_param(&conn_param, &cmd.conn_param);
+ ucma_copy_conn_param(ctx->cm_id, &conn_param, &cmd.conn_param);
ret = rdma_accept(ctx->cm_id, &conn_param);
} else
ret = rdma_accept(ctx->cm_id, NULL);
diff --git a/include/rdma/rdma_cm.h b/include/rdma/rdma_cm.h
index 68e73d1..363e7a3 100644
--- a/include/rdma/rdma_cm.h
+++ b/include/rdma/rdma_cm.h
@@ -99,6 +99,7 @@ struct rdma_conn_param {
/* Fields below ignored if a QP is created on the rdma_cm_id. */
u8 srq;
u32 qp_num;
+ u32 qkey;
};
struct rdma_ud_param {
diff --git a/include/rdma/rdma_user_cm.h b/include/rdma/rdma_user_cm.h
index d88c23c..fa6693c 100644
--- a/include/rdma/rdma_user_cm.h
+++ b/include/rdma/rdma_user_cm.h
@@ -131,7 +131,7 @@ struct rdma_ucm_query_route_resp {
struct rdma_ucm_conn_param {
__u32 qp_num;
- __u32 reserved;
+ __u32 qkey;
__u8 private_data[RDMA_MAX_PRIVATE_DATA];
__u8 private_data_len;
__u8 srq;
--
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