From: Jakub Kicinski <kuba@kernel.org>
To: Shannon Nelson <shnelson@amd.com>
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: Thu, 1 Dec 2022 14:29:51 -0800 [thread overview]
Message-ID: <20221201142951.5f068079@kernel.org> (raw)
In-Reply-To: <6a174081-0187-551c-4b34-17a59ad38230@amd.com>
On Thu, 1 Dec 2022 11:19:51 -0800 Shannon Nelson wrote:
> > It simply does not compute for me. You're exposing a very advanced vDPA
> > interface, and yet you say you don't need any network configuration
> > beyond what Niantic had.
>
> Would you have the same responses if we were trying to do this same kind
> of PF netdev on a simple Niantic-like device (simple sr-iov support,
> little filtering capability)?
It is really hard for me to imagine someone building a Niantic-like
device today.
Recently I was thought-experiment-designing simplest Niantic-like device
for container workloads. And my conclusion was that yes, TC would
probably be the best way to control forwarding. (Sorry not really an
answer to your question, I don't know of any real Niantics of the day)
> > There are no upstream-minded users of IPUs, if it was up to me I'd flat
> > out ban them from the kernel.
>
> Yeah, there's a lot of hidden magic going on behind the PCI devices
> presented to the host, and a lot of it depends on the use cases
> attempting to be addressed by the different product vendors and their
> various cloud and enterprise customers. I tend to think that the most
> friction here comes from us being more familiar and comfortable with the
> enterprise use cases where we typically own the whole host, and not so
> comfortable these newer cloud use cases with control and configuration
> coming from outside the host.
I know about cloud as much as I know about enterprise, being a Meta's
employee. But those who do have public clouds seem to develop all the
meaningful tech behind closed doors, under NDAs. And at best "bless"
us with a code dump which is under an open source license.
The community is where various developers should come together and
design together. If you do a full design internally and then come
upstream to just ship the code then it's a SW distribution channel,
not an open source project. That's what I am not comfortable with.
next prev parent reply other threads:[~2022-12-01 22:29 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
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 [this message]
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=20221201142951.5f068079@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=drivers@pensando.io \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=shnelson@amd.com \
--cc=snelson@pensando.io \
--cc=virtualization@lists.linux-foundation.org \
/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).