From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 2E6EA1B160 for ; Thu, 21 Sep 2017 10:19:34 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4E43420BBD; Thu, 21 Sep 2017 04:19:34 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 21 Sep 2017 04:19:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=LRTvjESah6u8Q37 vwgtxpohjUKcntf1GCwLzzWfhEf0=; b=nA2z1RIec2AhrWTVHjdgiemli3CY7y7 a/GydZK67ZyV/Y8wijxfM1w35//5OUvnTi1Mp2HS+VAO2MsRkVkX28EbiPgwQ80J IqHd2CMhQpsgaLgGWnc5jANPsWiDS6lFXUfTbGl/iv+QuRz/56KSRMc4Mf0syCTR CmFAFKTPjx9c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=LRTvjESah6u8Q37vwgtxpohjUKcntf1GCwLzzWfhEf0=; b=j0fOa3gb i41XZcrghFlFEK409WBYa828IVwDIgUvxB4LL7/IVvmYZubUSgxf8LiDgZLCWvE5 Kshxj88us+Mw2PmbhpQ6SVV6s3wSboZCbeOXxLNciT6VlJtgGDoxACIvPeOnsCdG i1cctua2xkXhQnVinhvfzCCMYYNI0yrj39OODQULTn5m/4l42XanU8wAOMc+Uu4w 7LM/0BiIO1cyYtGazPtxv/NMUnEXs3txoggD8CzmWsUqt0O64wU7JIxnIjZDZnZs CtFJl6ysmQvXSKIuXoaf3Mq73bO2LNVWM57sxkU7S5QW9bXyOYjQlQJxPUoMtpTW JpdKaWa+5X+jWQ== X-ME-Sender: X-Sasl-enc: rgh21D/PhSp1yXauSBeSMxFFuoelPeN2XkFSfLoIp2Vg 1505981973 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id EE0DF7E187; Thu, 21 Sep 2017 04:19:33 -0400 (EDT) From: Thomas Monjalon To: "Loftus, Ciara" Cc: Kevin Traynor , devendra rawat , ovs-dev@openvswitch.org, Adrien Mazarguil , nelio.laranjeiro@6wind.com, users@dpdk.org, Yuanhan Liu , olgas@mellanox.com Date: Thu, 21 Sep 2017 10:19:33 +0200 Message-ID: <1785021.jQYphEuIaN@xps> In-Reply-To: <74F120C019F4A64C9B78E802F6AD4CC278E0EB1C@IRSMSX106.ger.corp.intel.com> References: <1990042.kGnXgAYS5O@xps> <74F120C019F4A64C9B78E802F6AD4CC278E0EB1C@IRSMSX106.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-users] [ovs-dev] adding dpdk ports sharing same pci address to ovs-dpdk bridge X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:19:35 -0000 21/09/2017 10:04, Loftus, Ciara: > > 20/09/2017 19:33, Kevin Traynor: > > > On 09/08/2017 10:56 AM, Loftus, Ciara wrote: > > > > It seems the DPDK function rte_eth_dev_get_port_by_name() will > > > > always return the port ID of the first port on your NIC, > > > > when you specify the single PCI address and that's where the > > > > problem is. There doesn't seem to be a way currently to > > > > indicate to the calling application that in fact two > > > > (or more) port IDs are associated with the one PCI address. > > > > We have two ports (with the same PCI address) so we should have > > two different names. > > Where the names passed to rte_eth_dev_get_port_by_name() come from? > > It is the user parameter from options:dpdk-devargs=0002:01:00.0, right? > > Yes, we're using the PCI address specified by the user in dpdk-devargs. > > > > > I am cc-ing DPDK users mailing list for hopefully some input. > > > > Are there any plans for the rte_eth_dev_get_port_by_name function > > > > to be compatible with NICs with multiple ports under the same PCI address? > > > > We cannot return two different ports for the same name. > > There are two issues here: > > - the input should not be the PCI address > > - the ethdev function should look at ethdev name, not rte_device > > one > > This would require the user having to "guess" the DPDK ethdev name > which is something we'd like to avoid. Yes, but you can provide a way to list the ports with their names and characteristics. > We had the same problem using DPDK port IDs and decided not to use > them anymore, and use the PCI instead as it took the guesswork out. > Ethdev names and port IDs can change between tests, unlike the PCI > address which tends to remain constant for a device. We can add a requirement on ethdev names and make sure they remain constant for a given port. > > The idea is that we have only one rte_device object and we instantiate > > two rte_eth_dev ports. > > An ethdev port can be identified with its id (a number) or its unique name. > > Unfortunately, the user cannot guess the port id or the name set by the > > PMD. > > Exactly. Thanks for clarifying what's going on under the hood. > > Ciara > > > > > > Hi Adrien/Nelio, > > > > > > Is this something you can answer? We're wondering how to handle this in > > > OVS and whether a temporary or long term solution is needed. > > > > I suggest to rely on ethdev name. > > You will need to show to the user the mapping between the bus information > > (PCI id here) and the device names. > > > > Another alternative is to add a new function returning all ethdev ports > > associated to a given rte_device resource. > > So you would get two ports and you could pick one on the first "add-port", > > and the other one for the second "add-port" command. > > It means the user would be forced to add them in the right order if he > > wants a reproducible result.