On Tue, Dec 05, 2017 at 06:22:05PM +0100, Adrien Mazarguil wrote: > > > > > Just for information, this "port=x" argument in mlx4 is consistent > > > > > with the > > > > > value found in /sys/class/net/ethX/dev_port under Linux. If we choose > > > > > to use > > > > > a port index (instead of a MAC or something else), it would make > > > > > sense to > > > > > standardize it on the same order as given by the host OS for > > > > > consistency > > > > > across all PMDs. > > > > > > Thanks for the info. > > > > > > But FYI, for most of other PMDs, such sys file won't exist, as the host > > > driver should have been unbind and bind with something like uio. So I > > > don't think it applies to all other nics. > > Sure, I only meant PMDs must implement the same numbering scheme the kernel > driver they replace would have used (as exposed through dev_port) for > consistency. Note dev_port is always present since Linux 3.15, even with > single port/bus address devices, so applications that want to construct > -w/-b arguments can rely on that before unbinding devices.
I don't think that's a clean way. Fortunate enough though, even we want to use the port as one of the key for identification, we don't really need that in most cases. So, just like the mac proposed here, we could (and probably should) make it optional. [...] > > > I'm not a fan of the MAC naming, neither. The reason this patch proposes > > > mac > > > naming is that it's more clear for the user to specify a port. I also > > > agree > > > that the port index could be another good option. > > > > > > One thing I really haven't considered yet is how it becomes when the VF > > > reprenstor comes to play? (more guys are cc'ed). > > Won't VFs come through a separate PCI bus address anyway? Not sure extra > care is needed for those. Yes, for VF. But I was talking about VF representors [1]. Note that the interface is not settled down yet, but it's likely we need some interfaces (or more precisely, some concepts) like that. In that proposal, several ports could share a same vdev name, while each one is differenced by a vport_id. Again, it's not settled down yet, it might be something else in the end, say all share a same (PF) PCI id, while each one is identified by something else, etc. [1]: http://dpdk.org/ml/archives/dev/2017-November/080946.html --yliu
