netdev - Re: [RFC PATCH net-next 08/19] pds_core: initial VF configuration

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: <20221201142951.5f068079@kernel.org>
Date:   Thu, 1 Dec 2022 14:29:51 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Shannon Nelson <shnelson@....com>
Cc:     Shannon Nelson <snelson@...sando.io>, netdev@...r.kernel.org,
        davem@...emloft.net, mst@...hat.com, jasowang@...hat.com,
        virtualization@...ts.linux-foundation.org, drivers@...sando.io
Subject: Re: [RFC PATCH net-next 08/19] pds_core: initial VF configuration

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.