Re: [dpdk-dev] [PATCH] [RFC] ether: standardize getting the port by name

[Yuanhan Liu <yliu@fridaylinux.org>]

On Fri, Dec 01, 2017 at 10:47:50AM +0100, Gaëtan Rivet wrote:
> On Thu, Nov 30, 2017 at 10:44:58PM +0100, Thomas Monjalon wrote:
> > 30/11/2017 22:21, Stephen Hemminger:
> > > On Thu, 30 Nov 2017 18:35:11 +0100
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > 
> > > > 30/11/2017 18:15, Stephen Hemminger:
> > > > > Some thoughts.
> > > > > 1) Not all devices are PCI; look at recent VMBUS  
> > > > 
> > > > Yes, we need a syntax which works for every devices.
> > > > I suggest to use the prefix "pci:" before the PCI id.
> > > > We need also a prefix and ids for NXP buses.
> > > > We could use "vmbus:" before VMBUS ids.
> > > > How VMBUS ids look like?
> > > > 
> 
> rte_devargs are easily accessible, user-readable. Only thing missing
> would be requiring a 1-1 mapping between an rte_devargs and a port, thus
> requiring PMDs to have at least one version of a device string that
> would probe a single port (as is done with port= in mlx4).
> 
> Implementing an rte_devargs to rte_device in rte_bus is simple enough,
> and this would allow implementing an rte_devargs to port_id in rte_eth.
> 
> What am I missing?

rte_devargs is identified by the name (pci id for pci device). It also
includes other driver specific key-value options. It's not clear for the
user to know which one (or few) of them should be used together with the
PCI id to identify a specific port. For example, as you mentioned, in
mlx4, it's "pci_id,port=x". It could be something else in other drivers.

Actually, this patch also proposes a devarg like naming style: "name[,mac]".
What it does try to do is to define a standard syntax, so that the user
doesn't have to know any driver specific options.

However, the mac address is changeable, leaving this naming inconsistent.
Well, in practice, PCI id is also changeable.

OTOH, having a consistent naming seems a bit far away from this patch's
goal: define a standard ethdev naming and leave less harassment to the users.

	--yliu
> 
> > > > > 2) The name may have to be set before MAC address is determined on boot.  
> > > > 
> > > > I don't understand this comment.
> > > > Do you mean MAC may be unknown when starting DPDK?
> > > 
> > > The MAC be known by the hardware, but the device would have to be
> > > created before using  hardware to read it.
> > 
> > Indeed, it is a problem if we want to use this syntax for blacklist.
> > 
> > 
> > > > > 3) The names themselves are not persistent or human friendly. This is hard
> > > > >    see the effort udev goes to.  
> > > > 
> > > > Yes udev has a syntax to identify devices. It can be inspiring.
> > > > Qemu may also be inspiring:
> > > > 	https://github.com/qemu/qemu/blob/master/docs/qdev-device-use.txt
> > 
> 
> -- 
> Gaëtan Rivet
> 6WIND