From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sunil Kovvuri Subject: Re: [PATCH v2 00/17] octeontx2-af: NPC parser and NIX blocks initialization Date: Mon, 29 Oct 2018 10:02:54 +0530 Message-ID: References: <1540230964-5506-1-git-send-email-sunil.kovvuri@gmail.com> <20181022.201943.53165079906230990.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: "David S. Miller" , Linux Netdev List , linux-soc@vger.kernel.org, Sunil Goutham To: Arnd Bergmann Return-path: Received: from mail-wm1-f47.google.com ([209.85.128.47]:52549 "EHLO mail-wm1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729350AbeJ2NUG (ORCPT ); Mon, 29 Oct 2018 09:20:06 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Sat, Oct 27, 2018 at 12:59 AM Arnd Bergmann wrote: > > On Fri, Oct 26, 2018 at 6:33 PM Sunil Kovvuri wrote: > > On Fri, Oct 26, 2018 at 9:56 PM Sunil Kovvuri wrote: > > > On Fri, Oct 26, 2018 at 7:34 PM Arnd Bergmann wrote: > > > > > On 10/26/18, Sunil Kovvuri wrote: > > > > > On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann 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.