From: Tom Talpey <tom@talpey.com>
To: Sagi Grimberg <sagig@dev.mellanox.co.il>,
Christoph Hellwig <hch@infradead.org>,
Chuck Lever <chuck.lever@oracle.com>
Cc: linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org,
Sagi Grimberg <sagig@mellanox.com>
Subject: Re: [PATCH v1 3/9] xprtrdma: Introduce ro_unmap_sync method
Date: Tue, 24 Nov 2015 08:43:26 -0500 [thread overview]
Message-ID: <5654697E.1030809@talpey.com> (raw)
In-Reply-To: <565442F5.7080400@dev.mellanox.co.il>
On 11/24/2015 5:59 AM, Sagi Grimberg wrote:
> As I see it, if we don't wait for local-invalidate to complete before
> unmap and IO completion (and no one does)
For the record, that is false. Windows quite strictly performs these
steps, and deliver millions of real 4K IOPS over SMB Direct.
> Waiting for local invalidate to complete would be a really big
> sacrifice for our storage ULPs.
Not waiting would also be a sacrifice, by compromising data integrity.
It's a tough tradeoff, but if you choose to go that way it will be
critical to be honest about the consequences to the data.
Tom.
WARNING: multiple messages have this Message-ID (diff)
From: Tom Talpey <tom-CLs1Zie5N5HQT0dZR+AlfA@public.gmane.org>
To: Sagi Grimberg
<sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>,
Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Sagi Grimberg <sagig-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCH v1 3/9] xprtrdma: Introduce ro_unmap_sync method
Date: Tue, 24 Nov 2015 08:43:26 -0500 [thread overview]
Message-ID: <5654697E.1030809@talpey.com> (raw)
In-Reply-To: <565442F5.7080400-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
On 11/24/2015 5:59 AM, Sagi Grimberg wrote:
> As I see it, if we don't wait for local-invalidate to complete before
> unmap and IO completion (and no one does)
For the record, that is false. Windows quite strictly performs these
steps, and deliver millions of real 4K IOPS over SMB Direct.
> Waiting for local invalidate to complete would be a really big
> sacrifice for our storage ULPs.
Not waiting would also be a sacrifice, by compromising data integrity.
It's a tough tradeoff, but if you choose to go that way it will be
critical to be honest about the consequences to the data.
Tom.
--
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-11-24 13:43 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 22:13 [PATCH v1 0/9] NFS/RDMA client patches for 4.5 Chuck Lever
2015-11-23 22:13 ` Chuck Lever
2015-11-23 22:13 ` [PATCH v1 1/9] xprtrdma: Add a safety margin for receive buffers Chuck Lever
2015-11-23 22:13 ` Chuck Lever
2015-11-24 0:55 ` Tom Talpey
2015-11-24 0:55 ` Tom Talpey
2015-11-24 1:16 ` Chuck Lever
2015-11-24 1:16 ` Chuck Lever
2015-11-24 1:22 ` Tom Talpey
2015-11-24 1:22 ` Tom Talpey
2015-11-24 1:44 ` Chuck Lever
2015-11-24 1:44 ` Chuck Lever
2015-11-23 22:14 ` [PATCH v1 2/9] xprtrdma: Move struct ib_send_wr off the stack Chuck Lever
2015-11-23 22:14 ` Chuck Lever
2015-11-23 22:14 ` [PATCH v1 3/9] xprtrdma: Introduce ro_unmap_sync method Chuck Lever
2015-11-23 22:14 ` Chuck Lever
2015-11-24 6:45 ` Christoph Hellwig
2015-11-24 6:45 ` Christoph Hellwig
2015-11-24 7:28 ` Jason Gunthorpe
2015-11-24 7:28 ` Jason Gunthorpe
2015-11-24 10:59 ` Sagi Grimberg
2015-11-24 10:59 ` Sagi Grimberg
2015-11-24 13:43 ` Tom Talpey [this message]
2015-11-24 13:43 ` Tom Talpey
2015-11-24 14:40 ` Sagi Grimberg
2015-11-24 14:40 ` Sagi Grimberg
2015-11-24 14:39 ` Chuck Lever
2015-11-24 14:39 ` Chuck Lever
2015-11-24 14:44 ` Sagi Grimberg
2015-11-24 14:44 ` Sagi Grimberg
2015-11-24 15:20 ` Chuck Lever
2015-11-24 15:20 ` Chuck Lever
2015-11-24 18:57 ` Jason Gunthorpe
2015-11-24 18:57 ` Jason Gunthorpe
2015-11-23 22:14 ` [PATCH v1 4/9] xprtrdma: Add ro_unmap_sync method for FRWR Chuck Lever
2015-11-23 22:14 ` Chuck Lever
2015-11-23 22:14 ` [PATCH v1 5/9] xprtrdma: Add ro_unmap_sync method for FMR Chuck Lever
2015-11-23 22:14 ` Chuck Lever
2015-11-24 0:57 ` Tom Talpey
2015-11-24 0:57 ` Tom Talpey
2015-11-24 6:52 ` Future of FMR support, was: " Christoph Hellwig
2015-11-24 6:52 ` Christoph Hellwig
2015-11-24 7:12 ` Jason Gunthorpe
2015-11-24 7:12 ` Jason Gunthorpe
2015-12-01 15:33 ` Chuck Lever
2015-12-01 15:33 ` Chuck Lever
2015-12-02 12:27 ` Christoph Hellwig
2015-12-02 12:27 ` Christoph Hellwig
2015-11-24 12:36 ` Tom Talpey
2015-11-24 12:36 ` Tom Talpey
2015-11-24 21:54 ` santosh shilimkar
2015-11-24 21:54 ` santosh shilimkar
2015-11-25 9:00 ` Christoph Hellwig
2015-11-25 9:00 ` Christoph Hellwig
2015-11-25 17:09 ` santosh shilimkar
2015-11-25 17:09 ` santosh shilimkar
2015-11-25 18:22 ` Or Gerlitz
2015-11-25 18:22 ` Or Gerlitz
2015-11-25 19:17 ` santosh shilimkar
2015-11-25 19:17 ` santosh shilimkar
2015-11-25 19:28 ` Jason Gunthorpe
2015-11-25 19:28 ` Jason Gunthorpe
2015-11-26 10:01 ` Sagi Grimberg
2015-11-26 10:01 ` Sagi Grimberg
2015-11-23 22:14 ` [PATCH v1 6/9] xprtrdma: Add ro_unmap_sync method for all-physical registration Chuck Lever
2015-11-23 22:14 ` Chuck Lever
2015-11-23 22:14 ` [PATCH v1 7/9] SUNRPC: Introduct xprt_commit_rqst() Chuck Lever
2015-11-23 22:14 ` Chuck Lever
2015-11-24 19:54 ` Anna Schumaker
2015-11-24 19:54 ` Anna Schumaker
2015-11-24 19:56 ` Chuck Lever
2015-11-24 19:56 ` Chuck Lever
2015-11-23 22:14 ` [PATCH v1 8/9] xprtrdma: Invalidate in the RPC reply handler Chuck Lever
2015-11-23 22:14 ` Chuck Lever
2015-11-24 1:01 ` Tom Talpey
2015-11-24 1:01 ` Tom Talpey
2015-11-23 22:15 ` [PATCH v1 9/9] xprtrdma: Revert commit e7104a2a9606 ('xprtrdma: Cap req_cqinit') Chuck Lever
2015-11-23 22:15 ` 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=5654697E.1030809@talpey.com \
--to=tom@talpey.com \
--cc=chuck.lever@oracle.com \
--cc=hch@infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=sagig@dev.mellanox.co.il \
--cc=sagig@mellanox.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 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.