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:   Mon, 4 Mar 2019 04:59:04 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Jiri Pirko <jiri@...nulli.us>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 2/8] devlink: add PF and VF port flavours



> -----Original Message-----
> From: netdev-owner@...r.kernel.org <netdev-owner@...r.kernel.org> On
> Behalf Of Jiri Pirko
> Sent: Wednesday, February 27, 2019 6:17 AM
> To: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Cc: davem@...emloft.net; oss-drivers@...ronome.com;
> netdev@...r.kernel.org
> Subject: Re: [PATCH net-next 2/8] devlink: add PF and VF port flavours
> 
> Tue, Feb 26, 2019 at 07:24:30PM CET, jakub.kicinski@...ronome.com wrote:
> >Current port flavours cover simple switches and DSA.  Add PF and VF
> >flavours to cover "switchdev" SR-IOV NICs.
> >
> >Example devlink user space output:
> >
> >$ devlink port
> >pci/0000:82:00.0/0: type eth netdev p4p1 flavour physical
> >pci/0000:82:00.0/10000: type eth netdev eth0 flavour pcie_pf pf 0
> >pci/0000:82:00.0/10001: type eth netdev eth1 flavour pcie_vf pf 0 vf 0
> >pci/0000:82:00.0/10002: type eth netdev eth2 flavour pcie_vf pf 0 vf 1
>
A given port is of its parent device.
In current scenario, its PF or VF.
Hence it should be device attribute and not a port attribute.
So devlink dev show command have to show what device flavour is.
Is it well known PCI VF or PF or something else.
It will show subdev device attribute and its parent PCI (PF/VF) devlink device.
So we should have device flovour as PCI_PF or PCI_VF or SUBDEV.

Again VF number showcasing here is very restrictive model.
Every PF/VF/Subdev represents its own 'port' and it is connected to eswitch 'port'.
Instead of showing VF here, it must be this 'port' or 'link' number that gives right view.
Which netdev represents which VF is already linked in the VF rep-netdev sysfs property.

So flavour should be something like 'hostport' and when port is registered for the eswitch side it should be 'switchport'.
With this there is very clear picture of which hostport is connected to which eswitch port.
Just like how we see in the physical world.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ