From: "Steve Wise" <swise@opengridcomputing.com>
To: "'Sagi Grimberg'" <sagi@grimberg.me>, <linux-nvme@lists.infradead.org>
Cc: <linux-block@vger.kernel.org>, <linux-rdma@vger.kernel.org>,
"'Christoph Hellwig'" <hch@lst.de>,
"'Keith Busch'" <keith.busch@intel.com>
Subject: RE: [PATCH RFC 0/4] restore polling to nvme-rdma
Date: Wed, 12 Dec 2018 12:10:45 -0600 [thread overview]
Message-ID: <033101d49246$00d1c320$02754960$@opengridcomputing.com> (raw)
In-Reply-To: <bd50927c-c72b-01f6-bad7-080076610cde@grimberg.me>
> > Hey Sagi,
>
> Hi Steve,
>
> > Is there no way to handle this in the core? Maybe have the polling context
> > transition to DIRECT when the queue becomes empty and before re-arming
> the
> > CQ?
>
> That is what I suggested, but that would mean that we we need to drain
> the cq before making the switch, which means we need to allocate a
> dedicated qp for that cq, and even that doesn't guarantee that the
> ULP is not posting other wrs on its own qp(s)...
>
> So making this safe for infight I/O would be a challenge... If we end
> up agreeing that we are ok with this functionality, I'd much rather not
> deal with it and simply document "use with care".
>
> > So ib_change_cq_ctx() would be called to indicate the change should
> > happen when it is safe to do so.
>
> You lost me here... ib_change_cq_ctx would get called by who and when?
I didn't look in detail at your changes, but ib_change_cq_ctx() is called by the application, right? I was just asking what if the semantics of the call were "change the context when it is safe to do so" vs "do it immediately and hope there are no outstanding WRs". But I don't think this semantic change simplifies the problem.
prev parent reply other threads:[~2018-12-12 18:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 23:36 [PATCH RFC 0/4] restore polling to nvme-rdma Sagi Grimberg
2018-12-11 23:36 ` [PATCH RFC 1/4] nvme-fabrics: allow user to pass in nr_poll_queues Sagi Grimberg
2018-12-11 23:36 ` [PATCH RFC 2/4] rdma: introduce ib_change_cq_ctx Sagi Grimberg
2018-12-11 23:36 ` [PATCH RFC 3/4] nvme-rdma: implement polling queue map Sagi Grimberg
2018-12-11 23:36 ` [PATCH RFC 4/4] nvme-multipath: disable polling for underlying namespace request queue Sagi Grimberg
2018-12-12 7:11 ` Christoph Hellwig
2018-12-12 7:19 ` Sagi Grimberg
2018-12-12 7:21 ` Christoph Hellwig
2018-12-12 7:29 ` Sagi Grimberg
2018-12-12 7:37 ` Christoph Hellwig
2018-12-11 23:36 ` [PATCH RFC nvme-cli 5/4] fabrics: pass in number of polling queues Sagi Grimberg
2018-12-12 0:27 ` Sagi Grimberg
2018-12-12 7:07 ` [PATCH RFC 0/4] restore polling to nvme-rdma Christoph Hellwig
2018-12-12 7:16 ` Sagi Grimberg
2018-12-12 8:09 ` Christoph Hellwig
2018-12-12 8:53 ` Sagi Grimberg
2018-12-12 14:05 ` Christoph Hellwig
2018-12-12 18:23 ` Sagi Grimberg
2018-12-12 16:37 ` Steve Wise
2018-12-12 18:05 ` Sagi Grimberg
2018-12-12 18:10 ` Steve Wise [this message]
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='033101d49246$00d1c320$02754960$@opengridcomputing.com' \
--to=swise@opengridcomputing.com \
--cc=hch@lst.de \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-rdma@vger.kernel.org \
--cc=sagi@grimberg.me \
/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).