From: "Steve Wise" <swise@opengridcomputing.com>
To: "'J. Bruce Fields'" <bfields@fieldses.org>
Cc: "'Devesh Sharma'" <Devesh.Sharma@Emulex.Com>,
<linux-nfs@vger.kernel.org>, <linux-rdma@vger.kernel.org>,
<tom@opengridcomputing.com>
Subject: RE: [PATCH V3] svcrdma: refactor marshalling logic
Date: Mon, 2 Jun 2014 12:06:39 -0500 [thread overview]
Message-ID: <004b01cf7e85$04c6c7c0$0e545740$@opengridcomputing.com> (raw)
In-Reply-To: <20140602165716.GB20031@fieldses.org>
> On Mon, Jun 02, 2014 at 11:52:47AM -0500, Steve Wise wrote:
> > > > You're correct. And this bug appears to be in the current upstream code as well.
If
> > an
> > > > IB_WR_LOCAL_INV wr is used, it must include IB_SEND_FENCE to fence it until the
prior
> > > read
> > > > completes.
> > > >
> > > > Good catch! I'll post V4 soon.
> > >
> > > Any chance that can be handled as a separate patch rather than folded
> > > in?
> > >
> > > (Disclaimer: I've been following the discussion only very
> > > superficially.)
> > >
> >
> > Sure. I'll post the patch soon.
>
> Thanks, and, again, I'm not terribly happy about the monster
> patch--anything you can split off it is great, even if that thing's
> small. As long as all the intermediate stages still build and run.
>
I don't see any way to do this for this particular patch. It rewrites the entire rdma
read logic.
> (And any bugs you've identified in upstream code are good candidates for
> separate patches, hopefully preceding the rewrite. That also allows us
> to apply those fixes to stable kernels if appropriate.)
>
If I do this, then I'd have to respin the refactor patch. I really would like to get this
merged as-is (with the one change I'm sending soon), and move on. I definitely will try
and keep the patches smaller and more discrete going forward.
Will that work?
Steve.
next prev parent reply other threads:[~2014-06-02 17:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-29 16:55 [PATCH V3] svcrdma: refactor marshalling logic Steve Wise
2014-05-29 23:43 ` Chuck Lever
2014-05-30 5:29 ` Devesh Sharma
2014-05-30 13:02 ` Steve Wise
2014-05-31 3:34 ` Devesh Sharma
2014-06-02 16:47 ` Steve Wise
2014-06-02 16:51 ` J. Bruce Fields
2014-06-02 16:52 ` Steve Wise
2014-06-02 16:57 ` 'J. Bruce Fields'
2014-06-02 17:06 ` Steve Wise [this message]
2014-06-02 18:10 ` '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='004b01cf7e85$04c6c7c0$0e545740$@opengridcomputing.com' \
--to=swise@opengridcomputing.com \
--cc=Devesh.Sharma@Emulex.Com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=tom@opengridcomputing.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).