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: <20230502164336.1e8974af@kernel.org>
Date: Tue, 2 May 2023 16:43:36 -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, 27 Apr 2023 09:45:44 -0700 Shannon Nelson wrote:
> This is an RFC for adding to the pds_core driver some very simple support
> for VF representors and a tc command for offloading VF port vlans.
> 
> The problem to solve is how to request that a NIC do the push/pop of port
> vlans on a VF.  The initial pds_core patchset[0] included this support
> through the legacy ip-link methods with a PF netdev that had no datapath,
> simply existing to enable commands such as
>     ip link set <pf> vf <vfid> vlan <vid>
> This was soundly squashed with a request to create proper VF representors.
> The pds_core driver has since been reworked and merged without this feature.

Have you read the representors documentation? Passing traffic is
crucial.

> This pair of patches is a first attempt at adding support for a simple
> VF representor and tc offload which I've been tinkering with off and
> on over the last few weeks.  I will acknowledge that we have no proper
> filtering offload language in our firmware's adminq interface yet.
> This has been mentioned internally and is a "future project" with no
> actual schedule yet.  Given that, I have worked here with what I have,
> using the existing vf_setattr function.
> 
> An alternative that later occured to me is to make this a "devlink port
> function" thing, similar to the existing port mac.  This would have the
> benefit of using a familiar concept from and similar single command as
> the legacy method, would allow early port setup as with setting the mac
> and other port features, and would not need to create a lot of mostly
> empty netdevs for the VF representors.  I don't know if this would then
> lead to adding "trust" and "spoofcheck" as well, but I'm not aware of any
> other solutions for them, either.  This also might make more sense for
> devices that don't end up as user network interfaces, such as a virtio
> block device that runs over ethernet on the back end.  I don't have RFC
> code for this idea, but thought I would toss it out for discussion -
> I didn't see any previous related discussion in a (rather quick) search.

No, no -- the problem is not rtnetlink vs devlink but the fact 
that the old API was inventing its own parallel way of configuring
forwarding outside of normal/SW netdev concepts.