Subject: Re: [PATCH RFC net-next 0/2] pds_core: add switchdev and tc for vlan offload

From: Jakub Kicinski <[email-masked]>
Date: Thu, 4 May 2023 14:14:30 -0700

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.