From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 1386B1AEEB for ; Thu, 21 Sep 2017 10:04:26 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 01:04:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,424,1500966000"; d="scan'208";a="151731273" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga005.jf.intel.com with ESMTP; 21 Sep 2017 01:04:23 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.36]) by IRSMSX153.ger.corp.intel.com ([169.254.9.34]) with mapi id 14.03.0319.002; Thu, 21 Sep 2017 09:04:22 +0100 From: "Loftus, Ciara" To: Thomas Monjalon , Kevin Traynor CC: devendra rawat , "ovs-dev@openvswitch.org" , Adrien Mazarguil , "nelio.laranjeiro@6wind.com" , "users@dpdk.org" , Yuanhan Liu , "olgas@mellanox.com" Thread-Topic: [dpdk-users] [ovs-dev] adding dpdk ports sharing same pci address to ovs-dpdk bridge Thread-Index: AQHTMjbFBSAzK8Ty40aLyMCaG+/JtKK+RNyAgACzFuA= Date: Thu, 21 Sep 2017 08:04:22 +0000 Message-ID: <74F120C019F4A64C9B78E802F6AD4CC278E0EB1C@IRSMSX106.ger.corp.intel.com> References: <74F120C019F4A64C9B78E802F6AD4CC278E04762@IRSMSX106.ger.corp.intel.com> <1990042.kGnXgAYS5O@xps> In-Reply-To: <1990042.kGnXgAYS5O@xps> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjcyYzY5MTctNzc1Zi00ZjMxLWExZWUtZmJkOGQyYWViZTMzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlZOQTBUQ2ZnT1cxekNrYUFuTFM3T0p4SVgyWHM3RG9zaHJMV243dHgyWWc9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:04:27 -0000 > 20/09/2017 19:33, Kevin Traynor: > > On 09/08/2017 10:56 AM, Loftus, Ciara wrote: > > >> Hi, > > >> > > >> I have compiled and built ovs-dpdk using DPDK v17.08 and OVS v2.8.0. > The > > >> NIC that I am using is Mellanox ConnectX-3 Pro, which is a dual port= 10G > > >> NIC. The problem with this NIC is that it provides only one PCI addr= ess > for > > >> both the 10G ports. > > >> > > >> So when I am trying to add the two DPDK ports to my br0 bridge > > >> > > >> # ovs-vsctl --no-wait add-port br0 dpdk0 -- set Interface dpdk0 > type=3Ddpdk > > >> options:dpdk-devargs=3D0002:01:00.0 > > >> > > >> # ovs-vsctl --no-wait add-port br0 dpdk1 -- set Interface dpdk1 > type=3Ddpdk > > >> options:dpdk-devargs=3D0002:01:00.0 > > >> > > >> The port dpdk1 is added successfully and able to transfer data, but > adding > > >> dpdk0 to br0 fails: > [...] > > >> With OVS v2.6.1 I never had this problem as dpdk-devargs was not > > >> mandatory > > >> and just specifying port name was enough to add that port to bridge. > > >> > > >> Is there a way to add port both ports to bridge ? > > > > > > 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. >=20 > 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=3D0002:01:00.0, right? Yes, we're using the PCI address specified by the user in dpdk-devargs. >=20 > > > I am cc-ing DPDK users mailing list for hopefully some input. Are the= re 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? >=20 > 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. We had the same problem using DPDK port IDs and decided not to use them any= more, 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. >=20 > 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 nam= e. > 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 >=20 > > 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. >=20 > 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. >=20 > 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.