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 40847A04FA; Mon, 3 Feb 2020 10:22:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 96D411BFC0; Mon, 3 Feb 2020 10:22:26 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id DE0481BFA1 for ; Mon, 3 Feb 2020 10:22:24 +0100 (CET) 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 0139EeT1017507; Mon, 3 Feb 2020 01:22:24 -0800 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=1uKgv8GdOaCcn/ZOSHnMg3aypSR/UjznqXwX+NxGe5Q=; b=lUfzWNHLdqiGB+axNAVXXUIM3U86YdWs8ahlOYjps87p3JZm6+LRUmFbY7Ny6cTKG9f8 dPjeCvd0kzvNYe/pC0udoQuzerBzzXVgMNQnbqU/fR3FCA5UWfnkulFf89vJlZfKj9wV ChmYJCgxoFR7RiUVp4hA26Qiqu6QMYdIqJtWgdM9buzCDCpckEgVi6i/sMy6akB9cZB0 GZ3v5+/3k9JLlxrpSOFMgX4DsmLETn6N7r/HAxZlTSeLmcsTIxtWkDf48/1f0p1TIV95 2gckYcdB0odiz9m9dp9Q1Y2P46AYXoj5kaUebPsV4iQ1WJ6B439tiXBCIXuLHpfKGaRq SQ== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0a-0016f401.pphosted.com with ESMTP id 2xw7jvej4n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 03 Feb 2020 01:22:24 -0800 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Feb 2020 01:22:22 -0800 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.51) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 3 Feb 2020 01:22:22 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cH1flxEgH3uQrxU1rJdjDqP26UBC/l4HU5yN4l1EfT4lCi3uJ82UQT+X/g2l/LJJ7Ere9k3wBa7QH9M1h1MyhkHlWu5CeUGR2pRCgxDussB5zIDFz8p0SCiCuRUsHS5Z0eVyAnO3PqlpoOH6kbePaTln7ilD6fpctDaLC+OuZXtQGxShy8jbzpdV8IT3A19xtjF2EWfuSUETDUn/AMIGycZX2IERarli5GcLz3Gw5K2yDrIFFeJvmVCh5V8Xa7yvc1tsxrhPX2w2vTxZRjFr3oIj64juzJWL9hZI3SBcPVnOHn5ybekZqqz2KwLLoPyCZKeusJLx+kCR/1hUgCz9qQ== 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=1uKgv8GdOaCcn/ZOSHnMg3aypSR/UjznqXwX+NxGe5Q=; b=Q/lmPI27VJL628Bu39Q3WAsTQB1d5u/Tc7p2eYi0axwo5M2HuNLuCRf49o7b/3PYQbd0coj0jPmqy/v5qsin9yiZdGojz5wjdrNlGRaY9bjrvICVpAO/L1oX1INIOnzfhyB8Yryby67bHt2YEVoH6jKMNf3HNOZsdXZK0dX+Yl2R4guUkYQqkJdFqjO/sVZ3cbYmMM75mm+2tSB+V3MnTyO9jOsofTh8lClYAbRVNeHIdMgZO1aqngnwq7uH9OJ9LxmpYapc2hnKDC4z+mD7T6qUlx+H7BNh1MFuZkKDBvyagkgEoiWuJQRuoOQqwKLkwYUlmh6Xu0R8vL/DYbyRew== 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=1uKgv8GdOaCcn/ZOSHnMg3aypSR/UjznqXwX+NxGe5Q=; b=qurzaktsi7csIAs27lIx9nOMGr+IPIYpDlqyMJkzWG7buRupnqvgvE6SGqZyDwx627ETOGVk5jvGEutdkY3S6vXpqZ8m4IktLYGgIknI7Kp/4azLay90EAcXHdn7XBvCDRNJWdN3NjffyU05rL7HTu/Y3QIx0Cz/k+/kr/MgLWo= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB2816.namprd18.prod.outlook.com (20.179.21.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.28; Mon, 3 Feb 2020 09:22:21 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::e48d:494:fc46:3572]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::e48d:494:fc46:3572%7]) with mapi id 15.20.2686.031; Mon, 3 Feb 2020 09:22:21 +0000 From: Anoob Joseph To: Akhil Goyal , "Ananyev, Konstantin" , "Nicolau, Radu" CC: Jerin Jacob Kollanukkaran , Lukas Bartosik , Narayana Prasad Raju Athreya , "dev@dpdk.org" Thread-Topic: [PATCH] examples/ipsec-secgw: increase number of qps to lcore_params Thread-Index: AQHVx8TYVDK8x5pEckiwirDv9/IQuKgCUt6AgAEuDPCAAZd9AIAABTbggAAhMACABBMEIIAAA6kAgAABhjA= Date: Mon, 3 Feb 2020 09:22:20 +0000 Message-ID: References: <1578667598-18942-1-git-send-email-anoobj@marvell.com> In-Reply-To: Accept-Language: en-IN, 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: 06d8514a-aaf3-4bf2-4b3b-08d7a88a927a x-ms-traffictypediagnostic: MN2PR18MB2816: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(346002)(376002)(136003)(39850400004)(199004)(189003)(110136005)(316002)(7696005)(54906003)(478600001)(52536014)(66556008)(6506007)(66476007)(33656002)(66446008)(64756008)(53546011)(5660300002)(66946007)(8936002)(76116006)(81166006)(55236004)(81156014)(8676002)(71200400001)(55016002)(9686003)(186003)(86362001)(26005)(2906002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2816; H:MN2PR18MB2877.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: BCL:0; x-microsoft-antispam-message-info: CCf8IhIX78OMWawG3spczmcBjWJroAXYTvR1kfOPVhC4Kpq2L52fq6oXpY07si55AK9lpK+U3N2s+jS2vr0OCyOPIyp48TcJ/umDBd9jN9LcyDtOLYHdyN2H+yysYYsuCTD9NgRWzftS7GlvKaMkmDLsCMhXoZ5sx3zar4l1Zmz8/z5/r/0pYxdIXud5A7W2+hz1VP/HxZbf3NVJPxtDQyu6R9p/wumJR6P1msn1c486wedqREfVB085v9q82Um8jgymzgsdVBJjPZ+DtlbRcyDMmGCzfEes/CQY7mNIOdLKvA/tE5cymjTh1wINiX/qVXFMA2uXf3eSRqhpa25LVmMY7SIANdSCFwQseZzhiGEtMGc7vCsfaY8vnnl6OnbFIqoOJY0dOzkcaiUUoA4gXwYIybLHTDGkjqyNtM8wjgHqdKHwOkWMsMd3Sw2UXIye x-ms-exchange-antispam-messagedata: yL43NoXPMYmUq+zRfSHDfo5yvb2qR3BaywGTk9eiYTCAVxCH4b/Dv3+MSVMLbAJVyHbZJM7At5asA22QbpLsS8WF8Zg0M5H7gEXxCewlLU13JwGM75YRkigZEvFcxTVFWrFDTJIJatDlfpwUe3DSQw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 06d8514a-aaf3-4bf2-4b3b-08d7a88a927a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2020 09:22:21.1106 (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: 6trbNytLnKEMaHoRcPVZuBG1KUmgqxm4B7ENqDXoqZ0l+AHPbpse8yfS5di/3r05MbAbB44PbTv74Tnx1jw/4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2816 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-03_02:2020-02-02, 2020-02-03 signatures=0 Subject: Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: increase number of qps to lcore_params 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" Hi Akhil, Please see inline. Thanks, Anoob > -----Original Message----- > From: Akhil Goyal > Sent: Monday, February 3, 2020 2:46 PM > To: Anoob Joseph ; Ananyev, Konstantin > ; Nicolau, Radu > Cc: Jerin Jacob Kollanukkaran ; Lukas Bartosik > ; Narayana Prasad Raju Athreya > ; dev@dpdk.org > Subject: [EXT] RE: [PATCH] examples/ipsec-secgw: increase number of qps t= o > lcore_params >=20 > External Email >=20 > ---------------------------------------------------------------------- > > > > > > > > Currently only one qp will be used for one core. The > > > > > > > > number of qps can be increased to match the number of lcore > params. > > > > > > > > > > > > > > I don't really understand the purpose of that patch.... > > > > > > > As I understand, all it does - unconditionally increases > > > > > > > number of crypto-queues mapped to the same lcore. > > > > > > > > > > > > [Anoob] With the current code, we will have only crypto qp > > > > > > mapped to one lcore. So even if you have large number of > > > > > > crypto qps, you would be only > > > > > using as much as the number of lcores. > > > > > > > > > > > > This is an inefficient model as a fat flow(say with large > > > > > > packet > > > > > > sizes) on one eth queue hitting one core can starve another > > > > > > flow which > > > > > happens to hit the same core, because both flows would get > > > > > queued to the same qp. > > > > > > And, we cannot just randomly submit to multiple qps from the > > > > > > same core as then the ordering would be messed up. > > > > > > > > > > No-one suggesting that one I believe. > > > > > > > > > > So the best possible usage model would be to map one eth queue > > > > > to one > > > > > > crypto qp. That way, the core wouldn't be unnecessarily > > > > > > pipeline the crypto > > > > > processing. > > > > > > > > > > I doubt it is really the 'best possible usage model'. > > > > > There could be cases when forcing lcore to use/manage more > > > > > crypto-queues will lead to negative effects: perf drop, not > > > > > enough crypto queues for all eth queues, etc. > > > > > If your HW/SW requires to match each eth queue with a separate > > > > > crypto-queue, then I think it should be an optional feature, > > > > > while keeping default behavior intact. > > > > > > > > [Anoob] I think the question here is more to do with s/w crypto > > > > PMDs vs h/w crypto PMDs. For s/w PMDs, having more queues doesn't > > > > really > > > make sense and for h/w PMDs it's better. > > > > > > Not always. > > > If these queues belongs to the same device, sometimes it is faster > > > to use just one queue for device per core. > > > HW descriptor status polling, etc. is not free. > > > > > > > I'll see how we can make this an optional feature. Would you be > > > > okay with allowing such behavior if the underlying PMD can support > > > > as many > > > queues as lcore_params? > > > > > > > > As in, if the PMD doesn't support enough queues, we do 1 qp per cor= e. > > > Would that work for you? > > > > > > I am not fond of idea to change default mapping method silently. > > > My preference would be a new command-line option (--cdev-maping or > so). > > > Another thought, make it more fine-grained and user-controlled by > > > extending eth-port-queue-lcore mapping option. > > > from current: ,, to > > > ,,,. > > > > > > So let say with 2 cores , 2 eth ports/2 queues per port for current > > > mapping user would do: > > > # use cdev queue 0 on all cdevs for lcore 6 # use cdev queue 1 on > > > all cdevs for lcore 7 --lcores=3D"6,7" ... -- -- > config=3D"(0,0,6,0),(1,0,6,0),(0,1,7,1),(1,1,7,1)" > > > > > > for the mapping you'd like to have: > > > --lcores=3D"6,7" ... -- --config=3D"(0,0,6,0),(1,0,6,1),(0,1,7,2),(1,= 1,7,3)" > > > > [Anoob] I like this idea. This would work for inline case as well. > > > > @Akhil, do you have any comments? > > > > Also, I think we should make it > > ,,,, > > > Looks good to me, but I believe this would need more changes and testing = in > event patches. > Also it does not have any changes for lookaside cases. > Can we move this to next release and add lookaside case as well in a sing= le > go. [Anoob] Not a problem. I'll defer this to next release then. =20 > We need to close the RC2 on 5th Feb, and I don't want to push this series= for > RC3 as it is a massive change in ipsec-secgw. >=20 > -Akhil