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 BCCA4A0544; Tue, 14 Jun 2022 23:20:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A910A40DDD; Tue, 14 Jun 2022 23:20:54 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 0E05D40220 for ; Tue, 14 Jun 2022 23:20:54 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 8A0903200406; Tue, 14 Jun 2022 17:20:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 14 Jun 2022 17:20:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1655241650; x= 1655328050; bh=NAwXbUs1EZSm1pqyDKM+tCXvI9bPV/ZZO5+YUas7ilY=; b=L lrrbAIH6piqmtZuNWk1A5O8fGacp1sArcNdpz/BGgn/+zPBmG8tzEZH5hcRQu6bi coOr3EFgngiju+40n1N80iHBd4O1jT1j4ZyUEV43dUlg9/rjjNyv/cHk5gvcBZhE /NnrhKD57GgNbaFkA+Pzkb8UQXS+wIvTzCkWL34vDC+zOR1G1cqPH5aVX4zcS/PQ lgsNYyhVKPPUHogiVTw0C7pZIb1kDAET1+yUXVnq0PSbNoELiiueUhqyKq1744Yy Ft4+9DCOjixtgCcF/rQriS2jBi1dXLTbQhg5omWjxFf1ue01jNVHIX6yb+oVhtK+ FllE8nSbiK84xCQnExI7w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1655241650; x= 1655328050; bh=NAwXbUs1EZSm1pqyDKM+tCXvI9bPV/ZZO5+YUas7ilY=; b=W nZmjvy6N94a3KXLNkmORA6UsEXv7i2AFs6HRzqYQ5Q9XAcCNznRw8wpn5ygnT+Oa 0LmyFCW7oRwqbztINYBDclYm3tEs0OTcntYasx8vY2fjR9mTJcQo+LKQwTowgvRc mL6H37OJ4od3NnrLq0DsYQU2DFeVhwGrmAZsOETJsb/jTM9fib3bhCwmdHkpXctu 8tzKVLe7+P0m30HlBLv/wxPuP+fHm/B2N732Zr1iyQ0KPCQk1IJru9FmbmnWO2Hb LhnaajSLh2E4zgaRMiM2nAXkZiR5px0mKQMicHXS6vKwPaBkhKlRxucUJZsa0VPu HRTnXNIW0lGJRapib0XFQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudduledgudehjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnhepgedttdeljeejgeffkeekkedtjeevtdehvedtkeeivdeuuedv ieduvdelveejueejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Jun 2022 17:20:49 -0400 (EDT) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: Stephen Hemminger , Konstantin Ananyev , dev@dpdk.org Subject: Re: [RFC 8/8] ip_frag: fix gcc-12 warnings Date: Tue, 14 Jun 2022 23:20:46 +0200 Message-ID: <2651319.mvXUDI8C0e@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87101@smartserver.smartshare.dk> References: <20220607171746.461772-1-stephen@networkplumber.org> <20220608082644.5f99029e@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35D87101@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 09/06/2022 09:09, Morten Br=C3=B8rup: > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Wednesday, 8 June 2022 17.27 > >=20 > > On Wed, 8 Jun 2022 09:19:20 +0100 > > Konstantin Ananyev wrote: > >=20 > > > 07/06/2022 18:17, Stephen Hemminger =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > The function rte_memcpy can derference past source buffer which > > > > will cause array out of bounds warnings. But there is no good > > reason > > > > to use rte_memcpy instead of memcpy in this code. Memcpy is just > > > > as fast for these small inputs, and compiler will optimize. > > > > > > > > > AFAIK, rte_memcpy() will outperform memcpy() when _size_ parameter > > > is a variable. Unfortunately that's exactly the case here. > > > So not sure it is a good change, at least without extensive perf > > testing. > > > BTW, if rte_memcpy() really access src buffer beyond it's boundaries, > > > I think that's definitely a bug that needs to be fixed. > >=20 > > Yes and no. > > IMHO DPDK should not in the C library business, and glibc etc should be > > more optimized if necessary. >=20 > A very big +1 to that! >=20 > DPDK contains a lot of optimizations that really belong in the compiler a= nd/or C library, but weren't back then, so the clever DPDK developers put t= hem inside DPDK instead. >=20 > Over time, the compilers and C libraries have improved, and many of these= manually implemented optimizations have become obsolete. They should be cl= eaned up and replaced by simpler code, and the documentation about optimizi= ng code should be updated accordingly. >=20 > Until that happens, we have to expect contributors to use rte_memcpy() an= d other obsolete optimizations - they are only doing what the DPDK document= ation and reference code tells them. Just like application developers are u= sing KNI, because it is so heavily promoted in DPDK documentation. >=20 > The DPDK community has a very high focus on the risk of performance regre= ssions when touching DPDK Core libraries, so a general cleaning is probably= not going to happen. Luckily, there are exceptions to every rule, such as = Georg Sauthoff's patch removing the manual loop unroll in __rte_raw_cksum()= [1], which allowed the compiler to generate something better. >=20 > I guess that "if it isn't broken, don't fix it" applies to DPDK Core libr= aries too. ;-) No it doesn't apply, the only limitation is the number of contributions. =46eel free to propose cleanups.