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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230504141430.5eafa505@kernel.org>
Date: Thu, 4 May 2023 14:14:30 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Shannon Nelson <shannon.nelson@....com>
Cc: brett.creeley@....com, netdev@...r.kernel.org, drivers@...sando.io
Subject: Re: [PATCH RFC net-next 0/2] pds_core: add switchdev and tc for
 vlan offload

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.