From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yuanhan Liu Subject: Re: [PATCH] [RFC] ether: standardize getting the port by name Date: Wed, 6 Dec 2017 23:49:56 +0800 Message-ID: <20171206154956.GE17112@yliu-dev> References: <1512027330-30030-1-git-send-email-yliu@fridaylinux.org> <4433948.XFY0rnHxgs@xps> <20171205135831.GC9111@yliu-dev> <12208973.eJueFS28lF@xps> <20171205172205.GQ4062@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Thomas Monjalon , =?iso-8859-1?Q?Ga=EBtan?= Rivet , Stephen Hemminger , dev@dpdk.org, Ciara Loftus , Kevin Traynor , hemant.agrawal@nxp.com, Mohammad Abdul Awal , Declan Doherty To: Adrien Mazarguil Return-path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 6DDC12A5D for ; Wed, 6 Dec 2017 16:50:14 +0100 (CET) Content-Disposition: inline In-Reply-To: <20171205172205.GQ4062@6wind.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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