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

From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: davem@davemloft.net, netdev@vger.kernel.org, oss-drivers@netronome.com
Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports
Date: Wed, 13 Mar 2019 09:55:55 -0700	[thread overview]
Message-ID: <20190313095555.0f4f92ca@cakuba.attlocal.net> (raw)
In-Reply-To: <20190313162243.GB2270@nanopsycho>

On Wed, 13 Mar 2019 17:22:43 +0100, Jiri Pirko wrote:
> Wed, Mar 13, 2019 at 05:17:31PM CET, jakub.kicinski@netronome.com wrote:
> >On Wed, 13 Mar 2019 07:07:01 +0100, Jiri Pirko wrote:  
> >> Tue, Mar 12, 2019 at 09:56:28PM CET, jakub.kicinski@netronome.com wrote:  
> >> >On Tue, 12 Mar 2019 15:02:39 +0100, Jiri Pirko wrote:    
> >> >> Tue, Mar 12, 2019 at 03:10:54AM CET, wrote:    
> >> >> >On Mon, 11 Mar 2019 09:52:04 +0100, Jiri Pirko wrote:      
> >> >> >> Fri, Mar 08, 2019 at 08:09:43PM CET, 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      
> >> >> 
> >> >> Wait. If you allow to make VF subports (I believe that is what you ment
> >> >> by VFs partition themselves), that does not mean they will have a
> >> >> separate nested switch. They would still belong under the same one.    
> >> >
> >> >But that existing switch is administered by the hypervisor, how would
> >> >the VF owners install forwarding rules in a switch they don't control?    
> >> 
> >> They won't.  
> >
> >Argh.  So how is forwarding configured if there are no rules?  Are you
> >going to assume its switching on MACs?  We're supposed to offload
> >software constructs.  If its a software port it needs to be explicitly
> >switched.  If it's not explicitly switched - we already have macvlan
> >offload.  
> 
> Wait a second. You configure the switch. And for that, you have the
> switchports (representors). What we are talking about are VF (VF
> subport) host legs. Am I missing something?

Hm :)  So when VM gets a new port, how is it connected?  Are we
assuming all ports of a VM are plugged into one big L2 switch?
The use case for those sub ports is a little murky, sorry about
the endless confusion :)