From: Jakub Kicinski <kuba@kernel.org>
To: Shannon Nelson <shannon.nelson@amd.com>
Cc: brett.creeley@amd.com, netdev@vger.kernel.org, drivers@pensando.io
Subject: Re: [PATCH RFC net-next 0/2] pds_core: add switchdev and tc for vlan offload
Date: Thu, 4 May 2023 14:14:30 -0700 [thread overview]
Message-ID: <20230504141430.5eafa505@kernel.org> (raw)
In-Reply-To: <ad5bf0ee-9d93-e0c0-cb22-7b572b75d6a2@amd.com>
On Thu, 4 May 2023 13:51:13 -0700 Shannon Nelson wrote:
> On 5/3/23 6:27 PM, Jakub Kicinski wrote:
> > You mean setting vlan encap via devlink?
> > I don't know why you'd do that. It will certainly aggravate me,
> > and I doubt anyone will care/support you.
>
> We're trying to solve what would seem to be a simple problem for our
> customer: how to do basic vlan encap/decap on all traffic going in and
> of a VF.
Offload bridge.
If your customer doesn't want the bridge offload you can decide
to ship an out of tree driver for them with whatever deprecated
APIs you please.
> With no host PF traffic, the legacy ip-link and the newer
> switchdev+tc solutions don't fit. As this is VF port setup, and devlink
> is meant for device setup, it would seem to fit in the devlink port
> function model similar to the setting of the port hw_addr. What am I
> missing that makes this an unacceptable answer?
>
> I understand you don't like this devlink port function suggestion, but
> when I go back to negotiate with internal management, architects, etc, I
> can get a lot further with them if I have a technical explanation of why
> this is not acceptable. So, at the risk of further aggravating you, can
> I request a little more detail on why this is a bad idea?
The direction of the community was to use offload of standard networking
concepts like switching, routing and flow matching for probably a decade
now.
prev parent reply other threads:[~2023-05-04 21:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 16:45 [PATCH RFC net-next 0/2] pds_core: add switchdev and tc for vlan offload Shannon Nelson
2023-04-27 16:45 ` [PATCH RFC net-next 1/2] pds_core: netdev representors for each VF Shannon Nelson
2023-04-27 16:45 ` [PATCH RFC net-next 2/2] pds_core: tc command handling for vlan push-pop Shannon Nelson
2023-04-28 22:52 ` [PATCH RFC net-next 0/2] pds_core: add switchdev and tc for vlan offload Samudrala, Sridhar
2023-05-02 20:59 ` Shannon Nelson
2023-05-02 23:43 ` Jakub Kicinski
2023-05-03 22:49 ` Shannon Nelson
2023-05-04 1:27 ` Jakub Kicinski
2023-05-04 20:51 ` Shannon Nelson
2023-05-04 21:14 ` Jakub Kicinski [this message]
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=20230504141430.5eafa505@kernel.org \
--to=kuba@kernel.org \
--cc=brett.creeley@amd.com \
--cc=drivers@pensando.io \
--cc=netdev@vger.kernel.org \
--cc=shannon.nelson@amd.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.