From: Slava Ovsiienko <viacheslavo@nvidia.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
"Minggang(Gavin) Li" <gavinl@nvidia.com>
Cc: Matan Azrad <matan@nvidia.com>, Ori Kam <orika@nvidia.com>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
Dariusz Sosnowski <dsosnowski@nvidia.com>,
Bing Zhao <bingz@nvidia.com>, Suanming Mou <suanmingm@nvidia.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Raslan Darawsheh <rasland@nvidia.com>,
rongwei liu <rongweil@nvidia.com>
Subject: RE: [PATCH V2 3/7] net/mlx5: add new devargs to control probe optimization
Date: Wed, 30 Oct 2024 08:16:58 +0000 [thread overview]
Message-ID: <DM4PR12MB7549471905F22F8C66F33A44DF542@DM4PR12MB7549.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20241029090712.35ade0c0@hermes.local>
Hi,
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Tuesday, October 29, 2024 6:07 PM
> To: Minggang(Gavin) Li <gavinl@nvidia.com>
> Cc: Slava Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad
> <matan@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas
> Monjalon (EXTERNAL) <thomas@monjalon.net>; Dariusz Sosnowski
> <dsosnowski@nvidia.com>; Bing Zhao <bingz@nvidia.com>; Suanming Mou
> <suanmingm@nvidia.com>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>; rongwei liu <rongweil@nvidia.com>
> Subject: Re: [PATCH V2 3/7] net/mlx5: add new devargs to control probe
> optimization
>
> On Tue, 29 Oct 2024 16:27:25 +0800
> "Minggang(Gavin) Li" <gavinl@nvidia.com> wrote:
>
> > On 10/28/2024 11:47 PM, Stephen Hemminger wrote:
> > > On Mon, 28 Oct 2024 11:18:18 +0200
> > > "Minggang Li(Gavin)" <gavinl@nvidia.com> wrote:
> > >
> > >> +- ``probe_opt_en`` parameter [int]
> > >> +
> > >> + A non-zero value optimizes the probe process, especially for large
> scale.
> > >> + PMD will hold the IB device information internally and reuse it.
> > >> +
> > >> + By default, the PMD will set this value to 0.
> > >> +
> > > Is there ever a case where this should not be used?
> > >
> > > It would be better to just detect and use it if available.
> > > This driver does not need more options...
> > The new mechanism, which is required by few users, so we would not
> > break production and with the option we encourage to use new way only
> > those who actually needs. Once we see the new way is reliable - we
> > will change the default value.
>
> I understand that philosophy but it leads to a maze of technical debt.
This specific case is not about philosophy in general.
We have users with huge number of SFs/VFs configured and experiencing the issues
with gigantic probing timings (literally - tens of minutes). This story was lasting
long time, we were trying different approaches, then admitted we had to update kernel,
etc., and eventually we had things done and it resulted in this series.
The new approach is event driven and based on the handling the new kernel-generated events.
So, it relies on system-wide environment and might be problematic on some hosts (we do not
expect too much though).
At the same time, the existing probe approach provides acceptable performance and
satisfies the vast majority of the users. So, our main objective is not to break anything
in production (most users), the second objective - to resolve issues of some users with
configuration specifics (few users). That's why we would prefer to have the devarg
(with all its cons and pros) and set the devarg default value to false. Later, once the new kernel
API spreads and we have good production statistics we can consider altering the default
value to true or obsolete the devarg at all. Does this approach look reasonable?
> Has a full suite of tests been done with both settings of the option?
> Has both values been tested on all combinations of platforms and OS
> releases?
We cannot keep the new approach only - we have to maintain legacy kernel compatibility.
So - there always will be 2 branches of tests, till legacy kernels retirement. And having the devarg
might even simplify the testing - the single host can be used for both runs, with different devargs values.
> My point is every option adds to the necessary test matrix geometrically!
Once we added the new probing mechanics - the test matrix is ALREADY extended , regardless of devargs
implementation. The devarg just makes our users livings in fields easier.
With best regards,
Slava
next prev parent reply other threads:[~2024-10-30 8:17 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-16 8:38 [PATCH V1 0/7] port probe time optimization Minggang Li(Gavin)
2024-10-16 8:38 ` [PATCH V1 1/7] mailmap: update user name Minggang Li(Gavin)
2024-10-16 8:38 ` [PATCH V1 2/7] net/mlx5: optimize device probing Minggang Li(Gavin)
2024-10-16 8:38 ` [PATCH V1 3/7] net/mlx5: add new devargs to control probe optimization Minggang Li(Gavin)
2024-10-16 8:38 ` [PATCH V1 4/7] common/mlx5: fix Netlink socket leak Minggang Li(Gavin)
2024-10-16 8:38 ` [PATCH V1 5/7] common/mlx5: add RDMA monitor event awareness Minggang Li(Gavin)
2024-10-16 8:38 ` [PATCH V1 6/7] mlx5: use RDMA Netlink to update port information Minggang Li(Gavin)
2024-10-16 8:38 ` [PATCH V1 7/7] mlx5: add backward compatibility for RDMA monitor Minggang Li(Gavin)
2024-10-28 9:18 ` [PATCH V2 0/7] port probe time optimization Minggang Li(Gavin)
2024-10-28 9:18 ` [PATCH V2 1/7] mailmap: update user name Minggang Li(Gavin)
2024-10-28 9:18 ` [PATCH V2 2/7] net/mlx5: optimize device probing Minggang Li(Gavin)
2024-10-28 9:18 ` [PATCH V2 3/7] net/mlx5: add new devargs to control probe optimization Minggang Li(Gavin)
2024-10-28 15:47 ` Stephen Hemminger
2024-10-29 8:27 ` Minggang(Gavin) Li
2024-10-29 16:07 ` Stephen Hemminger
2024-10-30 8:16 ` Slava Ovsiienko [this message]
2024-10-28 9:18 ` [PATCH V2 4/7] common/mlx5: fix Netlink socket leak Minggang Li(Gavin)
2024-10-28 9:18 ` [PATCH V2 5/7] common/mlx5: add RDMA monitor event awareness Minggang Li(Gavin)
2024-10-28 9:18 ` [PATCH V2 6/7] mlx5: use RDMA Netlink to update port information Minggang Li(Gavin)
2024-10-28 9:18 ` [PATCH V2 7/7] mlx5: add backward compatibility for RDMA monitor Minggang Li(Gavin)
2024-10-28 15:49 ` Stephen Hemminger
2024-10-29 8:31 ` Minggang(Gavin) Li
2024-10-29 13:42 ` [PATCH V3 0/7] port probe time optimization Minggang Li(Gavin)
2024-10-29 13:42 ` [PATCH V3 1/7] mailmap: update user name Minggang Li(Gavin)
2024-10-29 13:42 ` [PATCH V3 2/7] net/mlx5: optimize device probing Minggang Li(Gavin)
2024-10-29 13:42 ` [PATCH V3 3/7] net/mlx5: add new devargs to control probe optimization Minggang Li(Gavin)
2024-10-29 16:20 ` Stephen Hemminger
2024-10-29 13:42 ` [PATCH V3 4/7] common/mlx5: fix Netlink socket leak Minggang Li(Gavin)
2024-10-29 13:42 ` [PATCH V3 5/7] common/mlx5: add RDMA monitor event awareness Minggang Li(Gavin)
2024-10-29 13:42 ` [PATCH V3 6/7] mlx5: use RDMA Netlink to update port information Minggang Li(Gavin)
2024-10-29 13:42 ` [PATCH V3 7/7] mlx5: add backward compatibility for RDMA monitor Minggang Li(Gavin)
2024-10-29 14:31 ` [PATCH V3 0/7] port probe time optimization Minggang Li(Gavin)
2024-10-29 14:31 ` [PATCH V3 1/7] mailmap: update user name Minggang Li(Gavin)
2024-10-29 14:31 ` [PATCH V3 2/7] net/mlx5: optimize device probing Minggang Li(Gavin)
2024-10-29 14:31 ` [PATCH V3 3/7] net/mlx5: add new devargs to control probe optimization Minggang Li(Gavin)
2024-10-29 14:31 ` [PATCH V3 4/7] common/mlx5: fix Netlink socket leak Minggang Li(Gavin)
2024-10-29 14:31 ` [PATCH V3 5/7] common/mlx5: add RDMA monitor event awareness Minggang Li(Gavin)
2024-10-29 14:31 ` [PATCH V3 6/7] mlx5: use RDMA Netlink to update port information Minggang Li(Gavin)
2024-10-29 14:31 ` [PATCH V3 7/7] mlx5: add backward compatibility for RDMA monitor Minggang Li(Gavin)
2024-10-29 16:26 ` Stephen Hemminger
2024-10-30 8:25 ` Minggang(Gavin) Li
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=DM4PR12MB7549471905F22F8C66F33A44DF542@DM4PR12MB7549.namprd12.prod.outlook.com \
--to=viacheslavo@nvidia.com \
--cc=bingz@nvidia.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=gavinl@nvidia.com \
--cc=matan@nvidia.com \
--cc=orika@nvidia.com \
--cc=rasland@nvidia.com \
--cc=rongweil@nvidia.com \
--cc=stephen@networkplumber.org \
--cc=suanmingm@nvidia.com \
--cc=thomas@monjalon.net \
/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).