From: Sagi Grimberg <sagig@dev.mellanox.co.il>
To: Chuck Lever <chuck.lever@oracle.com>,
Devesh Sharma <devesh.sharma@avagotech.com>
Cc: linux-rdma@vger.kernel.org,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1 03/18] xprtrdma: Remove completion polling budgets
Date: Sun, 20 Sep 2015 13:35:59 +0300 [thread overview]
Message-ID: <55FE8C0F.1050706@dev.mellanox.co.il> (raw)
In-Reply-To: <A3B1A836-81AF-40E6-B551-587B7173B72D@oracle.com>
>> It is possible that in a given poll_cq
>> call you end up getting on 1 completion, the other completion is
>> delayed due to some reason.
>
> If a CQE is allowed to be delayed, how does polling
> again guarantee that the consumer can retrieve it?
>
> What happens if a signal occurs, there is only one CQE,
> but it is delayed? ib_poll_cq would return 0 in that
> case, and the consumer would never call again, thinking
> the CQ is empty. There's no way the consumer can know
> for sure when a CQ is drained.
>
> If the delayed CQE happens only when there is more
> than one CQE, how can polling multiple WCs ever work
> reliably?
>
> Maybe I don't understand what is meant by delayed.
>
If I'm not mistaken, Devesh meant that if between ib_poll_cq (where you
polled the last 2 wcs) until the while statement another CQE was
generated then you lost a bit of efficiency. Correct?
>
>> Would it be better to poll for 1 in every
>> poll call Or
>> otherwise have this
>> while ( rc <= ARRAY_SIZE(wcs) && rc);
>>
WARNING: multiple messages have this Message-ID (diff)
From: Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
To: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
Devesh Sharma
<devesh.sharma-1wcpHE2jlwO1Z/+hSey0Gg@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux NFS Mailing List
<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v1 03/18] xprtrdma: Remove completion polling budgets
Date: Sun, 20 Sep 2015 13:35:59 +0300 [thread overview]
Message-ID: <55FE8C0F.1050706@dev.mellanox.co.il> (raw)
In-Reply-To: <A3B1A836-81AF-40E6-B551-587B7173B72D-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>> It is possible that in a given poll_cq
>> call you end up getting on 1 completion, the other completion is
>> delayed due to some reason.
>
> If a CQE is allowed to be delayed, how does polling
> again guarantee that the consumer can retrieve it?
>
> What happens if a signal occurs, there is only one CQE,
> but it is delayed? ib_poll_cq would return 0 in that
> case, and the consumer would never call again, thinking
> the CQ is empty. There's no way the consumer can know
> for sure when a CQ is drained.
>
> If the delayed CQE happens only when there is more
> than one CQE, how can polling multiple WCs ever work
> reliably?
>
> Maybe I don't understand what is meant by delayed.
>
If I'm not mistaken, Devesh meant that if between ib_poll_cq (where you
polled the last 2 wcs) until the while statement another CQE was
generated then you lost a bit of efficiency. Correct?
>
>> Would it be better to poll for 1 in every
>> poll call Or
>> otherwise have this
>> while ( rc <= ARRAY_SIZE(wcs) && rc);
>>
--
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
next prev parent reply other threads:[~2015-09-20 10:35 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 20:44 [PATCH v1 00/18] RFC NFS/RDMA patches for merging into v4.4 Chuck Lever
2015-09-17 20:44 ` Chuck Lever
2015-09-17 20:44 ` [PATCH v1 01/18] xprtrdma: Enable swap-on-NFS/RDMA Chuck Lever
2015-09-17 20:44 ` Chuck Lever
2015-09-21 8:58 ` Devesh Sharma
2015-09-21 8:58 ` Devesh Sharma
2015-09-17 20:44 ` [PATCH v1 02/18] xprtrdma: Replace global lkey with lkey local to PD Chuck Lever
2015-09-17 20:44 ` Chuck Lever
2015-09-21 8:59 ` Devesh Sharma
2015-09-21 8:59 ` Devesh Sharma
2015-09-17 20:44 ` [PATCH v1 03/18] xprtrdma: Remove completion polling budgets Chuck Lever
2015-09-17 20:44 ` Chuck Lever
2015-09-18 6:52 ` Devesh Sharma
2015-09-18 6:52 ` Devesh Sharma
2015-09-18 14:19 ` Chuck Lever
2015-09-18 14:19 ` Chuck Lever
2015-09-20 10:35 ` Sagi Grimberg [this message]
2015-09-20 10:35 ` Sagi Grimberg
2015-09-21 8:51 ` Devesh Sharma
2015-09-21 8:51 ` Devesh Sharma
2015-09-21 15:45 ` Chuck Lever
2015-09-21 15:45 ` Chuck Lever
2015-09-22 17:32 ` Devesh Sharma
2015-09-22 17:32 ` Devesh Sharma
2015-10-01 16:37 ` Chuck Lever
2015-10-01 16:37 ` Chuck Lever
2015-10-01 17:13 ` Jason Gunthorpe
2015-10-01 17:13 ` Jason Gunthorpe
2015-10-01 17:36 ` Chuck Lever
2015-10-01 17:36 ` Chuck Lever
2015-10-01 18:15 ` Jason Gunthorpe
2015-10-01 18:15 ` Jason Gunthorpe
2015-10-01 18:31 ` Chuck Lever
2015-10-01 18:31 ` Chuck Lever
2015-10-01 18:38 ` Jason Gunthorpe
2015-10-01 18:38 ` Jason Gunthorpe
2015-09-21 8:51 ` Devesh Sharma
2015-09-21 8:51 ` Devesh Sharma
2015-09-17 20:44 ` [PATCH v1 04/18] xprtrdma: Refactor reply handler error handling Chuck Lever
2015-09-17 20:44 ` Chuck Lever
2015-09-21 8:59 ` Devesh Sharma
2015-09-21 8:59 ` Devesh Sharma
2015-09-17 20:44 ` [PATCH v1 05/18] xprtrdma: Replace send and receive arrays Chuck Lever
2015-09-17 20:44 ` Chuck Lever
2015-09-20 10:52 ` Sagi Grimberg
2015-09-20 10:52 ` Sagi Grimberg
2015-09-21 23:04 ` Chuck Lever
2015-09-21 23:04 ` Chuck Lever
2015-09-17 20:45 ` [PATCH v1 06/18] SUNRPC: Abstract backchannel operations Chuck Lever
2015-09-17 20:45 ` Chuck Lever
2015-09-17 20:45 ` [PATCH v1 07/18] xprtrdma: Pre-allocate backward rpc_rqst and send/receive buffers Chuck Lever
2015-09-17 20:45 ` Chuck Lever
2015-09-21 10:28 ` Devesh Sharma
2015-09-21 10:28 ` Devesh Sharma
2015-09-17 20:45 ` [PATCH v1 08/18] xprtrdma: Pre-allocate Work Requests for backchannel Chuck Lever
2015-09-17 20:45 ` Chuck Lever
2015-09-21 10:33 ` Devesh Sharma
2015-09-21 10:33 ` Devesh Sharma
2015-09-21 22:41 ` Chuck Lever
2015-09-21 22:41 ` Chuck Lever
2015-09-17 20:45 ` [PATCH v1 09/18] xprtrdma: Add support for sending backward direction RPC replies Chuck Lever
2015-09-17 20:45 ` Chuck Lever
2015-09-17 20:45 ` [PATCH v1 10/18] xprtrdma: Handle incoming backward direction RPC calls Chuck Lever
2015-09-17 20:45 ` Chuck Lever
2015-09-17 20:45 ` [PATCH v1 11/18] svcrdma: Add backward direction service for RPC/RDMA transport Chuck Lever
2015-09-17 20:45 ` Chuck Lever
2015-09-17 20:45 ` [PATCH v1 12/18] SUNRPC: Remove the TCP-only restriction in bc_svc_process() Chuck Lever
2015-09-17 20:45 ` Chuck Lever
2015-09-17 20:45 ` [PATCH v1 13/18] NFS: Enable client side NFSv4.1 backchannel to use other transports Chuck Lever
2015-09-17 20:45 ` Chuck Lever
2015-09-17 20:46 ` [PATCH v1 14/18] svcrdma: Define maximum number of backchannel requests Chuck Lever
2015-09-17 20:46 ` Chuck Lever
2015-09-17 20:46 ` [PATCH v1 15/18] svcrdma: Add svc_rdma_get_context() API that is allowed to fail Chuck Lever
2015-09-17 20:46 ` Chuck Lever
2015-09-20 12:40 ` Sagi Grimberg
2015-09-20 12:40 ` Sagi Grimberg
2015-09-21 22:34 ` Chuck Lever
2015-09-21 22:34 ` Chuck Lever
2015-09-17 20:46 ` [PATCH v1 16/18] svcrdma: Add infrastructure to send backwards direction RPC/RDMA calls Chuck Lever
2015-09-17 20:46 ` Chuck Lever
2015-09-17 20:46 ` [PATCH v1 17/18] svcrdma: Add infrastructure to receive backwards direction RPC/RDMA replies Chuck Lever
2015-09-17 20:46 ` Chuck Lever
2015-09-17 20:46 ` [PATCH v1 18/18] xprtrdma: Add class for RDMA backwards direction transport Chuck Lever
2015-09-17 20:46 ` Chuck Lever
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=55FE8C0F.1050706@dev.mellanox.co.il \
--to=sagig@dev.mellanox.co.il \
--cc=chuck.lever@oracle.com \
--cc=devesh.sharma@avagotech.com \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.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.