From: Leon Romanovsky <leonro@mellanox.com>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Idan Burstein <idanb@mellanox.com>,
Saeed Mahameed <saeedm@mellanox.com>,
"David S. Miller" <davem@davemloft.net>,
Doug Ledford <dledford@redhat.com>,
Jason Gunthorpe <jgg@mellanox.com>,
Or Gerlitz <ogerlitz@mellanox.com>,
Tal Gilboa <talgi@mellanox.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Yamin Friedman <yaminf@mellanox.com>,
Max Gurtovoy <maxg@mellanox.com>
Subject: Re: [for-next V2 10/10] RDMA/core: Provide RDMA DIM support for ULPs
Date: Tue, 2 Jul 2019 06:41:09 +0000 [thread overview]
Message-ID: <20190702064107.GS4727@mtr-leonro.mtl.com> (raw)
In-Reply-To: <9d26c90c-8e0b-656f-341f-a67251549126@grimberg.me>
On Mon, Jul 01, 2019 at 10:36:41PM -0700, Sagi Grimberg wrote:
> Hey Idan,
>
> > " Please don't. This is a bad choice to opt it in by default."
> >
> > I disagree here. I'd prefer Linux to have good out of the box experience (e.g. reach 100G in 4K NVMeOF on Intel servers) with the default parameters. Especially since Yamin have shown it is beneficial / not hurting in terms of performance for variety of use cases. The whole concept of DIM is that it adapts to the workload requirements in terms of bandwidth and latency.
>
> Well, its a Mellanox device driver after all.
>
> But do note that by far, the vast majority of users are not saturating
> 100G of 4K I/O. The absolute vast majority of users are primarily
> sensitive to synchronous QD=1 I/O latency, and when the workload
> is much more dynamic than the synthetic 100%/50%/0% read mix.
>
> As much as I'm a fan (IIRC I was the one giving a first pass at this),
> the dim default opt-in is not only not beneficial, but potentially
> harmful to the majority of users out-of-the-box experience.
>
> Given that this is a fresh code with almost no exposure, and that was
> not tested outside of Yamin running limited performance testing, I think
> it would be a mistake to add it as a default opt-in, that can come as an
> incremental stage.
>
> Obviously, I cannot tell what Mellanox should/shouldn't do in its own
> device driver of course, but I just wanted to emphasize that I think
> this is a mistake.
Hi Sagi,
I'm not sharing your worries about bad out-of-the-box experience for a
number of reasons.
First of all, this code is part of upstream kernel and will take time
till users actually start to use it as is and not as part of some distro
backports or MOFED packages.
Second, Yamin did extensive testing and worked very close with Or G.
and I have very high confident in the results of their team work.
Third (outcome of first), actually the opposite is true, the setting
this option as a default will give us more time to fix/adjust code if
needed, before users will see any potential degradation.
>
> > Moreover, net-dim is enabled by default, I don't see why RDMA is different.
>
> Very different animals.
Yes and no, the logic behind is the same and both solutions have same
constrains of throughput vs. latency.
Thanks
next prev parent reply other threads:[~2019-07-02 6:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-25 20:57 [pull request][for-next V2 0/7] Generic DIM lib for netdev and RDMA Saeed Mahameed
2019-06-25 20:57 ` [for-next V2 01/10] linux/dim: Move logic to dim.h Saeed Mahameed
2019-06-25 21:53 ` Sagi Grimberg
2019-06-25 20:57 ` [for-next V2 02/10] linux/dim: Remove "net" prefix from internal DIM members Saeed Mahameed
2019-06-25 21:53 ` Sagi Grimberg
2019-06-25 20:57 ` [for-next V2 03/10] linux/dim: Rename externally exposed macros Saeed Mahameed
2019-06-25 21:54 ` Sagi Grimberg
2019-06-25 20:57 ` [for-next V2 04/10] linux/dim: Rename net_dim_sample() to net_dim_update_sample() Saeed Mahameed
2019-06-25 21:55 ` Sagi Grimberg
2019-06-25 20:57 ` [for-next V2 05/10] linux/dim: Rename externally used net_dim members Saeed Mahameed
2019-06-25 21:57 ` Sagi Grimberg
2019-06-26 6:38 ` Tal Gilboa
2019-06-25 20:57 ` [for-next V2 06/10] linux/dim: Move implementation to .c files Saeed Mahameed
2019-07-02 16:15 ` Geert Uytterhoeven
2019-06-25 20:57 ` [for-next V2 07/10] linux/dim: Add completions count to dim_sample Saeed Mahameed
2019-06-25 20:57 ` [for-next V2 08/10] linux/dim: Implement rdma_dim Saeed Mahameed
2019-06-25 22:02 ` Sagi Grimberg
2019-06-26 11:57 ` Or Gerlitz
2019-06-27 5:25 ` Yamin Friedman
2019-06-25 20:57 ` [for-next V2 09/10] RDMA/nldev: Added configuration of RDMA dynamic interrupt moderation to netlink Saeed Mahameed
2019-06-25 21:15 ` Sagi Grimberg
2019-06-27 5:29 ` Yamin Friedman
2019-06-25 20:57 ` [for-next V2 10/10] RDMA/core: Provide RDMA DIM support for ULPs Saeed Mahameed
2019-06-25 21:14 ` Sagi Grimberg
2019-06-26 7:56 ` Idan Burstein
2019-07-02 5:36 ` Sagi Grimberg
2019-07-02 6:41 ` Leon Romanovsky [this message]
[not found] ` <8d525d64-6da1-48c3-952d-8c6b0d541859@grimberg.me>
2019-07-04 7:51 ` Leon Romanovsky
2019-07-04 12:30 ` Idan Burstein
2019-06-27 5:28 ` Yamin Friedman
2019-06-25 21:07 ` [pull request][for-next V2 0/7] Generic DIM lib for netdev and RDMA Saeed Mahameed
2019-06-27 19:43 ` David Miller
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=20190702064107.GS4727@mtr-leonro.mtl.com \
--to=leonro@mellanox.com \
--cc=davem@davemloft.net \
--cc=dledford@redhat.com \
--cc=idanb@mellanox.com \
--cc=jgg@mellanox.com \
--cc=linux-rdma@vger.kernel.org \
--cc=maxg@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=saeedm@mellanox.com \
--cc=sagi@grimberg.me \
--cc=talgi@mellanox.com \
--cc=yaminf@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox