From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CC15220B7E; Wed, 6 Dec 2017 10:50:13 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 06 Dec 2017 10:50:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fridaylinux.org; h=cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=HOrnvDYaDCAS8aVFfyB4TLve+NGL7oZ/a8wv9b7T9As=; b=iv/IyGww zhurGUqo5DFx80olEDv1HhZTtYBF2WBE+j7QqkWEceJp/JJOhPJy3ikJuWiiRqt+ E45B+arJTT4QFqWNmr4JX6it8jrxw2p25IGBXCjmL3WKChEPQhPfaqxfx7yaehwh v8Za1EezMbtHnA31T2VvXcFsTPK/t5xndYuBqj2QRw6aSILCnFbkUj2YXpZ9yShH w3hkDk4IVw4l5gGp/ul9lZUjZnVwcRKyOA7UCpkyl6WfnZToi7x3CHPx68Z6lGZw igNkvHc8BBrgu8bskYd4xlJqxy/Ob6HgrYkc9Jf+ASWqBMgyWqWcu6BlK3VeuC3T 2aqbEUPKFEjp+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=HOrnvDYaDCAS8aVFfyB4TLve+NGL7 oZ/a8wv9b7T9As=; b=bngJYSNJsHEbYo5r5SuL5FzQU2yQJ3jzxseBCGrDLvWYL J5QTbANTMyawIqjsVqNcRs1t5HHDwgJVTR5Oj60fTC1aZIeAc9vmGgoQ77599L2q zlSBvbZb62k0e99+VjO2a+lD7Kn4r3a/EL1g+TnhPpzFSvpad036TZvTNVG7YqD9 FvoGCuYbIYC/i+7udItudMHrI5k0PWz4FKQ89MVnG8o1oZnQROqr//eVJVK2RaI3 B9XoAAzlAE1EvnsQau2fGbvEeTfN47fJqZDtXM5dt4wYfxIdmMfN6ALgECuf6lZw TerSMXH5JD1an2E3j1qOmBW1c7Vz21zUVHWnBs2MQ== X-ME-Sender: Received: from yliu-dev (unknown [180.158.55.119]) by mail.messagingengine.com (Postfix) with ESMTPA id 0AEE724136; Wed, 6 Dec 2017 10:50:09 -0500 (EST) Date: Wed, 6 Dec 2017 23:49:56 +0800 From: Yuanhan Liu To: Adrien Mazarguil 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 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 Content-Disposition: inline In-Reply-To: <20171205172205.GQ4062@6wind.com> User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [dpdk-dev] [PATCH] [RFC] ether: standardize getting the port by name X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 15:50:14 -0000 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