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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 26 Oct 2018 21:28:57 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Sunil Kovvuri <sunil.kovvuri@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Networking <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 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.

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