Re: [PATCH v2 00/17] octeontx2-af: NPC parser and NIX blocks initialization

On Sat, Oct 27, 2018 at 12:59 AM Arnd Bergmann [off-list ref] wrote:

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

quoted

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.

Yes, except for minor changes i don't think base mechanism will change.

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.

Agreed.

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?

This part is still under discussion, will get back on this.
Currently we are looking at a way for a administrator to limit the amount of
resources that can be attached / allocated to a virtual function.
Allowing administrator
to limit data transfer or to give priorities etc is complex, we will
look into that stuff
later on.

Thanks,
Sunil.