From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <devendra.rawat.singh@gmail.com> Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) by dpdk.org (Postfix) with ESMTP id C64C11B21F for <users@dpdk.org>; Thu, 5 Oct 2017 18:19:58 +0200 (CEST) Received: by mail-it0-f51.google.com with SMTP id p185so1964424itc.4 for <users@dpdk.org>; Thu, 05 Oct 2017 09:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BA0n9lANR3jqJJE9wzgxEI6K6F0gQO/mOU+7H1/GQq8=; b=lpML+P6oePMyJdY26/MF7Xg1+ftkd76SHQW18xd1yctP446oFhfLBz9sCn+wf/Mm2+ mnCU/EiFqKHUei3VTOnHi/7NTsmClWNHp7ZlvF6npZLDw1ZkEckwlBdQH8tjPavTSwzT Z3b8V+5cRtjVQw21u/KidaJyAxCd05hLFinxV9/GKZBaS42uAk0hmKD/IfJeRphEs69x sN2KL5VglWDVSWRYd9jXNX0KdRf1Rsi51tIy1jsOYgU6PZsoTC599COZIs18NkcoQdOg 0lF5G00p+HQqdNZU4giNgv6cGi9RXnYBkpeYJiyrhONmO/sc+DyAC59DT4NaCfWYmxNI pZUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BA0n9lANR3jqJJE9wzgxEI6K6F0gQO/mOU+7H1/GQq8=; b=Z0UqokhGyl1BMl34Qe5SXGknLrKTfCJ7L+zQXvROr37b9wMwVKpI5MJ89mN0aNotkD MfdG4aLGMJ3/RiGdduVu8BOP71zMlckLK6dfy+bSfA1i57wytE1j4E7+3CfLEvnphtUd 5FtxiRPMocsEyPi5xb9amrNNejj8VGvEzrdYrmEdiL96ldKTGfyfPx9DztkM9L0UeXid LaM59jAY6Aj7eUVyRr9Z2ujmZNdeCMpOY7Kz25ij/r+NmQ++7Wob+17mBc5RXmFaHtHH InGwU3EbEB+YZHrDBJhlNll6uyLpPUcPdRMPmfXgnJSYeFNE18/WqXG5A0x3hnYEfKiQ I8/Q== X-Gm-Message-State: AMCzsaVe8jQUUNqCUv6YS4iHrH4ImHZR38AudUfr2yLHTyiu55pW+TQg b4N2KWwE/xZN11F2mq3QrggISMfhX0QHq69+JHs= X-Google-Smtp-Source: AOwi7QBacy9t95crP7gxIgw8V8yDrYoeXKOWrvxZ/nxYFF2Ap8l8NipWzlu5U2tz1C6StPdIhNSZT+1BCSSVo4I+nZo= X-Received: by 10.36.111.4 with SMTP id x4mr31179429itb.144.1507220398006; Thu, 05 Oct 2017 09:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.200.74 with HTTP; Thu, 5 Oct 2017 09:19:57 -0700 (PDT) In-Reply-To: <74F120C019F4A64C9B78E802F6AD4CC278E0EB69@IRSMSX106.ger.corp.intel.com> References: <CACsJYqps0gM6NTUspVBcvjw1-VM4wj_UV2SbAhWGd-Y6WDBOzg@mail.gmail.com> <1990042.kGnXgAYS5O@xps> <74F120C019F4A64C9B78E802F6AD4CC278E0EB1C@IRSMSX106.ger.corp.intel.com> <1785021.jQYphEuIaN@xps> <74F120C019F4A64C9B78E802F6AD4CC278E0EB69@IRSMSX106.ger.corp.intel.com> From: devendra rawat <devendra.rawat.singh@gmail.com> Date: Thu, 5 Oct 2017 21:49:57 +0530 Message-ID: <CACsJYqpwnKPE9+WTXHuj-4Biwf+Zz4eX3jPnXCtaQhLnV7JFTQ@mail.gmail.com> To: "Loftus, Ciara" <ciara.loftus@intel.com> Cc: Thomas Monjalon <thomas@monjalon.net>, Kevin Traynor <ktraynor@redhat.com>, "ovs-dev@openvswitch.org" <ovs-dev@openvswitch.org>, Adrien Mazarguil <adrien.mazarguil@6wind.com>, "nelio.laranjeiro@6wind.com" <nelio.laranjeiro@6wind.com>, "users@dpdk.org" <users@dpdk.org>, Yuanhan Liu <yliu@fridaylinux.org>, "olgas@mellanox.com" <olgas@mellanox.com> Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 <users.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/users>, <mailto:users-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/users/> List-Post: <mailto:users@dpdk.org> List-Help: <mailto:users-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/users>, <mailto:users-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 05 Oct 2017 16:19:59 -0000 On Thu, Sep 21, 2017 at 1:58 PM, Loftus, Ciara <ciara.loftus@intel.com> wrote: > > 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. > > Ok, I see. Maybe something like this could be considered: > > port A = dpdk-devargs=xx:yy:zz 0 > port B = dpdk-devargs=xx:yy:zz 1 > > If we detect a value after the PCI address we iterate through the > rte_eth_dev_info (http://dpdk.org/doc/api/structrte__eth__dev__info.html) > for all valid port IDs and assign port A to the first ethdev encountered > with the provided PCI address, and port B to the second, etc. > > If we don't detect a value, then we operate as normal. Thoughts? > > Hi Everyone, Anything finalized for sorting out this issue, do you need any more information regarding this issue ? Thanks, Devendra > > > > > 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. > >