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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ad5bf0ee-9d93-e0c0-cb22-7b572b75d6a2@amd.com>
Date: Thu, 4 May 2023 13:51:13 -0700
From: Shannon Nelson <shannon.nelson@....com>
To: Jakub Kicinski <kuba@...nel.org>
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 5/3/23 6:27 PM, Jakub Kicinski wrote:
> 
> On Wed, 3 May 2023 15:49:27 -0700 Shannon Nelson wrote:
>> Given that there is no traffic to the host PF in this case, and I can't
>> do anything more than wave my hands at vague promises for the future,
>> perhaps tc and representors is the wrong path for now.
> 
> If it's not a priority for AMD to have an upstream implementation
> that's fine. There's not point over-complicating the discussion.
> 
>> But there remains a need for some port related configuration.  I can
>> take a stab at adding this concept to "devlink port function" and see
>> what discussion follows from there.
> 
> 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.  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?

Thanks,
sln