On Sat, Oct 27, 2018 at 12:59 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Fri, Oct 26, 2018 at 6:33 PM Sunil Kovvuri <sunil.kovvuri@xxxxxxxxx> wrote: > > On Fri, Oct 26, 2018 at 9:56 PM Sunil Kovvuri <sunil.kovvuri@xxxxxxxxx> wrote: > > > On Fri, Oct 26, 2018 at 7:34 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > > On 10/26/18, Sunil Kovvuri <sunil.kovvuri@xxxxxxxxx> wrote: > > > > > On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann <arnd@xxxxxxxx> 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.
