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 E921DA2EEB for ; Wed, 11 Sep 2019 10:35:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BDBC31BF0F; Wed, 11 Sep 2019 10:35:21 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 1FDF42C08 for ; Wed, 11 Sep 2019 10:35:18 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2019 01:35:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,489,1559545200"; d="scan'208";a="384621465" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by fmsmga005.fm.intel.com with ESMTP; 11 Sep 2019 01:35:17 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX108.ger.corp.intel.com ([169.254.11.112]) with mapi id 14.03.0439.000; Wed, 11 Sep 2019 09:35:16 +0100 From: "Ananyev, Konstantin" To: "Ruifeng Wang (Arm Technology China)" , "Honnappa Nagarahalli" , "Kantecki, Tomasz" CC: "dev@dpdk.org" , "Gavin Hu (Arm Technology China)" , nd , nd , nd Thread-Topic: [dpdk-dev] [PATCH 0/2] add lock-free mode for l3fwd Thread-Index: AQHVZJ2V0VFLih9NLEC8cBERfEm4mKcecv3ggAQVfgCAAhqkwP///u+AgAFKNwCAABZYAIAAKs2A Date: Wed, 11 Sep 2019 08:35:15 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580191962AB2@irsmsx105.ger.corp.intel.com> References: <20190906102615.36942-1-ruifeng.wang@arm.com> <2601191342CEEE43887BDE71AB977258019192657B@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258019196218E@irsmsx105.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDgzYzU2OWItYzFiYi00ODkzLTk4NjAtODUzZmU3MDFjNjhiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiVFAwcTd4bFhnS0xiMjMwYnU0Z2lrak93V3pIaUllTGsxN1l3WXdjVFwvODN1czdyYkpaVlJJcDlyQ3l3dXV1ajgifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 0/2] add lock-free mode for l3fwd 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: Ruifeng Wang (Arm Technology China) [mailto:Ruifeng.Wang@arm.com] > Sent: Wednesday, September 11, 2019 7:58 AM > To: Honnappa Nagarahalli ; Ananyev, Konstan= tin ; Kantecki, Tomasz > > Cc: dev@dpdk.org; Gavin Hu (Arm Technology China) ; nd = ; nd ; nd > Subject: RE: [dpdk-dev] [PATCH 0/2] add lock-free mode for l3fwd >=20 > > -----Original Message----- > > From: Honnappa Nagarahalli > > Sent: Wednesday, September 11, 2019 13:38 > > To: Ruifeng Wang (Arm Technology China) ; > > Ananyev, Konstantin ; Kantecki, Tomasz > > > > Cc: dev@dpdk.org; Gavin Hu (Arm Technology China) ; > > Honnappa Nagarahalli ; nd > > ; nd > > Subject: RE: [dpdk-dev] [PATCH 0/2] add lock-free mode for l3fwd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Lock-free mode is supported by hash library and LPM library. > > > > > > > Now we add an option for l3fwd example to enable the lock-fre= e > > > mode. > > > > > > > Necessary preparation steps are added to use lock-free LPM mo= de. > > > > > > > > > > > > Can I ask about the purpose of these changes? > > > > > > Right now in l3fwd both lpm and hash tables are static and har= d- > > coded. > > > > > > we initialize them at startup and then just do read from them. > > > > > > Do you plan to enhance l3fwd with ability to dynamically update > > > > > > tables contents? > > > > > > Though fir that we first have to get rid of hard-coded values > > > > > > (config file or > > > > so). > > > > > > Konstantin > > > > > > > > > > > Thanks for your questions. > > > > > Currently, we have no plan to enhance l3fwd with ability to > > > > > dynamically > > > > update table contents. > > > > > Lock-free method is being integrated into Hash library and LPM > > > > > library. Lock-free algorithms are not only about control plane > > > > > (adding or deleting routes), they affect the data path performanc= e as > > well. > > > > > Since l3fwd application is showcasing data path performance, we > > > > > need to show the impact of including the quiescent state reportin= g > > > > > on data > > > path. > > > > > This change also serves as an example of using the RCU APIs. > > > > > > > > > > > > But what you suggest doesn't provide the complete picture. > > > > With dynamic updates in place (via control path) the data-path > > > > impact might be completely different then without. > > > > Again without dynamic updates how can you test that your data-path > > > > lock- free approach does work as expected? > > > > Also it can't even be used as a reference implementation for users, > > > > as half of the functionality they need to implement is simply missi= ng. > > > > My opinion - we either need to leave l3fwd as it is (static routes)= , > > > > or implement a proper control path with ability to dynamically > > > > update routes before starting to introduce some synchronization > > > > schemes (RCU or whatever). > > > > > > > > Konstantin > > > > > > > > > > Agree that dynamic control path updates should be included for a whol= e > > > picture. > > > I will add dynamic update to l3fwd and reroll the patch series. > > > Thanks. > > I think we should have an agreement on what exactly we mean by > > 'dynamically update routes'. > > IMO, we should not disturb the existing static routes as there might be > > automated tests running in the labs. I suggest that we should add/delet= e > > new routes/hash entries which are different from the existing routes/ha= sh > > entries. This should be sufficient to showcase the functionality as wel= l as > > measure the impact. > > > Yes, existing static routes should be kept intact. > To perform regular route/hash entries add/delete, a dedicated lcore will = be needed. > An interactive prompt is not an option since we need automatic add/delete= . > We can skip master core for data path main loop. And perform unrelated ro= ute/hash entries add/delete regularly on master core. > The impact is that command lines used in tests will need update since mas= ter core will no longer do data path work. Not sure why it has to be master core? Why interrupt thread wouldn't do? I think what we need to: 1. introduce reading routes from config file instead of having them hard-co= ded within the app. 2. add ability to update routes dynamically. Probably the easiest (and commonly used way) re-read conf file and upda= te routes on the signal (SIGUSR1 or so). Konstantin > > > > > > > > > > > > > > > > > > > > > > Patch 2/2 has dependency on RCU QSBR integration with LPM > > library: > > > > > > > http://patches.dpdk.org/project/dpdk/list/?series=3D6288 > > > > > > > > > > > > > > > > > > > > > Ruifeng Wang (2): > > > > > > > examples/l3fwd: add lock-free option for l3fwd > > > > > > > examples/l3fwd: integrate RCU QSBR for LPM mode > > > > > > > > > > > > > > doc/guides/sample_app_ug/l3_forward.rst | 3 ++ > > > > > > > examples/l3fwd/Makefile | 1 + > > > > > > > examples/l3fwd/l3fwd.h | 4 +- > > > > > > > examples/l3fwd/l3fwd_em.c | 10 +++- > > > > > > > examples/l3fwd/l3fwd_lpm.c | 72 > > > > +++++++++++++++++++++++-- > > > > > > > examples/l3fwd/main.c | 27 ++++++++-- > > > > > > > examples/l3fwd/meson.build | 1 + > > > > > > > 7 files changed, 108 insertions(+), 10 deletions(-) > > > > > > > > > > > > > > -- > > > > > > > 2.17.1 > > > > >