[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR0501MB227107AFB91FB04ABEB397A0D1720@VI1PR0501MB2271.eurprd05.prod.outlook.com>
Date: Tue, 5 Mar 2019 19:59:57 +0000
From: Parav Pandit <parav@...lanox.com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>,
Jiri Pirko <jiri@...nulli.us>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"oss-drivers@...ronome.com" <oss-drivers@...ronome.com>
Subject: RE: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI
ports
> -----Original Message-----
> From: netdev-owner@...r.kernel.org <netdev-owner@...r.kernel.org> On
> Behalf Of Jakub Kicinski
> Sent: Tuesday, March 5, 2019 11:16 AM
> 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 Tue, 5 Mar 2019 12:06:01 +0100, Jiri Pirko wrote:
> > >> >as ports. Can we invent a new command (say "partition"?) that'd take
> > >> >the bus info where the partition is to be spawned?
> > >>
> > >> Got it. But the question is how different this object would be from
> > >> the existing "port" we have today.
> > >
> > >They'd be where "the other side of a PCI link" is represented,
> > >restricting ports to only ASIC's forwarding plane ports.
> >
> > Basically a "host port", right? It can still be the same port object,
> > only with different flavour and attributes. So we would have:
> >
> > 1) pci/0000:05:00.0/0: type eth netdev enp5s0np0
> > flavour physical switch_id 00154d130d2f
> > 2) pci/0000:05:00.0/10000: type eth netdev enp5s0npf0s0
> > flavour pci_pf pf 0 subport 0
> > switch_id 00154d130d2f
> > peer pci/0000:05:00.0/1
> > 3) pci/0000:05:00.0/10001: type eth netdev enp5s0npf0vf0
> > flavour pci_vf pf 0 vf 0
> > switch_id 00154d130d2f
> > peer pci/0000:05:10.1/0
> > 4) pci/0000:05:00.0/10001: type eth netdev enp5s0npf0s1
> > flavour pci_pf pf 0 subport 1
> > switch_id 00154d130d2f
> > peer pci/0000:05:00.0/2
> > 5) pci/0000:05:00.0/1: type eth netdev enp5s0f0??
> > flavour host <----------------
> > peer pci/0000:05:00.0/10000
> > 6) pci/0000:05:10.1/0: type eth netdev enp5s10f0
> > flavour host <----------------
> > peer pci/0000:05:00.0/10001
> > 7) pci/0000:05:00.0/2: type eth netdev enp5s0f0??
> > flavour host <----------------
> > peer pci/0000:05:00.0/10001
> >
> > I think it looks quite clear, it gives complete topology view.
>
> Okay, I have some of questions :)
>
> What do we use for port_index?
>
port_index to refer a port for port attribute query/config.
> What are the operations one can perform on "host ports"?
>
Set port parameters.
I see use case for mac address, rdma port guid, port speed that should be emulated.
> If we have PCI parameters, do they get set on the ASIC side of the port or the
> host side of the port?
>
Hostport has host facing parameters.
Eswitch port has switch facing parameters (configured/queried/managed through netdev/ovs).
> How do those behave when device is passed to VM?
>
> You have a VF devlink instance there - what ports does it show?
>
VF devlink port in VM will show the port it got.
It will likely have only read permission for the port attributes as today.
For example, it will not know which switchport it is connected to.
> How do those look when the PF is connected to another host? Do they get
> spawned at all?
>
> Will this not be confusing to DSA folks who have a CPU port?
Powered by blists - more mailing lists