From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B4C24A00C2; Thu, 23 Apr 2020 09:47:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D2E171C2AF; Thu, 23 Apr 2020 09:47:14 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 7B1D51C24B for ; Thu, 23 Apr 2020 09:47:12 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03N7eBDg003082; Thu, 23 Apr 2020 00:47:11 -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=iqv7awgOWamOoTOeZQNMjgs10bAIgynarFw5y8p86J4=; b=nZXRge5KhWWrEc/hvcgplExE7J4JwoTaIMJQhKxrFtO0HRzrM3NwdT9gA2KhzjGn7HW+ NiWJ94kcOLExviOSa8UR8XYknMcbSI09z+8jL4mWA048zUOPoyUxoQUtbm1mxwZJriqI pfw+XUN6B3tGC/EjtFERf8tXByn95SNOoZ6Jj5xpsgyY2r279NqMVCYOQjq24MJ3Zc6o nt98w5sqYmQZEAhtUfm1kICnDf3EgXFKcL+iQU8D36h2+krQu+7jmywEYq0fS5N2K4mg TIvVVhzaCA2QRyaJiNfzUwtW27SqLzFU+FZbup0bDzC8PT7xV5ttr1U29RJjkwfugH/M 0Q== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0a-0016f401.pphosted.com with ESMTP id 30fxwpnv0w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 23 Apr 2020 00:47:11 -0700 Received: from DC5-EXCH02.marvell.com (10.69.176.39) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 23 Apr 2020 00:47:10 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by DC5-EXCH02.marvell.com (10.69.176.39) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 23 Apr 2020 00:47:09 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.59) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 00:47:08 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fAN/kVyoV7xyXeEni0Gqd1mI9NWsoNT0ymo4k5WfdRsqGF6/V/T3IlDdeOFi1htk+wgHE57ZfifMHOUgSOA2U/qVqqBuZjc+BiGS+zZfy+zrjFDJuulBTZkv3pfGRTq0Q9D1pYmGOLlQwCXDQOhgB8TL1dbcyvrBadm5SrX45GvGRG6RCtvbaWJTxpfbdhGHI994x7wKXgu4dvXwfObVVPlgkpkmigVIzPurV1Qq+zIXBZeJ+VOpLN/hYm25RvcV7hek8TfTAZH7/vFel4kLuQmgVFPmvn3jQlGomT4jEx3JhigkvyN360gJP/Pe0FeD64m+RVb9QDlybCK76y5bEQ== 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=iqv7awgOWamOoTOeZQNMjgs10bAIgynarFw5y8p86J4=; b=oCy9ig+whZrD9v/wOZLmrG+me8Z3owiZRVW1ao9tX+fuSaSM3YBCa4y7iuQmLg7zWZHEUO0Cji923v0nYsrDd3WwEOqdSive1fFZV4XRWtJwW33DDE+5N3EHj4YVK/RtnU+SDrgEBLOFtMYv1IQutQ6vs9AAJgzh9ZyaAIwYUONw3ijZ9gD6ZLay0pz4xkcnr5aYkx/yzleM6dieaz2MdtjgmNTLCTVb3rvzrO5lAqd7QfqlvaR624cZu4QG9ioXa6XzAkiGW8b9MNJpem7dkhAVqfZ7nCETJ3j9EJ/amVc/xWY0rTtBO5juocVDhnVL2YPgEGpbh7HwuyDjrZ4xuQ== 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=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iqv7awgOWamOoTOeZQNMjgs10bAIgynarFw5y8p86J4=; b=jqtdKc3GexUb677e9A2W4i93lTua1tc/zVG+zA2AjILyv8lIHU7LO+9evk+HEBtlNjod9W8VdrgjGOYPXFTnj2nd5tl0CyRf22gEAWk+IXsYMTtd5R6Bj/ECT++qT0UL0aRVJLAUyFmw3zoYGoF0bxMJkj7UuPD6kuTqWn1ECvs= Received: from BY5PR18MB3105.namprd18.prod.outlook.com (2603:10b6:a03:1a4::30) by BY5PR18MB3425.namprd18.prod.outlook.com (2603:10b6:a03:1af::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.27; Thu, 23 Apr 2020 07:47:06 +0000 Received: from BY5PR18MB3105.namprd18.prod.outlook.com ([fe80::cc6:c7ae:dc40:7ddf]) by BY5PR18MB3105.namprd18.prod.outlook.com ([fe80::cc6:c7ae:dc40:7ddf%7]) with mapi id 15.20.2921.032; Thu, 23 Apr 2020 07:47:06 +0000 From: Sunil Kumar Kori To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= CC: "stephen@networkplumber.org" , "david.marchand@redhat.com" , "Jerin Jacob Kollanukkaran" , "dev@dpdk.org" Thread-Topic: [EXT] Re: [dpdk-dev] [PATCH v3 1/1] bus/pci: optimise scanning with whitelist/blacklist Thread-Index: AQHWFuDHsE1AbyTvlU2Aees2cTiIn6iDsmiAgAD0u6CAAD6rAIABZzow Date: Thu, 23 Apr 2020 07:47:06 +0000 Message-ID: References: <20200407092856.554-1-skori@marvell.com> <20200420065554.20138-1-skori@marvell.com> <20200421151817.pfcktwfl72mgiuyk@u256.net> <20200422093820.kinhuqy37sjmzffl@u256.net> In-Reply-To: <20200422093820.kinhuqy37sjmzffl@u256.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2401:4900:1694:856e:2ccf:f688:ec5c:69e0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d9bd8037-0a19-4ebf-a85c-08d7e75a8588 x-ms-traffictypediagnostic: BY5PR18MB3425: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03827AF76E x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR18MB3105.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(346002)(136003)(366004)(4326008)(186003)(55016002)(86362001)(9686003)(478600001)(2906002)(66946007)(66574012)(33656002)(54906003)(316002)(66556008)(66476007)(66446008)(64756008)(5660300002)(52536014)(6916009)(76116006)(53546011)(6506007)(8676002)(81156014)(8936002)(71200400001)(7696005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UENk8HGgZX6S2qCSJONefjFYGrWVudFSGLaar/OmGasd5umzj6AKChJc2BVUiUXa3zfpEAo3oyzgfemZNLHxLAnA+MukHMlQWmID8dMpdez1Lck3xVTILDTGkTESa+r1o4Jh2EVnp1XTI9lKDPZ/b6yLnirdTPmMKJX2CWid4nlr8p3nBzHB7jlmqZcgxuE4/hN2odm5lwm/n92miVZXHbbtxJkelleqW5UBAniN1Hyy5I/dpPjQaz6ewhwI63IvEHuZ3eO0wg0PEzVc6oLahjHgEn44BpN9uDZJbSwwlernb2HjVYqu39u6vP5WYX1mznfFBMAePDDXCeWKIh75/J01UJ7GpFS5TotKErSH3fqeyqDpbpf4VheOWgByiMcTGc/Ke9SBY+BYZBPOxTfnOfjrxCWJo5ujXfjaPOffxYFvQyVzxVKQrJO1If6CzKZ6 x-ms-exchange-antispam-messagedata: LfMzoqfgPbs2nkPRgHrHU/e3PlM/qObTGSIBY87keAohCNKwLR8HKuN0InQRxwT0QCPK2dwrd58x31a5w79LfjVadXS/uYIetdkz0YmmmHwYfj1wVDrlWV6DKc5sN/3hXKPSrejL7hR2r1+/r8a1OeTSY1HlhEtnr6n1mZsZbndzcpNs2BnEkNriENKDi3xFbw6RmVI2k8tOqjA5Z8VbXg== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d9bd8037-0a19-4ebf-a85c-08d7e75a8588 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2020 07:47:06.8233 (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: MvmgoY6SejtWhrRNOJdnlyNVRkY5JmkxO0G2pDopV5Lej33PrVo3gtaQHnYvGJ0z6htd/MDwSHJN5i2qzvjkgQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3425 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-23_06:2020-04-22, 2020-04-23 signatures=0 Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v3 1/1] bus/pci: optimise scanning with whitelist/blacklist 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: Wednesday, April 22, 2020 3:09 PM >To: Sunil Kumar Kori >Cc: stephen@networkplumber.org; david.marchand@redhat.com; Jerin Jacob >Kollanukkaran ; dev@dpdk.org >Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v3 1/1] bus/pci: optimise scannin= g >with whitelist/blacklist > >On 22/04/20 06:17 +0000, Sunil Kumar Kori wrote: >> >-----Original Message----- >> >From: Ga=EBtan Rivet >> >Sent: Tuesday, April 21, 2020 8:48 PM >> >To: Sunil Kumar Kori >> >Cc: stephen@networkplumber.org; david.marchand@redhat.com; Jerin >> >Jacob Kollanukkaran ; dev@dpdk.org >> >Subject: [EXT] Re: [dpdk-dev] [PATCH v3 1/1] bus/pci: optimise >> >scanning with whitelist/blacklist >> > >> >External Email >> > >> >--------------------------------------------------------------------- >> >- On 20/04/20 12:25 +0530, Sunil Kumar Kori wrote: >> >> rte_bus_scan API scans all the available PCI devices irrespective >> >> of white or black listing parameters then further devices are >> >> probed based on white or black listing parameters. So unnecessary >> >> CPU cycles are wasted during rte_pci_scan. >> >> >> >> For Octeontx2 platform with core frequency 2.4 Ghz, rte_bus_scan >> >> consumes around 26ms to scan around 90 PCI devices but all may not >> >> be used by the application. So for the application which uses 2 >> >> NICs, rte_bus_scan consumes few microseconds and rest time is saved >> >> with this >> >patch. >> >> >> > >> >Hi Sunil, >> > >> >The PCI bus was written at first with the understanding that all PCI >> >devices were scanned and made available on the bus -- the probe will fi= lter >afterward. >> > >> >Device hotplug and iteration were written with this in mind. Changing >> >this principle might have unintended consequences in other EAL parts. >> >I'm not fundamentally against it, but it is not how buses are >> >currently designed in DPDK. >> > >> I am also not sure about this. I would request you provide suggestion >> to ensure that there won't be any negative consequences if any. So that= I >can handle those too. >> > >I would like also to hear from other stakeholders for the PCI bus. > >Generally, as long as the blacklist mode is the default, behavior should n= ot >change, but devil is in the details. > >I would have some comments on the patch itself if everyone agrees with thi= s >direction. > >If the principle of the patch is accepted, it would be great for you to te= st >hotplug and device listing with testpmd: > > hotplug: > * You can spawn VMs with virtual e1000 ports on PCI using QEMU for thi= s, > and within testpmd `port attach ` -- of course, the > port(s) should not be attached when starting testpmd. You might > have to either blacklist them, or you could hotplug them in QEMU usi= ng the > monitor. I don't recall the QEMU commands to do that, sorry. > > device list: > * `show device info all` in testpmd. I thought I had added a command t= o > test the device iterator, taking an arbitrary device string, but > the patch has been dropped it seems. > >If you have no segfault and no surprise, it is a good start. > Okay but before verification I would appreciate to have more comments and closure on principle from other PCI stakeholders. If there is no objection = on principle then I will invest energy in testing. I will wait for inputs by next week and if there are no inputs then assuming it fundamentally correct, I will start verification of above test= cases.=20 Also If anyone has already validated above mentioned test cases then Suggestions, about the impact of this patch on PCI bus design, will be very helpful to understand the real issues with this.=20 >> >To me, a one-time 26ms gain is not enough justification to change >> >this principle. How problematic is this for you? Do you encounter >> >specific issues due to this delay? >> > >> >Thanks, >> >> Recently we observed this requirement to cater a use of having lowest >bootup time for DPDK application. >> One of the use-case for this to reduce the downtime as part of DPDK SW >> upgrade in the field. i.e after the SW update, time to close the applica= tion >and restart it again for packet processing. >> Having this solution application will be up soon and lesser traffic impa= ct will >be there in a deployed system. > >DPDK startup was not written with low latency in mind. You will find here = and >there minute improvements, but I think it is a pipedream to reduce service >disruption on binary upgrade. > >People in the field would be better served with HA, not relying on a criti= cal >apps restarting as fast as possible. > Recently we had a requirement to have bootup time <=3D 500ms and find it as one of the candidate to be improved. So thought of to upstream it.=20 Also having mechanism to improve bootup time is good. I think, there is no harm in this. >Cheers, >-- >Ga=EBtan