Date:   Mon, 29 Oct 2018 10:02:54 +0530
From:   Sunil Kovvuri <sunil.kovvuri@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        linux-soc@...r.kernel.org, Sunil Goutham <sgoutham@...vell.com>
Subject: Re: [PATCH v2 00/17] octeontx2-af: NPC parser and NIX blocks initialization

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

Powered by blists - more mailing lists