From: Shannon Nelson <shannon.nelson@amd.com>
To: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
brett.creeley@amd.com, netdev@vger.kernel.org
Cc: drivers@pensando.io
Subject: Re: [PATCH RFC net-next 0/2] pds_core: add switchdev and tc for vlan offload
Date: Tue, 2 May 2023 13:59:39 -0700 [thread overview]
Message-ID: <ad1d28c2-766a-5249-af36-cdaa6ea9f69f@amd.com> (raw)
In-Reply-To: <e7cdeea9-0ee4-7d08-f13b-e8afe13095a7@intel.com>
On 4/28/23 3:52 PM, Samudrala, Sridhar wrote:
>
> 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.
This is something that had occurred to me. The tc commands seem to be
aimed at a finer grain control than what I need for this case.
>
> 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.
I thought about this as well, but this also seems to be abusing the
model when there are no data streams and no representor for the PF.
>
> 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.
I'm hoping that others will chime in on this idea. Meanwhile, I'll see
if I can work up an RFC for this thought later this week.
sln
>
>>
>> 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
>>
next prev parent reply other threads:[~2023-05-02 20:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 16:45 [PATCH RFC net-next 0/2] pds_core: add switchdev and tc for vlan offload Shannon Nelson
2023-04-27 16:45 ` [PATCH RFC net-next 1/2] pds_core: netdev representors for each VF Shannon Nelson
2023-04-27 16:45 ` [PATCH RFC net-next 2/2] pds_core: tc command handling for vlan push-pop Shannon Nelson
2023-04-28 22:52 ` [PATCH RFC net-next 0/2] pds_core: add switchdev and tc for vlan offload Samudrala, Sridhar
2023-05-02 20:59 ` Shannon Nelson [this message]
2023-05-02 23:43 ` Jakub Kicinski
2023-05-03 22:49 ` Shannon Nelson
2023-05-04 1:27 ` Jakub Kicinski
2023-05-04 20:51 ` Shannon Nelson
2023-05-04 21:14 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ad1d28c2-766a-5249-af36-cdaa6ea9f69f@amd.com \
--to=shannon.nelson@amd.com \
--cc=brett.creeley@amd.com \
--cc=drivers@pensando.io \
--cc=netdev@vger.kernel.org \
--cc=sridhar.samudrala@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).