On 6/7/19, 2:27 PM, "Jakub Kicinski" <jakub.kicin...@netronome.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 ?
