From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA88AC47E48 for ; Thu, 26 Sep 2019 09:41:17 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 20437222C3 for ; Thu, 26 Sep 2019 09:41:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=marvell.com header.i=@marvell.com header.b="rPRTPTv/"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=marvell.onmicrosoft.com header.i=@marvell.onmicrosoft.com header.b="YA3Oj/2V" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 20437222C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=marvell.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DEDD81BF33; Thu, 26 Sep 2019 11:41:15 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id DC0911BF31 for ; Thu, 26 Sep 2019 11:41:13 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8Q9etE0022220; Thu, 26 Sep 2019 02:41:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=3SPHz371kOIMKJDrlti+GKP6sh7hvwfPMQVzgF2TcLo=; b=rPRTPTv/t7dDCxysGasa+6tWnpW09hsjqsiqqSVR5hwewGxO7ktjMdYOYXQJmItODMFB eqJRbGjOvUEgWmwddtC7VyX7nTWx5wqXdYh7c33Q2A2YVO9yYPm5n1g0PYan1Ds+AN8o 1Nt5zh3n1Rb0xXYP/inaSRociJd5M4bkteJJahTn2MovjT1HICXRzugiSMSrj7XW0h/h FLsjlOC7N/0Y9VZp/kSmxi2M/SqTADqE7tf49oeswDEqiE8pnPpUm1C13mOvrs9GyQDb A2WsjUXVZZYHbgs0kXSgqmtlvAOFwFJUscPt1vvVXFdjGhXMu+x3SDFKCNWKPgVfrZbu sQ== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0b-0016f401.pphosted.com with ESMTP id 2v8twmr02x-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 26 Sep 2019 02:41:12 -0700 Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 26 Sep 2019 02:40:01 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (104.47.34.52) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 26 Sep 2019 02:40:01 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SmqShppzljVk8HRegLmjQriZmkjV9cRyGV6RjdcabPYM84WjO/R4UJo9kKi+Lm5QPF9QGbUT1cu+oM4i2iGgtfLxMDennBUTVhv8SNDiKHCVKkYcfvLCkm+01ly+IABKz/BMMhXhUT+QBQtkmYkWIWQYmD30uXndtVh0aGLew23AUhCYM4YY83tIFMajTPe/94xYz1/JwePu/DXXlKFVfVOpyZKrZIcnHztJ9U8kciJXKMbbY8zLi7RKogEJ1pEDb1o5G2/FXTnQKZkbAs+UA52yL6c1OwK1uM3xVDRXhMjT2Gf8X/62zINj0zlVHrwXD5krv8bJJM+nWIjCKiyGFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3SPHz371kOIMKJDrlti+GKP6sh7hvwfPMQVzgF2TcLo=; b=B4Cgfua0+WwfLOWHlyhppB3fJQSbcjbTYfXs6TKnrsHTtPqeLprgri8OGIKhwos63xwlwmOsI5MR2HjUxAkOS/N6CSFA0gZIGSrZt/sOHCGeIO8zujg9hpeItacmrsyCS+Sxjfo3Q70t3eOehfNsDFYfDhoDVile65rxCAKzcgCsVGMbYoa4T/q8UEe1ACvZ+0Leq3Si2u04ocZFOPnEVaPJ/7QIjm9qKmlniJTYCzE7M6E3KGOx6KBgQyseBAJNVAl3w1rSK59oxY9yQNBGeUVZkC5v+npHc2PydN/YEKl4EWgklOICWK6vLAMBtaFn8EfuBzk1Oq43dZEg3MouGg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3SPHz371kOIMKJDrlti+GKP6sh7hvwfPMQVzgF2TcLo=; b=YA3Oj/2V+dXr/AFTAw7UEVY2EILcSRJFRkhvwPOExDw/bJNlODZX9r1e7QWrhGjUiLhN6LREDZKK1niT+BHw14bpfJDyCx5eQUr5m/Cyh+phxG9xN9stn5w9+tMhWKZeWgXy/AJAipwhV8ZXuvnKlmJSiX13pY3wWmLW+6B8q/Q= Received: from MWHPR18MB1645.namprd18.prod.outlook.com (10.173.241.137) by MWHPR18MB1375.namprd18.prod.outlook.com (10.173.243.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.23; Thu, 26 Sep 2019 09:40:00 +0000 Received: from MWHPR18MB1645.namprd18.prod.outlook.com ([fe80::e0e3:ce2c:587a:d607]) by MWHPR18MB1645.namprd18.prod.outlook.com ([fe80::e0e3:ce2c:587a:d607%7]) with mapi id 15.20.2284.028; Thu, 26 Sep 2019 09:39:59 +0000 From: Vamsi Krishna Attunuru To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= CC: Slava Ovsiienko , "dev@dpdk.org" , "ferruh.yigit@intel.com" , "anatoly.burakov@intel.com" , Thomas Monjalon , Jerin Jacob Kollanukkaran Thread-Topic: [EXT] Re: [dpdk-dev] [PATCH v1 1/1] bus/pci: probe PCI devices in whitelisted order Thread-Index: AQHVc2xR4F+OSeK6SkyydCmfpKSaYqc8GlwAgAE3F5CAAEmfAIAAFD0w Date: Thu, 26 Sep 2019 09:39:59 +0000 Message-ID: References: <20190923115630.7929-1-vattunuru@marvell.com> <20190925090706.xeutwkjiee4hrglk@bidouze.vm.6wind.com> <20190926080402.xl6ibg6yvoyobcyh@bidouze.vm.6wind.com> In-Reply-To: <20190926080402.xl6ibg6yvoyobcyh@bidouze.vm.6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.140.231.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 862b35d5-8e5f-4a5c-c252-08d742657fb1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MWHPR18MB1375; x-ms-traffictypediagnostic: MWHPR18MB1375: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0172F0EF77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(366004)(136003)(376002)(13464003)(199004)(189003)(7696005)(102836004)(5660300002)(107886003)(6246003)(4326008)(8936002)(6916009)(81156014)(81166006)(305945005)(7736002)(54906003)(74316002)(52536014)(33656002)(6436002)(86362001)(229853002)(66446008)(64756008)(76116006)(66946007)(66556008)(66476007)(316002)(9686003)(478600001)(55016002)(66066001)(6116002)(14444005)(256004)(486006)(476003)(99286004)(71200400001)(14454004)(71190400001)(3846002)(25786009)(26005)(2906002)(66574012)(6506007)(53546011)(186003)(55236004)(446003)(11346002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR18MB1375; H:MWHPR18MB1645.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Hvm8NF8fhUR+/x5aDCt+ptXGNZs+NHRTAyps4m5k2yAZs+JMeaKTTt0SZlctntSpl15JrOV4oAyw5IchbT59yMTv/0Gj0BRUoamTYvXVKCwzUbBPkTuwBlmejXAiGi9b1Pu6XvBpDCi6o7BLG+ljv8p9jNyvcZIBlaid/aQIyz5pJTy335SRf7mvmV3TPCRKNDCDYSMYZw9fWiLFTji9r+rrekyikAe0++01ZaFBzmsdZ4XOkyGASMzx3iw7e1tOszCRkYqW0kdWOmz2q8gYEX4gV9ZQyIJ0+9T+QwY6Ydn2HN0BAoS+DrfDYyUg9J7jdUCCCoPNuXg4AQuua+hjWxwULJUfavWENs0q/BEOv5CGP0+/cM7/B2P89QI5iyWwSv3YyqfDlQpX+aFqU7Cr8WEUexZzUG4y5Sui17JXzNQ= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 862b35d5-8e5f-4a5c-c252-08d742657fb1 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2019 09:39:59.3392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AN8sp+9D2rwXcjGg8p9RfhKTT0u/gr/dafORoaV3YU1+DLbnnzuvV0UckjBpn+dk3oY3fqNHSDTbrbUS/cRfdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR18MB1375 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-26_04:2019-09-25,2019-09-26 signatures=0 Subject: Re: [dpdk-dev] [EXT] Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Ga=EBtan Rivet > Sent: Thursday, September 26, 2019 1:34 PM > To: Vamsi Krishna Attunuru > Cc: Slava Ovsiienko ; dev@dpdk.org; > ferruh.yigit@intel.com; anatoly.burakov@intel.com; Thomas Monjalon > ; Jerin Jacob Kollanukkaran > Subject: [EXT] Re: [dpdk-dev] [PATCH v1 1/1] bus/pci: probe PCI devices i= n > whitelisted order >=20 > External Email >=20 > ---------------------------------------------------------------------- > On Thu, Sep 26, 2019 at 04:15:49AM +0000, Vamsi Krishna Attunuru wrote: > > > > > > -----Original Message----- > > From: dev On Behalf Of Ga=EBtan Rivet > > Sent: Wednesday, September 25, 2019 2:37 PM > > To: Slava Ovsiienko > > Cc: Vamsi Krishna Attunuru ; dev@dpdk.org; > > ferruh.yigit@intel.com; anatoly.burakov@intel.com; Thomas Monjalon > > ; Jerin Jacob Kollanukkaran > > Subject: Re: [dpdk-dev] [PATCH v1 1/1] bus/pci: probe PCI devices in > > whitelisted order > > > > On Wed, Sep 25, 2019 at 06:41:36AM +0000, Slava Ovsiienko wrote: > > > > -----Original Message----- > > > > From: dev 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 ; > > > > jerinj@marvell.com; Vamsi Attunuru > > > > Subject: [dpdk-dev] [PATCH v1 1/1] bus/pci: probe PCI devices in > > > > whitelisted order > > > > > > > > From: Vamsi Attunuru > > > > > > > > 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 > > > > > > > > > > > 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 > > > > Hello Vamsi, Viacheslav, > > > > This is a nice patch. I agree that port dependency could be better hand= led. The > port-mapping part however should be managed at the app level. > > > > Vamsi, you gave the example of l2fwd and testpmd, being able to properl= y > configure forwarding directions implicitly. I think the better approach h= ere 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 core= s, 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 fro= m > 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-grain= ed 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 ar= e > 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 disabl= e > 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 EA= L conf), > then hotplug ports as they see fit. > > > > This will keep the existing behavior stable for current apps, while all= owing > flexibility for the more advanced ones. > > > > > > Hi Gaetan, > > > > Thanks, vdev part was not taken care in this patch. Rather than imposin= g > hotplug for every application which requires port mapping, If vdev probin= g order > is also handled same as pdevs(in whitelist order), existing whitelisting= feature > will serve the port mapping requirement, right. Also the existing applica= tions get > benefited instead of overloading them with more configuration options. I= f > these probing order is not needed by default, it can be triggered using a= n EAL > parameter(not added yet). > > > > Regards, > > A Vamsi >=20 > Hi, >=20 > The way buses are written right now, they will each do a whole scan, then= they > each probe all their devices. >=20 > You cannot intersperse probes across several buses, i.e. probe a PCI devi= ce, then > a vdev, then another PCI device. >=20 > Changing this structure could be difficult. A possible way to do what you= want > without breaking everything would be to do what the app would have done i= n > my solution above, but from within the EAL: block all probes, then go ove= r a > mixed list of (-w) and (--vdev) parameters and hotplug them in order. Thi= s would > require the --no-dev (or --no-probe, or --no-auto-probe) flag anyway (or = as a > conf item, or something at least telling the EAL to behave this way). >=20 > Would this way of doing it work for you? Yes, above approach sounds fine to me and it works without breaking everyth= ing. >=20 > In any case, controlling the probe order should be fixed properly for all= buses > and the general use-case if possible, instead of limiting the patch to th= e PCI bus. Ack >=20 > Kind regards, > -- > Ga=EBtan Rivet > 6WIND