From: Tom Tucker <tom@opengridcomputing.com>
To: Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>,
"J. Bruce Fields" <bfields@fieldses.org>
Cc: NeilBrown <neilb@suse.de>,
Trond Myklebust <Trond.Myklebust@netapp.com>,
<linux-nfs@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH for 2.6.25] SVCRDMA: Use only 1 RDMA read scatter entry for iWARP adapters
Date: Sun, 23 Mar 2008 18:52:49 -0500 [thread overview]
Message-ID: <C40C5781.3E539%tom@opengridcomputing.com> (raw)
In-Reply-To: <adaiqzdt9lb.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
Ack. It's actually an _ancient_ remnant when it had to compile against iWARP
vs. non-iWARP enabled OFA trees.
On 3/23/08 4:27 PM, "Roland Dreier" <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> The iWARP protocol limits RDMA read requests to a single scatter
> entry. NFS/RDMA has code in rdma_read_max_sge() that is supposed to
> limit the sge_count for RDMA read requests to 1, but the code to do
> that is inside an #ifdef RDMA_TRANSPORT_IWARP block. In the mainline
> kernel at least, RDMA_TRANSPORT_IWARP is an enum and not a
> preprocessor #define, so the #ifdef'ed code is never compiled.
>
> In my test of a kernel build with -j8 on an NFS/RDMA mount, this
> problem eventually leads to trouble starting with:
>
> svcrdma: Error posting send = -22
> svcrdma : RDMA_READ error = -22
>
> and things go downhill from there.
>
> The trivial fix is to delete the #ifdef guard. The check seems to be
> a remnant of when the NFS/RDMA code was not merged and needed to
> compile against multiple kernel versions, although I don't think it
> ever worked as intended. In any case now that the code is upstream
> there's no need to test whether the RDMA_TRANSPORT_IWARP constant is
> defined or not.
>
> Without this patch, my kernel build on an NFS/RDMA mount using NetEffect
> adapters quickly and 100% reproducibly failed with an error like:
>
> ld: final link failed: Software caused connection abort
>
> With the patch applied I was able to complete a kernel build on the
> same setup.
>
> Signed-off-by: Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
> ---
> I guess this should probably go into 2.6.25 if possible, since things
> get seriously screwed up in my testing once this bug is hit.
>
> Not sure why this doesn't trigger on Chelsio or Ammasso adapters (or
> does it?), but it's easily reproducible here on Neteffect adapters
> (and that driver is now upstream for 2.6.25).
>
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> index ab54a73..9712716 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> @@ -237,14 +237,12 @@ static void rdma_set_ctxt_sge(struct svc_rdma_op_ctxt
> *ctxt,
>
> static int rdma_read_max_sge(struct svcxprt_rdma *xprt, int sge_count)
> {
> -#ifdef RDMA_TRANSPORT_IWARP
> if ((RDMA_TRANSPORT_IWARP ==
> rdma_node_get_transport(xprt->sc_cm_id->
> device->node_type))
> && sge_count > 1)
> return 1;
> else
> -#endif
> return min_t(int, sge_count, xprt->sc_max_sge);
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Tom Tucker <tom@opengridcomputing.com>
To: Roland Dreier <rdreier@cisco.com>,
"J. Bruce Fields" <bfields@fieldses.org>
Cc: NeilBrown <neilb@suse.de>,
Trond Myklebust <Trond.Myklebust@netapp.com>,
<linux-nfs@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH for 2.6.25] SVCRDMA: Use only 1 RDMA read scatter entry for iWARP adapters
Date: Sun, 23 Mar 2008 18:52:49 -0500 [thread overview]
Message-ID: <C40C5781.3E539%tom@opengridcomputing.com> (raw)
In-Reply-To: <adaiqzdt9lb.fsf@cisco.com>
Ack. It's actually an _ancient_ remnant when it had to compile against iWARP
vs. non-iWARP enabled OFA trees.
On 3/23/08 4:27 PM, "Roland Dreier" <rdreier@cisco.com> wrote:
> The iWARP protocol limits RDMA read requests to a single scatter
> entry. NFS/RDMA has code in rdma_read_max_sge() that is supposed to
> limit the sge_count for RDMA read requests to 1, but the code to do
> that is inside an #ifdef RDMA_TRANSPORT_IWARP block. In the mainline
> kernel at least, RDMA_TRANSPORT_IWARP is an enum and not a
> preprocessor #define, so the #ifdef'ed code is never compiled.
>
> In my test of a kernel build with -j8 on an NFS/RDMA mount, this
> problem eventually leads to trouble starting with:
>
> svcrdma: Error posting send = -22
> svcrdma : RDMA_READ error = -22
>
> and things go downhill from there.
>
> The trivial fix is to delete the #ifdef guard. The check seems to be
> a remnant of when the NFS/RDMA code was not merged and needed to
> compile against multiple kernel versions, although I don't think it
> ever worked as intended. In any case now that the code is upstream
> there's no need to test whether the RDMA_TRANSPORT_IWARP constant is
> defined or not.
>
> Without this patch, my kernel build on an NFS/RDMA mount using NetEffect
> adapters quickly and 100% reproducibly failed with an error like:
>
> ld: final link failed: Software caused connection abort
>
> With the patch applied I was able to complete a kernel build on the
> same setup.
>
> Signed-off-by: Roland Dreier <rolandd@cisco.com>
> ---
> I guess this should probably go into 2.6.25 if possible, since things
> get seriously screwed up in my testing once this bug is hit.
>
> Not sure why this doesn't trigger on Chelsio or Ammasso adapters (or
> does it?), but it's easily reproducible here on Neteffect adapters
> (and that driver is now upstream for 2.6.25).
>
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> index ab54a73..9712716 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> @@ -237,14 +237,12 @@ static void rdma_set_ctxt_sge(struct svc_rdma_op_ctxt
> *ctxt,
>
> static int rdma_read_max_sge(struct svcxprt_rdma *xprt, int sge_count)
> {
> -#ifdef RDMA_TRANSPORT_IWARP
> if ((RDMA_TRANSPORT_IWARP ==
> rdma_node_get_transport(xprt->sc_cm_id->
> device->node_type))
> && sge_count > 1)
> return 1;
> else
> -#endif
> return min_t(int, sge_count, xprt->sc_max_sge);
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-03-23 23:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-23 21:27 [PATCH for 2.6.25] SVCRDMA: Use only 1 RDMA read scatter entry for iWARP adapters Roland Dreier
2008-03-23 21:27 ` Roland Dreier
[not found] ` <adaiqzdt9lb.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2008-03-23 23:52 ` Tom Tucker [this message]
2008-03-23 23:52 ` Tom Tucker
2008-03-24 3:06 ` FW: " Tom Tucker
2008-03-24 15:44 ` J. Bruce Fields
2008-03-24 16:57 ` Roland Dreier
[not found] ` <adave3crrfj.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2008-03-24 17:05 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C40C5781.3E539%tom@opengridcomputing.com \
--to=tom@opengridcomputing.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.