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 C985CA0487 for ; Mon, 1 Jul 2019 08:44:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 096043195; Mon, 1 Jul 2019 08:44:10 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50078.outbound.protection.outlook.com [40.107.5.78]) by dpdk.org (Postfix) with ESMTP id 73973235 for ; Mon, 1 Jul 2019 08:44:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ttcT2PmE07hZ+2v/8/Xbkk7ATQEANJ0hcYmwLMUUsA4=; b=B/lmKZvrZF71X5LEbXPrNVHifht6/tNqY6PHR/ddotCdF0JVX9ON03mG0+DyiwU0O4nmPZ3KOCQ3yObeFXnM5KuCC9WuFdsjzUAndqxshDfQ76I3LP5OIEvfhtzQ22QXRytH8M86GbSxikhKDD89pGZnrTbmJp4LrqBsHuRNXxw= Received: from AM0PR08MB4418.eurprd08.prod.outlook.com (20.179.35.207) by AM0PR08MB3489.eurprd08.prod.outlook.com (20.177.108.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Mon, 1 Jul 2019 06:44:07 +0000 Received: from AM0PR08MB4418.eurprd08.prod.outlook.com ([fe80::3582:a8b6:2af4:a6d]) by AM0PR08MB4418.eurprd08.prod.outlook.com ([fe80::3582:a8b6:2af4:a6d%3]) with mapi id 15.20.2032.019; Mon, 1 Jul 2019 06:44:07 +0000 From: "Ruifeng Wang (Arm Technology China)" To: "Medvedkin, Vladimir" CC: Honnappa Nagarahalli , Stephen Hemminger , "bruce.richardson@intel.com" , "dev@dpdk.org" , "Gavin Hu (Arm Technology China)" , nd , nd Thread-Topic: [dpdk-dev] [PATCH v3 1/3] lib/lpm: not inline unnecessary functions Thread-Index: AQHVLMwV0WqbgHJxDE+UVV0PVSn4MKavn1SAgACuGHCAAC6gAIAAmlcAgAADAACAAAUuAIAAFfeAgAQc6xA= Date: Mon, 1 Jul 2019 06:44:07 +0000 Message-ID: References: <20190627093751.7746-1-ruifeng.wang@arm.com> <20190627082451.56719392@hermes.lan> <20190627213450.30082af6@hermes.lan> <185e012d-6f8a-66be-dc8c-a420065660fb@intel.com> <20190628083507.31eca1db@hermes.lan> In-Reply-To: <20190628083507.31eca1db@hermes.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 4c088f1c-990a-414f-b485-a3b82e8579fe.0 x-checkrecipientchecked: true authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruifeng.Wang@arm.com; x-originating-ip: [113.29.88.7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 98b4558e-73f0-45d2-1de4-08d6fdef8402 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR08MB3489; x-ms-traffictypediagnostic: AM0PR08MB3489: nodisclaimer: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00851CA28B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(396003)(39850400004)(366004)(53754006)(13464003)(199004)(189003)(68736007)(3846002)(66476007)(73956011)(66946007)(66556008)(76116006)(64756008)(6116002)(66446008)(74316002)(478600001)(66066001)(72206003)(305945005)(7736002)(52536014)(4326008)(33656002)(81166006)(25786009)(8936002)(81156014)(5660300002)(8676002)(76176011)(2906002)(476003)(11346002)(446003)(256004)(55236004)(102836004)(14444005)(486006)(53936002)(7696005)(26005)(54906003)(53546011)(6506007)(229853002)(6916009)(99286004)(71190400001)(71200400001)(316002)(55016002)(6436002)(14454004)(9686003)(86362001)(6246003)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3489; H:AM0PR08MB4418.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lc7tJml7zPAwx5vKuIx6hPkXojuEh5pt7XaxTZPDmFeEJPLQqwWckBnJoDaIz1uP2tfl6iXANlWrIudiH25IaY3p+9G7/I6q39Las3GLA/ehJvOjonh2OB3KjGr/WbJnbB7yQJlBWpxv3d9+M2lkHyIiRJzvU0XxtjNwUsNtTXEhYEbDObA5D1gYM4DwGH1WobIvXpDKh0g6E7GfngFR6GZdoYlXPI+E3L0ADS2QJMYKQe/ZPuRsoOFkaLEnvfIcHo2oX0jdcK8R00QoNhuwqRvyu1iFNjnfTtABquJOV7xsm9CKwN/7Wp3NPio+MEW7hxRGEpbjcr+u9blzNVY00nntzhuCQ6GGxbX1pTNs/O1+bdrXLFdJYN1p3uJLS/IIC5lKMPTfEJbKfv02oZAgFNsVRv+UCSGhZ9vCLPirwkk= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98b4558e-73f0-45d2-1de4-08d6fdef8402 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2019 06:44:07.2646 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ruifeng.Wang@arm.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3489 Subject: Re: [dpdk-dev] [PATCH v3 1/3] lib/lpm: not inline unnecessary functions 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 Medvedkin, > -----Original Message----- > From: Stephen Hemminger > Sent: Friday, June 28, 2019 23:35 > To: Medvedkin, Vladimir > Cc: Honnappa Nagarahalli ; Ruifeng Wang > (Arm Technology China) ; > bruce.richardson@intel.com; dev@dpdk.org; Gavin Hu (Arm Technology > China) ; nd > Subject: Re: [dpdk-dev] [PATCH v3 1/3] lib/lpm: not inline unnecessary > functions >=20 > On Fri, 28 Jun 2019 15:16:30 +0100 > "Medvedkin, Vladimir" wrote: >=20 > > Hi Honnappa, > > > > On 28/06/2019 14:57, Honnappa Nagarahalli wrote: > > >> Hi all, > > >> > > >> On 28/06/2019 05:34, Stephen Hemminger wrote: > > >>> On Fri, 28 Jun 2019 02:44:54 +0000 "Ruifeng Wang (Arm Technology > > >>> China)" wrote: > > >>> > > >>>>>> Tests showed that the function inlining caused performance drop > > >>>>>> on some x86 platforms with the memory ordering patches applied. > > >>>>>> By force no-inline functions, the performance was better than > > >>>>>> before on x86 and no impact to arm64 platforms. > > >>>>>> > > >>>>>> Suggested-by: Medvedkin > Vladimir > > >>>>>> Signed-off-by: Ruifeng Wang > > >>>>>> Reviewed-by: Gavin Hu > > >>>>> { > > >>>>> > > >>>>> Do you actually need to force noinline or is just taking of inlin= e > enough? > > >>>>> In general, letting compiler decide is often best practice. > > >>>> The force noinline is an optimization for x86 platforms to keep > > >>>> rte_lpm_add() API performance with memory ordering applied. > > >>> I don't think you answered my question. What does a recent version > > >>> of GCC do if you drop the inline. > > >>> > > >>> Actually all the functions in rte_lpm should drop inline. > > >> I'm agree with Stephen. If it is not a fastpath and size of > > >> function is not minimal it is good to remove inline qualifier for > > >> other control plane functions such as rule_add/delete/find/etc and > > >> let the compiler decide to inline it (unless it affects performance)= . > > > IMO, the rule needs to be simple. If it is control plane function, we= should > leave it to the compiler to decide. I do not think we need to worry too m= uch > about performance for control plane functions. > > Control plane is not as important as data plane speed but it is still > > important. For lpm we are talking not about initialization, but > > runtime routes add/del related functions. If it is very slow the > > library will be totally unusable because after it receives a route > > update it will be blocked for a long time and route update queue would > overflow. >=20 > Control plane performance is more impacted by algorithmic choice. > The original LPM had terrible (n^2?) control path. Current code is better= . > I had a patch using RB tree, but it was rejected because it used the > /usr/include/bsd/sys/tree.h which added a dependency. Based on current discussion, I'd like to drop this single patch from the pa= tch set. Since it is not directly related to memory ordering changes in this library= . We can remove inlines in a follow up patch.