From: Jakub Kicinski <kuba@kernel.org>
To: Saeed Mahameed <saeedm@nvidia.com>
Cc: Saeed Mahameed <saeed@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, Tariq Toukan <tariqt@nvidia.com>,
Moshe Shemesh <moshe@nvidia.com>, Mark Bloch <mbloch@nvidia.com>
Subject: Re: [net-next 14/15] net/mlx5: SRIOV, Add 802.1ad VST support
Date: Wed, 7 Dec 2022 09:25:17 -0800 [thread overview]
Message-ID: <20221207092517.3320f4b4@kernel.org> (raw)
In-Reply-To: <Y5AitsGhZdOdc/Fm@x130>
On Tue, 6 Dec 2022 21:20:54 -0800 Saeed Mahameed wrote:
>> I can't take this with clear conscience :( I started nacking any new use
>> of the legacy VF NDOs. You already have bridging offload implemented,
>> why can bridging be used?
>
> I really tried, many customers aren't ready to make this leap yet.
>
> I understand your point, my goal is to move as many customers to use
> upstream and step away from out of tree drivers, if it makes it any
> easier you can look at this as filling a small gap in mlx5 which will
> help me bring more users to the upstream driver, after all the feature
> is already implemented in mlx5, this is just a small gap we previously
> missed to upstream.
I recently nacked a new driver from AMD which was using legacy NDO, and
they can be somewhat rightfully miffed that those who got there earlier
can keep their support. If we let the older drivers also extend the
support the fairness will suffer even more.
We need to draw the line somewhere, so what do you propose as our
policy? Assuming we want people to move to new APIs and be fair
to new vs old drivers.
next prev parent reply other threads:[~2022-12-07 17:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-03 22:13 [pull request][net-next 00/15] mlx5 updates 2022-12-03 Saeed Mahameed
2022-12-03 22:13 ` [net-next 01/15] net/mlx5e: E-Switch, handle flow attribute with no destinations Saeed Mahameed
2022-12-03 22:13 ` [net-next 02/15] net/mlx5: fs, assert null dest pointer when dest_num is 0 Saeed Mahameed
2022-12-03 22:13 ` [net-next 03/15] net/mlx5e: TC, reuse flow attribute post parser processing Saeed Mahameed
2022-12-03 22:13 ` [net-next 04/15] net/mlx5e: TC, add terminating actions Saeed Mahameed
2022-12-03 22:13 ` [net-next 05/15] net/mlx5e: TC, validate action list per attribute Saeed Mahameed
2022-12-03 22:13 ` [net-next 06/15] net/mlx5e: TC, set control params for branching actions Saeed Mahameed
2022-12-03 22:13 ` [net-next 07/15] net/mlx5e: TC, initialize branch flow attributes Saeed Mahameed
2022-12-03 22:13 ` [net-next 08/15] net/mlx5e: TC, initialize branching action with target attr Saeed Mahameed
2022-12-03 22:13 ` [net-next 09/15] net/mlx5e: TC, rename post_meter actions Saeed Mahameed
2022-12-03 22:13 ` [net-next 10/15] net/mlx5e: TC, init post meter rules with branching attributes Saeed Mahameed
2022-12-03 22:13 ` [net-next 11/15] net/mlx5e: TC, allow meter jump control action Saeed Mahameed
2022-12-03 22:13 ` [net-next 12/15] net/mlx5: SRIOV, Remove two unused ingress flow group Saeed Mahameed
2022-12-03 22:13 ` [net-next 13/15] net/mlx5: SRIOV, Recreate egress ACL table on config change Saeed Mahameed
2022-12-03 22:13 ` [net-next 14/15] net/mlx5: SRIOV, Add 802.1ad VST support Saeed Mahameed
2022-12-07 4:34 ` Jakub Kicinski
2022-12-07 5:20 ` Saeed Mahameed
2022-12-07 17:25 ` Jakub Kicinski [this message]
2022-12-08 8:28 ` Saeed Mahameed
2022-12-09 1:04 ` Jakub Kicinski
2022-12-09 1:57 ` Saeed Mahameed
2022-12-09 2:04 ` Jakub Kicinski
2022-12-09 5:05 ` Saeed Mahameed
2022-12-09 16:34 ` Jakub Kicinski
2022-12-03 22:13 ` [net-next 15/15] net/mlx5: SRIOV, Allow ingress tagged packets on VST 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=20221207092517.3320f4b4@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=mbloch@nvidia.com \
--cc=moshe@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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).