From: Shannon Nelson <shnelson@amd•com>
To: Jakub Kicinski <kuba@kernel•org>
Cc: Shannon Nelson <snelson@pensando•io>,
netdev@vger•kernel.org, davem@davemloft•net, mst@redhat•com,
jasowang@redhat•com, virtualization@lists•linux-foundation.org,
drivers@pensando•io
Subject: Re: [RFC PATCH net-next 08/19] pds_core: initial VF configuration
Date: Mon, 28 Nov 2022 17:08:28 -0800 [thread overview]
Message-ID: <51330a32-1fa1-cc0f-e06e-b4ac351cb820@amd.com> (raw)
In-Reply-To: <20221128165522.62dcd7be@kernel.org>
On 11/28/22 4:55 PM, Jakub Kicinski wrote:
> On Mon, 28 Nov 2022 16:37:45 -0800 Shannon Nelson wrote:
>>> If this is a "SmartNIC" there should be alternative solution based on
>>> representors for each of those callbacks, and the device should support
>>> forwarding using proper netdev constructs like bridge, routing, or tc.
>>>
>>> This has been our high level guidance for a few years now. It's quite
>>> hard to move the ball forward since all major vendors have a single
>>> driver for multiple generations of HW :(
>>
>> Absolutely, if the device presented to the host is a SmartNIC and has
>> these bridge and router capabilities, by all means it should use the
>> newer APIs, but that's not the case here.
>>
>> In this case we are making devices available to baremetal platforms in a
>> cloud vendor setting where the majority of the network configuration is
>> controlled outside of the host machine's purview. There is no bridging,
>> routing, or filtering control available to the baremetal client other
>> than the basic VF configurations.
>
> Don't even start with the "our device is simple and only needs
> the legacy API" line of arguing :/
I'm not sure what else to say here - yes, we have a fancy and complex
piece of hardware plugged into the PCI slot, but the device that shows
up on the PCI bus is a very constrained model that doesn't know anything
about switchdev kinds of things.
>
>> The device model presented to the host is a simple PF with VFs, not a
>> SmartNIC, thus the pds_core driver sets up a simple PF netdev
>> "representor" for using the existing VF control API: easy to use,
>> everyone knows how to use it, keeps code simple.
>>
>> I suppose we could have the PF create a representor netdev for each
>> individual VF to set mac address and read stats, but that seems
>
> Oh, so the "representor" you mention in the cover letter is for the PF?
Yes, a PF representor simply so we can get access to the .ndo_set_vf_xxx
interfaces. There is no network traffic running through the PF.
sln
next prev parent reply other threads:[~2022-11-29 1:08 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 22:56 [RFC PATCH net-next 00/19] pds core and vdpa drivers Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 01/19] pds_core: initial framework for pds_core driver Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 02/19] pds_core: add devcmd device interfaces Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 03/19] pds_core: health timer and workqueue Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 04/19] pds_core: set up device and adminq Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 05/19] pds_core: Add adminq processing and commands Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 06/19] pds_core: add FW update feature to devlink Shannon Nelson
2022-11-28 18:27 ` Jakub Kicinski
2022-11-28 22:25 ` Shannon Nelson
2022-11-28 23:33 ` Jakub Kicinski
2022-11-28 23:45 ` Shannon Nelson
2022-11-29 0:18 ` Keller, Jacob E
2022-11-29 0:13 ` Keller, Jacob E
2022-11-18 22:56 ` [RFC PATCH net-next 07/19] pds_core: set up the VIF definitions and defaults Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 08/19] pds_core: initial VF configuration Shannon Nelson
2022-11-28 18:28 ` Jakub Kicinski
2022-11-28 22:25 ` Shannon Nelson
2022-11-28 23:37 ` Jakub Kicinski
2022-11-29 0:37 ` Shannon Nelson
2022-11-29 0:55 ` Jakub Kicinski
2022-11-29 1:08 ` Shannon Nelson [this message]
2022-11-29 1:54 ` Jakub Kicinski
2022-11-29 17:57 ` Shannon Nelson
2022-11-30 2:02 ` Jakub Kicinski
2022-12-01 0:12 ` Shannon Nelson
2022-12-01 3:45 ` Jakub Kicinski
2022-12-01 19:19 ` Shannon Nelson
2022-12-01 22:29 ` Jakub Kicinski
2022-11-18 22:56 ` [RFC PATCH net-next 09/19] pds_core: add auxiliary_bus devices Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 10/19] pds_core: devlink params for enabling VIF support Shannon Nelson
2022-11-28 18:29 ` Jakub Kicinski
2022-11-28 22:26 ` Shannon Nelson
2022-11-28 22:57 ` Andrew Lunn
2022-11-28 23:07 ` Shannon Nelson
2022-11-28 23:29 ` Andrew Lunn
2022-11-28 23:39 ` Jakub Kicinski
2022-11-29 9:00 ` Leon Romanovsky
2022-11-29 9:13 ` Jiri Pirko
2022-11-29 17:16 ` Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 11/19] pds_core: add the aux client API Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 12/19] pds_core: publish events to the clients Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 13/19] pds_core: Kconfig and pds_core.rst Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 14/19] pds_vdpa: Add new PCI VF device for PDS vDPA services Shannon Nelson
2022-11-22 3:53 ` Jason Wang
2022-11-29 22:24 ` Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 15/19] pds_vdpa: virtio bar setup for vdpa Shannon Nelson
2022-11-22 3:32 ` Jason Wang
2022-11-22 6:36 ` Jason Wang
2022-11-29 23:02 ` Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 16/19] pds_vdpa: add auxiliary driver Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 17/19] pds_vdpa: add vdpa config client commands Shannon Nelson
2022-11-22 6:32 ` Jason Wang
2022-11-29 23:16 ` Shannon Nelson
2022-11-18 22:56 ` [RFC PATCH net-next 18/19] pds_vdpa: add support for vdpa and vdpamgmt interfaces Shannon Nelson
2022-11-22 6:32 ` Jason Wang
2022-11-30 0:11 ` Shannon Nelson
2022-12-05 7:40 ` Jason Wang
2022-11-18 22:56 ` [RFC PATCH net-next 19/19] pds_vdpa: add Kconfig entry and pds_vdpa.rst Shannon Nelson
2022-11-22 6:35 ` Jason Wang
2022-11-22 22:33 ` Shannon Nelson
2022-11-30 0:13 ` Shannon Nelson
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=51330a32-1fa1-cc0f-e06e-b4ac351cb820@amd.com \
--to=shnelson@amd$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=drivers@pensando$(echo .)io \
--cc=jasowang@redhat$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=mst@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=snelson@pensando$(echo .)io \
--cc=virtualization@lists$(echo .)linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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