From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E1EAAA00C3; Thu, 21 Apr 2022 08:40:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7F64E410FB; Thu, 21 Apr 2022 08:40:10 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 1DAD8410E1 for ; Thu, 21 Apr 2022 08:40:10 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v1 5/5] examples/l3fwd: enable direct rearm mode Date: Thu, 21 Apr 2022 08:40:06 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86FE8@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v1 5/5] examples/l3fwd: enable direct rearm mode Thread-Index: AQHYVI8Os3vmCXi1HEGk+2Bx5G4N06z4lK6AgAEIHHCAAEehgA== References: <20220420081650.2043183-1-feifei.wang2@arm.com> <20220420081650.2043183-6-feifei.wang2@arm.com> <98CBD80474FA8B44BF855DF32C47DC35D86FE4@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Honnappa Nagarahalli" , "Feifei Wang" Cc: , "nd" , "Ruifeng Wang" , "nd" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com] > Sent: Thursday, 21 April 2022 04.35 > > > > > From: Feifei Wang [mailto:feifei.wang2@arm.com] > > > Sent: Wednesday, 20 April 2022 10.17 > > > > > > Enable direct rearm mode. The mapping is decided in the data plane > > > based on the first packet received. > > > > I usually don't care much about l3fwd, but putting configuration > changes in the > > fast path is just wrong! > I would say it depends. In this case the cycles consumed by the API = are > very less and configuration data is very small and is already in the > cache as PMD has accessed the same data structure. >=20 > If the configuration needs more cycles than a typical (depending on = the > application) data plane packet processing needs or brings in enormous > amount of data in to the cache, it should not be done on the data > plane. >=20 As a matter of principle, configuration changes should be done outside = the fast path. If we allow an exception for this feature, it will set a bad precedent = about where to put configuration code. > > > > Also, l3fwd is often used for benchmarking, and this small piece of > code in the > > fast path will affect benchmark results (although only very little). > We do not see any impact on the performance numbers. The reason for > putting in the data plane was it covers wider use case in this L3fwd > application. If the app were to be simple, the configuration could be > done from the control plane. Unfortunately, the performance of L3fwd > application matters. >=20 Let's proceed down that path for the sake of discussion... Then the fast = path is missing runtime verification that all preconditions for using = remapping are present at any time. > > > > Please move it out of the fast path. BTW, this patch does not call the rte_eth_direct_rxrearm_enable() to = enable the feature. And finally, this feature should be disabled by default, and only = enabled by a command line parameter or similar. Otherwise, future l3fwd = NIC performance reports will provide misleading performance results, if = the feature is utilized. Application developers, when comparing NIC = performance results, don't care about the performance for this unique = use case; they care about the performance for the generic use case.