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: <20190607142717.3ee89f12@cakuba.netronome.com>
Date:   Fri, 7 Jun 2019 14:27:17 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     "Bshara, Nafea" <nafea@...zon.com>,
        David Woodhouse <dwmw2@...radead.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "Jubran, Samih" <sameehj@...zon.com>, Andrew Lunn <andrew@...n.ch>,
        "Kiyanovski, Arthur" <akiyano@...zon.com>,
        "Bshara, Saeed" <saeedb@...zon.com>,
        "Tzalik, Guy" <gtzalik@...zon.com>,
        "Matushevsky, Alexander" <matua@...zon.com>,
        "Liguori, Anthony" <aliguori@...zon.com>,
        "Saidi, Ali" <alisaidi@...zon.com>,
        "Machulsky, Zorik" <zorik@...zon.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Wilson, Matt" <msw@...zon.com>,
        "Belgazal, Netanel" <netanel@...zon.com>,
        "Herrenschmidt, Benjamin" <benh@...zon.com>
Subject: Re: [PATCH V2 net 00/11] Extending the ena driver to support new
 features and enhance performance

On Thu, 6 Jun 2019 18:14:16 -0700, Jakub Kicinski wrote:
> On Fri, 7 Jun 2019 01:04:14 +0000, Bshara, Nafea wrote:
> > On Jun 6, 2019, at 4:43 PM, Jakub Kicinski wrote:  
> > >>> Okay, then you know which one is which.  Are there multiple ENAs but
> > >>> one EFA?  
> > >> 
> > >> Yes,  very possible. Very common
> > >> 
> > >> Typical use case that instances have one ena for control plane, one
> > >> for internet facing , and one 100G ena that also have efa capabilities  
> > > 
> > > I see, and those are PCI devices..  Some form of platform data would
> > > seem like the best fit to me.  There is something called:
> > > 
> > > /sys/bus/pci/${dbdf}/label
> > > 
> > > It seems to come from some ACPI table - DSM maybe?  I think you can put
> > > whatever string you want there 🤔    
> > 
> > Acpi path won’t work, much of thee interface are hot attached, using
> > native pcie hot plug and acpi won’t be involved.   
> 
> Perhaps hotplug break DSM, I won't pretend to be an ACPI expert.  So you
> can find a way to stuff the label into that file from another source.
> There's also VPD, or custom PCI caps, but platform data generally seems
> like a better idea.

Jiri, do you have any thoughts about using phys_port_name for exposing
topology in virtual environments.  Perhaps that's the best fit on the
netdev side.  It's not like we want any other port name in such case,
and having it automatically appended to the netdev name may be useful.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ