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 5A423A2EEB for ; Tue, 10 Sep 2019 11:06:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6625F1EDEA; Tue, 10 Sep 2019 11:06:27 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 54BE51EB3B for ; Tue, 10 Sep 2019 11:06:26 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2019 02:06:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,489,1559545200"; d="scan'208";a="189282634" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga006.jf.intel.com with ESMTP; 10 Sep 2019 02:06:23 -0700 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 10 Sep 2019 10:06:22 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX156.ger.corp.intel.com ([169.254.3.246]) with mapi id 14.03.0439.000; Tue, 10 Sep 2019 10:06:22 +0100 From: "Ananyev, Konstantin" To: "Ruifeng Wang (Arm Technology China)" , "Kantecki, Tomasz" CC: "dev@dpdk.org" , "Gavin Hu (Arm Technology China)" , Honnappa Nagarahalli , nd , nd Thread-Topic: [dpdk-dev] [PATCH 0/2] add lock-free mode for l3fwd Thread-Index: AQHVZJ2V0VFLih9NLEC8cBERfEm4mKcecv3ggAQVfgCAAhqkwA== Date: Tue, 10 Sep 2019 09:06:21 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258019196218E@irsmsx105.ger.corp.intel.com> References: <20190906102615.36942-1-ruifeng.wang@arm.com> <2601191342CEEE43887BDE71AB977258019192657B@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGY5NDc1MzAtNDA3OS00YzI5LWFiYmYtMjQyYzJmZjE4ZWFlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoicUZmSmdSWXBXQjZvM3dlWFBaTDVZWWY3Z015RTB4T3RKTWp5MCs3ZTYwUlZDUVwvS2UyZnBXdXZ3WWZPTWUxbWsifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.181] 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" > > > > > > > > Lock-free mode is supported by hash library and LPM library. > > > Now we add an option for l3fwd example to enable the lock-free mode. > > > Necessary preparation steps are added to use lock-free LPM mode. > > > > Can I ask about the purpose of these changes? > > Right now in l3fwd both lpm and hash tables are static and hard-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 f= ile or so). > > Konstantin > > > Thanks for your questions. > Currently, we have no plan to enhance l3fwd with ability to dynamically u= pdate 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 performance > as well. > Since l3fwd application is showcasing data path performance, we need to s= how the impact of > including the quiescent state reporting 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-fre= e 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 missing. My opinion - we either need to leave l3fwd as it is (static routes), or implement a proper control path with ability to dynamically update route= s before starting to introduce some synchronization schemes (RCU or whatever)= .=20 Konstantin >=20 > > > > > > 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