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 898AAA053B; Thu, 6 Feb 2020 12:02:42 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CBC931BF54; Thu, 6 Feb 2020 12:02:41 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 28577AAD5 for ; Thu, 6 Feb 2020 12:02:40 +0100 (CET) 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 016B0QjC031214; Thu, 6 Feb 2020 03:02:39 -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=hcy0cyzWsE9fconHTdsbAPxPF/KRNnzhBwhspf86VaI=; b=ucXqW+e2HV3i4G9JASm+rjbV2bfUipXnpabXkjETCNhBsbZs/oiRtf+Gqut029SVE6Xm aDi8AEfAZJpVYWQZFEHLOgVPLggc1A+H660+xqURlvjALMLZTTHxN7jhygIm1SgpnN3C y0KdvIEEYCGF8x39ZjlSmJLCuRjRoJaiNNnRxMfqQJPH6+06f0V9Gpkscp6SATT+PTcP nD61QMLN1nvCJBUC1MM8gkE/VeXI2NWjnRSWiLX6vRn2KYObcBMOpXGR0rG439ozPLNz OdYvR93DatKK9TxMAup6SLli9FP+Fx9MbGPzKtCtbJ5trvpEZtrCP09G6p8LqqaX4i11 0g== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2xyhn178gu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Feb 2020 03:02:39 -0800 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 6 Feb 2020 03:02:37 -0800 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.102) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 6 Feb 2020 03:02:37 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NE2XQ8raRb1TW96fQevAzEj5VK3eJaZvnGvw7fBGDk/HMwVwU3MAaLjKP6xbF2Ld+4k3Gw9ZDbX8d511VLivvSHWMj2CiVRBzTgf5hV1afmqUQS4MuHwsbEHuS9oLjMUPdJFWqVx/T9IPR5ANBIq2JmnyCPjTsE7hvq78j1L/rtG7u2twYhS59OVaH3m97SNlJuBA0qQI9PsY/b9em+PbgOBtcxqZpwCYGm6SFSZTWImaKX9xHTNgrHuy5SEktvRlyShcReoCq2inzOm0vnNE9Dz3o+n4aW3Q8dEuFxj9xGnOCkV+DX4bZAhXyLEiaHjLmOxnyhzI9gm2vv4jmu6fg== 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=hcy0cyzWsE9fconHTdsbAPxPF/KRNnzhBwhspf86VaI=; b=Mtavzrj5Cvh7nGff+aTjrNhfEcO73qlDniF4nJRD6CUmKHZX8j2FxKMDbJdmgkf2E8quMLFFrXgi08Yj+SzExPCzZ557tS5yjseX9Y73zisAqv2ZIV92vr3idrHrUU63m2xgcQQEkiJ2MGJvWOPBKX/wWSgOnSfXDR0Hf06rQkixilbEipD188bWuFv/iYVmp5lJrThHglgK5ZnxEZGv9XzI6/+5TyM0ClNaKEivv/t6FpSQaVTU+cEQQ7XBmw51sXc0PyfQfdc0Y/EBJn14LiMglrG9NSaGw1o1p4IhJoIgrnel5Q3rZK/u6ZXiOky0xZp7JfoI+YPH8miXDZGm2g== 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=hcy0cyzWsE9fconHTdsbAPxPF/KRNnzhBwhspf86VaI=; b=vECOZdsHs4RdzAynAqQHLeGt9VoVg3ksgIlYhXGh6bsrRRxinEW8cv00YyomKRfFTq+DUKzGeGbGBuSdFnuaIpdzsjzmTNzvvwCn/Myc6+97pV6O08u8zsHxmAhFo+7WZ3pAbaXiMFHMlDgyEks5JHGZgyGXypPKRM/K87R6TK8= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB2656.namprd18.prod.outlook.com (20.179.84.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Thu, 6 Feb 2020 10:46:41 +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.2707.024; Thu, 6 Feb 2020 10:46:41 +0000 From: Anoob Joseph To: Akhil Goyal , "Ananyev, Konstantin" , "Nicolau, Radu" , Thomas Monjalon 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/IQuKgCUt6AgAEuDPCAAZd9AIAABTbggAAhMACABBMEIIAAA6kAgAABhjCABMkFYA== Date: Thu, 6 Feb 2020 10:46:40 +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: 540cb15a-e819-44cc-f094-08d7aaf1d9b1 x-ms-traffictypediagnostic: MN2PR18MB2656: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(136003)(376002)(39860400002)(366004)(189003)(199004)(33656002)(66556008)(81156014)(81166006)(8936002)(64756008)(8676002)(66446008)(55236004)(5660300002)(4326008)(52536014)(478600001)(66946007)(66476007)(76116006)(9686003)(53546011)(71200400001)(55016002)(2906002)(54906003)(186003)(110136005)(316002)(86362001)(26005)(7696005)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2656; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: BRZL7lyBO4H/3/sRMKnYIGjlV9kTlZJzmLfXhr1l3LBMdTMmsNyImS4fpmde+LXZZuuvBZYLlU4KfID3rUZ6/4e8Cf0+b4OZLgYZ7vj9dhLsNyNjFy8Y2fYlwxDJBI3mFeGRx9D5JFVR3r9seNstC5IWziSXf8lAjL4l2Eu5wlaicZj9MObpZWQ6XM90PpUruwVRKu4e427mxD+/c93Yf+1pORbMXqg5ztRIrQzddydWztz9HfpCMbBCZiufSgiVQ9okFyfL7vC/T3lhvSAo18hGwrH5/dmwP7FMx6vLj1A9VT4t4akha2b3STe5iKoILqpbcHX+zIW0A2+kC8RYkn5wvv4gOil4jXP2xPpj/1pn/TM6ybR2hY46gSeTekisif3xoPHdeXoOLMeGLKMH93xtU6gSF7EkFEkINkDwiNnnowH1FZyPeAqV1ZL69hRL x-ms-exchange-antispam-messagedata: apmIwpJU0uBqJIFWDPf8iHaOEVTUiEk0yxRZCPA7C5GlNxgviba4Lpw8w/2h5aGgjcyY+5h/k4v8IT6GGjvdNN+wbd3PHQY9QA21uNQyMXZ8Sxd/VrPaPgRZSU3b2hSQWKPCfO5uXxH/YmfjGzKWFw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 540cb15a-e819-44cc-f094-08d7aaf1d9b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 10:46:41.0153 (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: ejTOekSHOrj5aztspOJlr22liVPM+BLNhsNMo3Cwcp74HqCz+MPKFb4NyFD8gkcnLZWExNrodnLe0O2mtkEuSQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2656 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-06_01:2020-02-06, 2020-02-06 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, > > > @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 > > single go. >=20 > [Anoob] Not a problem. I'll defer this to next release then. This patch is not part of the event additions to ipsec-segcw. This patch is= required to handle few corner cases, but is equally applicable to lookasid= e crypto as well. I had agreed to only deferring this patch. Lukasz is preparing v4 of event mode patches with doc update and addressing= one minor comment from Konstantin. If the event ipsec-secgw patches are no= t getting merged for this release, can you confirm it will be merged immedi= ately after this release? I'm assuming you have finished the reviews as the= patch was submitted early in this release cycle. Thanks, Anoob > -----Original Message----- > From: Anoob Joseph > Sent: Monday, February 3, 2020 2:52 PM > To: Akhil Goyal ; Ananyev, Konstantin > ; Nicolau, Radu > Cc: Jerin Jacob Kollanukkaran ; Lukas Bartosik > ; Narayana Prasad Raju Athreya > ; dev@dpdk.org > Subject: RE: [PATCH] examples/ipsec-secgw: increase number of qps to > lcore_params >=20 > Hi Akhil, >=20 > Please see inline. >=20 > Thanks, > Anoob >=20 > > -----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 to lcore_params > > > > External Email > > > > ---------------------------------------------------------------------- > > > > > > > > > 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 > core. > > > > 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 > > single go. >=20 > [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. > > > > -Akhil