netdev - Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports

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]

Message-ID: <20190311191054.36b801d6@cakuba.hsd1.ca.comcast.net>
Date:   Mon, 11 Mar 2019 19:10:54 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        oss-drivers@...ronome.com
Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI
 ports

On Mon, 11 Mar 2019 09:52:04 +0100, Jiri Pirko wrote:
> Fri, Mar 08, 2019 at 08:09:43PM CET, jakub.kicinski@...ronome.com wrote:
> >If the switchport is in the hypervisor then only the hypervisor can
> >control switching/forwarding, correct?  
> 
> Correct.
> 
> >The primary use case for partitioning within a VM (of a VF) would be
> >containers (and DPDK)?  
> 
> Makes sense.
> 
> >SR-IOV makes things harder.  Splitting a PF is reasonably easy to grasp.
> >I'm trying to get a sense of is how would we control an SR-IOV
> >environment as a whole.  
> 
> You mean orchestration? 

Right, orchestration.

To be clear on where I'm going with this - if we want to allow VFs 
to partition themselves then they have to control what is effectively 
a "nested" switch.  A per-VF set of rules which would the get
"flattened" into the main eswitch rule set.  If I was to choose I'd
really rather have this "flattening" be done on the (Linux) hypervisor
and not in the vendor driver and firmware.

I'd much rather have the VM make a "give me another NIC" orchestration
call via some high level REST API than devlink.  This makes the
configuration strictly high level to low level:

  VM -> cloud net REST API -> cloud agent -> devlink/Linux -> FW -> HW

Without round trips via firmware.  

This allows for easy policy enforcement, common code to be maintained
in user space, in high level languages (no 0.5M LoC drivers and 10M LoC
firmware for every driver).  It can also be used with software paths
like VirtIO..

Modelling and debugging a nested switch would be a nightmare.  What
follows is that we probably shouldn't deal with partitioning of VFs,
but rather only partition via the PF devlink instance, and reassign 
the partitions to VMs.

> I originally planned to implement sriov orchestration api in devlink too.

Interesting, would you mind elaborating?