netdev - RE: [PATCH net-next 6/8] devlink: introduce port's peer netdevs

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 05:07:57 +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 6/8] devlink: introduce port's peer netdevs



> -----Original Message-----
> From: netdev-owner@...r.kernel.org <netdev-owner@...r.kernel.org> On
> Behalf Of Jiri Pirko
> Sent: Wednesday, February 27, 2019 7:08 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 6/8] devlink: introduce port's peer netdevs
> 
> Tue, Feb 26, 2019 at 07:24:34PM CET, jakub.kicinski@...ronome.com wrote:
> >Devlink ports represent ports of a switch device (or SR-IOV NIC which
> >has an embedded switch).
Need not be.
As you know,
In switchdev mode, there are two ports. hostport and switchport.
Switch port represented by representor netdevice and services ingress traffic from hostport.

hostport is connected to NIC txq, rxq and rdma queues.

Each should be managed/configured separately.


>  In case of SR-IOV when PCIe PFs are exposed
> >the PFs which are directly connected to the local machine may also
> >spawn PF netdev (much like VFs have a port/"repr" and an actual VF
> >netdev).
> >
> >Allow devlink to expose such linking. There is currently no way to find
> >out which netdev corresponds to which PF.
> >
> >Example:
> >
> >$ devlink port
> >pci/0000:82:00.0/0: type eth netdev p4p1 flavour physical
> >pci/0000:82:00.0/10000: type eth netdev eth1 flavour pci_pf pf 0
> >peer_netdev enp130s0
> >pci/0000:82:00.0/10001: type eth netdev eth0 flavour pci_vf pf 0 vf 0
> >pci/0000:82:00.0/10002: type eth netdev eth2 flavour pci_vf pf 0 vf 1
> 
> Peer as the other side of a "virtual cable". For PF, that is probably sufficient.
> But I think what a "peer of devlink port" should be "a devlink port".
> 
> Not sure about VF.
> 
> Consider a simple problem of setting up a VF mac address. In legacy, you do
> it like this:
> $ ip link set eth2 vf 1 mac 00:52:44:11:22:33 However, in new model, you so
> far cannot do that.
> 
> What I was thinking about was some "dummy peer" which would be on the
> host. Not sure if only as a "dummy peer devlink port" or even as some sort
> of "dummy netdev".
>
I think we shouldn't bring up this convoluted concept of dummy/peer netdev.
A simpler scheme is to represent and configure what port does.
Rep-netdev is well defined switchport.
hostport should be used to configured hostport configurations using devlink.
netdev object for hostport config is probably too heavy and we should just continue with hostport.