From: Jakub Kicinski <kuba@kernel.org>
To: Mark Bloch <mbloch@nvidia.com>
Cc: Saeed Mahameed <saeed@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Saeed Mahameed <saeedm@nvidia.com>,
netdev@vger.kernel.org, Tariq Toukan <tariqt@nvidia.com>,
Roi Dayan <roid@nvidia.com>, Maor Dickman <maord@nvidia.com>
Subject: Re: [net-next 01/15] net/mlx5: Lag, Let user configure multiport eswitch
Date: Tue, 14 Feb 2023 12:40:55 -0800 [thread overview]
Message-ID: <20230214124055.6e9df4dd@kernel.org> (raw)
In-Reply-To: <b4300690-f9a3-5de6-08f8-0b3430db7fd8@nvidia.com>
On Tue, 14 Feb 2023 09:31:10 +0200 Mark Bloch wrote:
> > Oh, the "legacy software where updating the logic isn't possible"
> > sounds concerning. Do we know what those cases are? Can we perhaps
> > constrain them to run on a specific version of HW (say starting with
> > CX8 the param will no longer be there and only the right behavior will
> > be supported upstream)?
>
> While I can encourage customers to update their software to deal with
> this new mode it's up to them. As you already know, it's hard to change
> customers infrastructure so quickly. These things take time. They plan
> on running multiple hardware generations on top of the same software.
> I'll keep pushing on making this mode the default one.
I think we should document some time horizon. We can always push it
back but having a concrete plan in place may motive users. Also it's
useful to point at and say "we warned you".
Doesn't have to be anything very imminent, time flies.
next prev parent reply other threads:[~2023-02-14 20:41 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 22:18 [pull request][net-next 00/15] mlx5 updates 2023-02-10 Saeed Mahameed
2023-02-10 22:18 ` [net-next 01/15] net/mlx5: Lag, Let user configure multiport eswitch Saeed Mahameed
2023-02-11 4:03 ` Jakub Kicinski
2023-02-13 11:32 ` Jiri Pirko
2023-02-13 19:00 ` Mark Bloch
2023-02-14 2:02 ` Jakub Kicinski
2023-02-14 7:31 ` Mark Bloch
2023-02-14 20:40 ` Jakub Kicinski [this message]
2023-02-14 21:50 ` Saeed Mahameed
2023-02-14 13:38 ` Jiri Pirko
2023-02-14 17:07 ` Alexander Lobakin
2023-02-14 21:49 ` Saeed Mahameed
2023-02-15 11:46 ` Leon Romanovsky
2023-02-15 17:04 ` Alexander Lobakin
2023-02-15 19:41 ` Saeed Mahameed
2023-02-10 22:18 ` [net-next 02/15] net/mlx5e: TC, Add peer flow in mpesw mode Saeed Mahameed
2023-02-10 22:18 ` [net-next 03/15] net/mlx5: E-Switch, rename bond update function to be reused Saeed Mahameed
2023-02-10 22:18 ` [net-next 04/15] net/mlx5: Lag, set different uplink vport metadata in multiport eswitch mode Saeed Mahameed
2023-02-10 22:18 ` [net-next 05/15] net/mlx5: Lag, Add single RDMA device in multiport mode Saeed Mahameed
2023-02-10 22:18 ` [net-next 06/15] net/mlx5e: Use a simpler comparison for uplink rep Saeed Mahameed
2023-02-10 22:18 ` [net-next 07/15] net/mlx5e: TC, Remove redundant parse_attr argument Saeed Mahameed
2023-02-10 22:18 ` [net-next 08/15] net/mlx5: Remove outdated comment Saeed Mahameed
2023-02-10 22:18 ` [net-next 09/15] net/mlx5e: Pass mdev to mlx5e_devlink_port_register() Saeed Mahameed
2023-02-10 22:18 ` [net-next 10/15] net/mlx5e: Replace usage of mlx5e_devlink_get_dl_port() by netdev->devlink_port Saeed Mahameed
2023-02-10 22:18 ` [net-next 11/15] net/mlx5e: Move dl_port to struct mlx5e_dev Saeed Mahameed
2023-02-10 22:18 ` [net-next 12/15] net/mlx5e: Move devlink port registration to be done before netdev alloc Saeed Mahameed
2023-02-10 22:18 ` [net-next 13/15] net/mlx5e: Create auxdev devlink instance in the same ns as parent devlink Saeed Mahameed
2023-02-10 22:18 ` [net-next 14/15] net/mlx5: Remove "recovery" arg from mlx5_load_one() function Saeed Mahameed
2023-02-10 22:18 ` [net-next 15/15] net/mlx5: Suspend auxiliary devices only in case of PCI device suspend Saeed Mahameed
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=20230214124055.6e9df4dd@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=maord@nvidia.com \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=roid@nvidia.com \
--cc=saeed@kernel.org \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.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;
as well as URLs for NNTP newsgroup(s).