On Fri, Oct 26, 2018 at 6:33 PM Sunil Kovvuri [off-list ref] wrote:

On Fri, Oct 26, 2018 at 9:56 PM Sunil Kovvuri [off-list ref] wrote:

quoted

On Fri, Oct 26, 2018 at 7:34 PM Arnd Bergmann [off-list ref] wrote:

quoted

quoted

On 10/26/18, Sunil Kovvuri [off-list ref] wrote:
On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann [off-list ref] wrote:

As of now it's only mbox based configuration that is supported.

Ok, thanks for the clarification.

Does this mean that you intend to have user space tools that use
the mbox based interface on VFIO devices to perform configuration
for virtual network devices, or just that the configuration interface
is something that needs to be designed later?

No there is no need for any userspace tools.
It's the virtual network device's driver which will send commands
like resource allocation, configuration, stats retrieval to this
AF device via mbox interface.

eg: A user using ethtool changes RSS settings for the network device,
network device's driver receives the data, prepares a mailbox command
sends it to this driver for configuring the same in HW.

Ok, that part is mostly fine, as within a given host you can just have
multiple network interfaces that you can each configure independently,
and the mailbox interface for the most part is an implementation detail.

Doing the same in virtual machines means that the mailbox interface
becomes an ABI between the driver in the guest and the driver in the
host. This is still not too bad, in the worst case the guest might have
to detect the version of the host that's running and support both
an old and new version of the interface. There is reasonable hope
that you don't need to revise the interface here; it's not much different
from talking to firmware, and having both sides of the interface under
the control of Linux may in fact be better.

Once the interface gets exposed to stuff like ODP or DPDK, it effectively
becomes a user space interface, and that carries risk of being abused
for passing lots of other stuff, so this is the point where we have to be
very careful.

Aside from this, there is the stuff that Andrew mentioned, which is the
most important: For anything that should /not/ be controlled by a
network interface for itself, you still need an administrative interface.
An example of this would be creating additional virtual functions,
assigning bandwidth allocation between them, or limiting the
data that can be transferred to and from a virtual function.

Can you explain what your plan is to handle those?

To be more clear there is no mbox 'interface' as such.
Here PCI devices shares a memory region, one device prepares a command
in this shared memory and writes into a doorbell kind of register which triggers
an IRQ to other device. Which then takes the command processes it.

Yes, this part was already clear to me.

       Arnd