[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e7cdeea9-0ee4-7d08-f13b-e8afe13095a7@intel.com>
Date: Fri, 28 Apr 2023 17:52:53 -0500
From: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To: Shannon Nelson <shannon.nelson@....com>, <brett.creeley@....com>,
<netdev@...r.kernel.org>
CC: <drivers@...sando.io>
Subject: Re: [PATCH RFC net-next 0/2] pds_core: add switchdev and tc for vlan
offload
On 4/27/2023 11:45 AM, 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.
>
> 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.
>
> I welcome your comments and suggestions.
Adding a tc rule doesn't seem to be the right interface to
configure port-vlan for all packets sent/received on a port.
tc would be appropriate if we want to do push/pop vlan on certain flows.
bridge vlan add dev $VF_REP vid 200 pvid untagged master
would be a better option. This may require adding vf reps to a bridge
and enable vlan_filtering on the bridge. The driver needs to register
for SWITCHDEV_PORT_OBJ_ADD events.
Extending devlink port function to support port-vlan similar to setting
a mac address also looks like a good option without the requirement of
having to add port reps to a bridge.
>
> Thanks,
> sln
>
> [0]: https://lore.kernel.org/netdev/20221118225656.48309-1-snelson@pensando.io/
>
> Shannon Nelson (2):
> pds_core: netdev representors for each VF
> pds_core: tc command handling for vlan push-pop
>
> drivers/net/ethernet/amd/pds_core/Makefile | 1 +
> drivers/net/ethernet/amd/pds_core/core.h | 12 +
> drivers/net/ethernet/amd/pds_core/main.c | 28 +-
> drivers/net/ethernet/amd/pds_core/rep.c | 322 +++++++++++++++++++++
> 4 files changed, 361 insertions(+), 2 deletions(-)
> create mode 100644 drivers/net/ethernet/amd/pds_core/rep.c
>
Powered by blists - more mailing lists