From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 26202A00E6 for ; Tue, 16 Apr 2019 14:48:20 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2E5471B4B3; Tue, 16 Apr 2019 14:48:17 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140049.outbound.protection.outlook.com [40.107.14.49]) by dpdk.org (Postfix) with ESMTP id 3A0901B4AE for ; Tue, 16 Apr 2019 14:48:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U8Uh+OSyw+QHgYfWcZbHBfaa2zJiYtjW66B/rb6EcHI=; b=fjG0a2PcZ0+K0Y95NOTOoILizpUVmufYuJubHP6xj6fq9kG3uzjSeiwoOHKMOitJ6/iRQhrkcalFXOZ3Kt1sk3hosv/IfBu4X9ag4RVtWJJ74pFDp8N4QRiMZ6CHnKTVKRufjp7kCrm6hjF4UEkOa5AlYoz7kjOGlhJOX6qCO8w= Received: from VI1PR04MB4688.eurprd04.prod.outlook.com (20.177.56.80) by VI1PR04MB4910.eurprd04.prod.outlook.com (20.177.49.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Tue, 16 Apr 2019 12:48:15 +0000 Received: from VI1PR04MB4688.eurprd04.prod.outlook.com ([fe80::48ee:dfc2:13c2:2f96]) by VI1PR04MB4688.eurprd04.prod.outlook.com ([fe80::48ee:dfc2:13c2:2f96%5]) with mapi id 15.20.1792.018; Tue, 16 Apr 2019 12:48:15 +0000 From: Shreyansh Jain To: "Ananyev, Konstantin" , "Ruifeng Wang (Arm Technology China)" , "dev@dpdk.org" CC: nd Thread-Topic: [dpdk-dev] [PATCH] examples/l3fwd: support separate buffer pool per port Thread-Index: AdT0Udh9S5zlTgv+Qi+aOYnwnc1OzA== Date: Tue, 16 Apr 2019 12:47:58 +0000 Deferred-Delivery: Tue, 16 Apr 2019 12:47:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shreyansh.jain@nxp.com; x-originating-ip: [92.120.1.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f77923e-d74f-41cf-ca83-08d6c269cadd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:VI1PR04MB4910; x-ms-traffictypediagnostic: VI1PR04MB4910: x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(396003)(136003)(376002)(39860400002)(189003)(199004)(26005)(6436002)(66066001)(86362001)(52536014)(5660300002)(4326008)(6666004)(68736007)(81166006)(81156014)(2501003)(74316002)(3846002)(14454004)(6116002)(44832011)(71190400001)(71200400001)(14444005)(256004)(2906002)(476003)(53936002)(486006)(33656002)(102836004)(97736004)(6506007)(99286004)(110136005)(478600001)(6246003)(316002)(25786009)(8936002)(305945005)(229853002)(9686003)(7736002)(186003)(105586002)(106356001)(7696005)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR04MB4910; H:VI1PR04MB4688.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jORWbb5bIA28EqxVfGBA0hmxHLUcR3DcuAYIe+XV+07HUwYFbml4c6Pfh6u5xd9Vc1LVW99u2CXTtVJo9HTdhzqqWatxBFD/3/UKFCb5GfDu4BP8ZBMLDFRo5IO1yAbjqt33wagYCE5GZc7YL2SMYtRlD1BskBtJ61C50EFEqdwkuFYj7879hzxRy8BkrXLhDIUuL9fNG50YPvuCjGbqKp7EFOjkBzc+IhSec+3jKDIh2l2tkMakASQb+12LOtQk9bR3iOdPudh+h+KGUSwP+z/eNn7BGYC14clsPz6eav7xdW53yOh9ocrUyiXipX00vrycRXuBLtRpof+27J2GeGcsvHNh5lbXthG/8UEk+t0MP9VhUxaiS5VWJpfjq9l/1e5kMcmgNQ0Nyjlcvw/wilH7Ss83/voHPNg8+cHvhpA= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f77923e-d74f-41cf-ca83-08d6c269cadd X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 12:48:14.9210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4910 Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: support separate buffer pool per port 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" Message-ID: <20190416124758.5Mw0IFb8lVo7tjFR2FqKpMxOvnJ1wK9YhZK-WvPet0A@z> Hello Ananyev, > Hi Shreyansh, >=20 > > > > I tried this patch on MacchiatoBin + 82599 NIC. > > > > Compared with global-pool mode, per-port-pool mode showed slightly > > > lower performance in single core test. > > > > > > That was my thought too - for the case when queues from multiple > ports > > > are handled by the same core > > > it probably would only slowdown things. > > > > Thanks for your comments. > > > > This is applicable for cases where separate cores can handle separate > ports - each with their pools. (somehow I felt that message in commit > > was adequate - I can rephrase if that is misleading) > > > > In case there is enough number of cores available for datapath, such > segregation can result in better performance - possibly because of > > drop in pool and cache conflicts. > > At least on some of NXP SoC, this resulted in over 15% improvement. > > And, in other cases it didn't lead to any drop/negative-impact. >=20 > If each core manages just one port, then yes definitely performance > increase is expected. > If that's the case you'd like enable, then can I suggest to have mempool > per lcore not per port? As you have stated below, it's just the same thing with two different views= . > I think it would be plausible for both cases: > - one port per core (your case). > - multiple ports per core. Indeed. For this particular patch, I just chose the first one. Probably bec= ause that is the most general use-case I come across. I am sure the second too has equal number of possible use-cases - but proba= bly someone with access to that kind of scenario would be better suited for= validating what is the performance increase. Do you think it would be OK to have that in and then sometime in future ena= ble the second option? [...] - Shreyansh