All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sagi Grimberg <sagig@dev.mellanox.co.il>
To: Tom Talpey <tom@talpey.com>,
	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 16:40:16 +0200	[thread overview]
Message-ID: <565476D0.3020607@dev.mellanox.co.il> (raw)
In-Reply-To: <5654697E.1030809@talpey.com>

Hey Tom,

> 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,

I meant Linux ULPs. I'm not very familiar with Windows SMBD.

> and deliver millions of real 4K IOPS over SMB Direct.

That's very encouraging! Is this the client side scaling?
 From my experience, getting a storage client/initiator to scale
up to 1.5-3 MIOPs over a single HCA with limited number of cores
is really a struggle for each interrupt and cacheline.

Still the latency of each IO will see a noticable increase.

>> 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.

That's true. I assume that the best compromise would be remote
invalidation but some standards needs enhancements and it doesn't solve
the multi-rkey transactions.

As storage devices are becoming faster we really should try to do our
best to keep up.

WARNING: multiple messages have this Message-ID (diff)
From: Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
To: Tom Talpey <tom-CLs1Zie5N5HQT0dZR+AlfA@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 16:40:16 +0200	[thread overview]
Message-ID: <565476D0.3020607@dev.mellanox.co.il> (raw)
In-Reply-To: <5654697E.1030809-CLs1Zie5N5HQT0dZR+AlfA@public.gmane.org>

Hey Tom,

> 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,

I meant Linux ULPs. I'm not very familiar with Windows SMBD.

> and deliver millions of real 4K IOPS over SMB Direct.

That's very encouraging! Is this the client side scaling?
 From my experience, getting a storage client/initiator to scale
up to 1.5-3 MIOPs over a single HCA with limited number of cores
is really a struggle for each interrupt and cacheline.

Still the latency of each IO will see a noticable increase.

>> 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.

That's true. I assume that the best compromise would be remote
invalidation but some standards needs enhancements and it doesn't solve
the multi-rkey transactions.

As storage devices are becoming faster we really should try to do our
best to keep up.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2015-11-24 14:40 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
2015-11-24 13:43         ` Tom Talpey
2015-11-24 14:40         ` Sagi Grimberg [this message]
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=565476D0.3020607@dev.mellanox.co.il \
    --to=sagig@dev.mellanox.co.il \
    --cc=chuck.lever@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sagig@mellanox.com \
    --cc=tom@talpey.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.