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: <20220728122745.4cf0f860@kernel.org>
Date:   Thu, 28 Jul 2022 12:27:45 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Edward Cree <ecree.xilinx@...il.com>
Cc:     ecree@...inx.com, davem@...emloft.net, pabeni@...hat.com,
        linux-net-drivers@....com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 12/14] sfc: set EF100 VF MAC address through
 representor

On Thu, 28 Jul 2022 19:54:21 +0100 Edward Cree wrote:
> On 28/07/2022 19:32, Jakub Kicinski wrote:
> > How do you map reprs to VFs? The PCI devices of the VF may be on 
> > a different system.  
> That's what the client ID from patch #10 is for.  We ask the FW for
>  a handle to "caller's PCIe controller → caller's PF → VF number
>  efv->idx", and that handle is what we store in efv->clid, and later
>  pass to MC_CMD_SET_CLIENT_MAC_ADDRESSES in patch #12.
> 
> The user determines which repr corresponds to which VF by looking in
>  /sys/class/net/$VFREP/phys_port_name (e.g. "p0pf0vf0").

.. and that would also most likely be what the devlink port ID would be.

> > But reps are like switch ports in a switch ASIC, and the PCI
> > device is the other side of the virtual wire. You would not be
> > configuring the MAC address of a peer to peer link by setting 
> > the local address.  
> Indeed.  I agree that .ndo_set_mac_address() is the wrong interface.
> But the interface I have in mind would be something like
>     int (*ndo_set_partner_mac_address)(struct net_device *, void *);
>  and would only be implemented by representor netdevs.
> Idk what the uAPI/UI for that would be; probably a new `ip link set`
>  parameter.

Yup... If only you were there during the fight over this uAPI.
Now it's the devlink "port function" thing.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ