From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E64E5A0613 for <public@inbox.dpdk.org>; Wed, 25 Sep 2019 11:07:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B2B8A2BAB; Wed, 25 Sep 2019 11:07:10 +0200 (CEST) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id 614221E25 for <dev@dpdk.org>; Wed, 25 Sep 2019 11:07:09 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id i18so5679750wru.11 for <dev@dpdk.org>; Wed, 25 Sep 2019 02:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=EYQxEpn9KmqVPEJHwLhjlSYBf8fdLVOZkr7Gw09mADU=; b=fwGxeGozhKOVe0+AfuMZ6xS79WrCVlGabSzvxhJp44P/+Nsedt3to6Z7SAakUc+wdo TqAw0wCScSx8+13LzoW4KatlZk3Jso4Ndi+TH8C54DPPC7w6KoqFnUtHSD/L0lwzd1N7 qjpyfbXoTw5dgSoLer1f3yc9q60Hpn0y8Csd1p0GCD3UGh801fdoqoeqzoWQX4H3L0kA pPhc1qZjMNkfxgmz1gGDFW5C/V7LDO01+9scs/nAi0ymd2glkBdEpXeeLxWMLfzBOh64 fucTjMtnNPt4PW1nvdSGYf4MoPkFQKzyacrdscwfRvFVra8Vf9ZjGBA4kf8VoYaBrxfT IWSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=EYQxEpn9KmqVPEJHwLhjlSYBf8fdLVOZkr7Gw09mADU=; b=NBiNiamqhl7kkdyLpsawR/VgGk7R+7I+LTJMfTirQ5cwDOUV/fsznkNNzK43Rhrihy AQLvNsoEuBjodUYoF9XbCS0yQHxePZZU19U0Jm7s5KF0osksvs4Y9mzsRUzfNAXfzRPW Fd5nD5GYG1hNqHzVqyc5S1Vf9EYUxZWCjALLOIP5pb1QTXm+avyazIy5LFJkd4WoG3wY OjEU9Na204Xotc1wYzsED1t/OfdMzx8UjVy3oCY97G6wxv2+jYZ0cFWVQZxLg+OLKqDW tCccqcARsNQhAQSZukETXiHTg/ycCvZGMKTGCFG2S2RZtroOise2+WsOuPLl9zxyocnL o+DA== X-Gm-Message-State: APjAAAUoCdTiJG/TWAfJfdnEHyY5kg/2WNzcydzPr7XPcRs9X3XhCM1k l1mj7Lzs2HYvOLr8AKdfZBRlaw== X-Google-Smtp-Source: APXvYqy1ERD2yR90zoqVht78Tr225uHzubYmic5j1AX4AFOwlyTh3cLdNEdMuYQtbQbjLxlXciwsCA== X-Received: by 2002:adf:cc0a:: with SMTP id x10mr7805749wrh.195.1569402429076; Wed, 25 Sep 2019 02:07:09 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id a71sm2102666wme.11.2019.09.25.02.07.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Sep 2019 02:07:08 -0700 (PDT) Date: Wed, 25 Sep 2019 11:07:06 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com> To: Slava Ovsiienko <viacheslavo@mellanox.com> Cc: "vattunuru@marvell.com" <vattunuru@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>, "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>, "anatoly.burakov@intel.com" <anatoly.burakov@intel.com>, Thomas Monjalon <thomas@monjalon.net>, "jerinj@marvell.com" <jerinj@marvell.com> Message-ID: <20190925090706.xeutwkjiee4hrglk@bidouze.vm.6wind.com> References: <20190923115630.7929-1-vattunuru@marvell.com> <AM4PR05MB32659A26400F3A38BB7F972DD2870@AM4PR05MB3265.eurprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <AM4PR05MB32659A26400F3A38BB7F972DD2870@AM4PR05MB3265.eurprd05.prod.outlook.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v1 1/1] bus/pci: probe PCI devices in whitelisted order X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Wed, Sep 25, 2019 at 06:41:36AM +0000, Slava Ovsiienko wrote: > > -----Original Message----- > > From: dev <dev-bounces@dpdk.org> On Behalf Of vattunuru@marvell.com > > Sent: Monday, September 23, 2019 14:57 > > To: dev@dpdk.org > > Cc: gaetan.rivet@6wind.com; ferruh.yigit@intel.com; > > anatoly.burakov@intel.com; Thomas Monjalon <thomas@monjalon.net>; > > jerinj@marvell.com; Vamsi Attunuru <vattunuru@marvell.com> > > Subject: [dpdk-dev] [PATCH v1 1/1] bus/pci: probe PCI devices in whitelisted > > order > > > > From: Vamsi Attunuru <vattunuru@marvell.com> > > > > Current pci bus driver scans pci devices in the order that it read from sysfs. > > Accordingly all or whitelisted devices are getting probed. > > > > Patch modifies the probing order of whitelisted pci devices in a sequence the > > devices are whitelisted(using EAL flags). > > Thanks, it would be nice to have opportunity to control probing order, > it might be useful for bonded devices and representors either. > > Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> > > > > > It ensures the eth devices that application uses are probed in device > > whitelisted sequence, in turn it facilitates the packet forwarding applications > > to work without any packet loss or performance drop when the underneath > > network ports have different bandwidths. By altering the whitelist order > > applications like testpmd, l2fwd can forward the ingress traffic to egress port > > that has of equivalent bandwidth. > > > > Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com> Hello Vamsi, Viacheslav, This is a nice patch. I agree that port dependency could be better handled. The port-mapping part however should be managed at the app level. Vamsi, you gave the example of l2fwd and testpmd, being able to properly configure forwarding directions implicitly. I think the better approach here is to add these configurations items within the apps directly. Configuring the mapping at the port level is not precise enough. The proper control is about cores, port and queues, not only ports. This patch only solves a limited part of this issue with testpmd. I wrote a command to do this, that collided with some stream rework from Intel at the time (3, 4 years back?), so I did not take the time to force it through. If there is a need we could discuss about adding this back. I had needed it to write a PMD, that could be useful to others. As you say Viacheslav, there are use-cases that will rely on fine-grained probe order. However, this patch solves this issue only regarding PCI devices, depending on other PCI devices. We have in EAL an improper hack about it, forcing the vdev probe last, because usually ports depending on others are virtual ones. As this patch shows, the hack is not sufficient, and as the hack shows, this patch does not cover everything. A solution, would be an EAL parameter (I propose --no-dev), that disable probing for all buses. Applications and devices requiring a fine-grained probe order, are then free to start in this mode (and maybe force it through EAL conf), then hotplug ports as they see fit. This will keep the existing behavior stable for current apps, while allowing flexibility for the more advanced ones. -- Gaëtan Rivet 6WIND