netdev - Re: [PATCH V2 net 00/11] Extending the ena driver to support new features and enhance performance

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: <F6CECB83-63C5-4A91-8798-84846A3D7E00@amazon.com>
Date:   Fri, 7 Jun 2019 21:34:00 +0000
From:   "Bshara, Nafea" <nafea@...zon.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...nulli.us>
CC:     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 6/7/19, 2:27 PM, "Jakub Kicinski" <jakub.kicinski@...ronome.com> wrote:

    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.
    
any preference for that vs /sysfs ?