On Thu, 1 Dec 2022 11:19:51 -0800 Shannon Nelson wrote:

quoted

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)

quoted

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.