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 0E01DA034F; Sat, 16 Oct 2021 19:17:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 94FB340040; Sat, 16 Oct 2021 19:17:08 +0200 (CEST) Received: from turing.lru.li (turing.lru.li [49.12.115.177]) by mails.dpdk.org (Postfix) with ESMTP id 7DDF84003C for ; Sat, 16 Oct 2021 19:17:06 +0200 (CEST) Received: from dell12.lru.li (unknown [IPv6:2001:1a80:303a:0:faca:b8ff:fe50:d072]) (Authenticated sender: georg) by turing.lru.li (Postfix) with ESMTPSA id 294335E4B6A; Sat, 16 Oct 2021 17:17:06 +0000 (UTC) Received: by dell12.lru.li (Postfix, from userid 1000) id 8E73E1A6E28; Sat, 16 Oct 2021 19:17:05 +0200 (CEST) Date: Sat, 16 Oct 2021 19:17:05 +0200 From: Georg Sauthoff To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org, Ferruh Yigit , Olivier Matz , Thomas Monjalon , David Marchand Message-ID: References: <20210918114930.245387-1-mail@gms.tf> <20210918114930.245387-2-mail@gms.tf> <14e68fb1-0c73-8a6f-0032-7adf186ceb0c@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D86C44@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86C44@smartserver.smartshare.dk> Subject: Re: [dpdk-dev] [PATCH 1/1] net: fix aliasing issue in checksum computation 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 Sender: "dev" Hello, On Sat, Oct 16, 2021 at 10:21:03AM +0200, Morten Brørup wrote: > I have given this some more thoughts. > > Most bytes transferred in real life are transferred in large packets, > so faster processing of large packets is a great improvement! > > Furthermore, a quick analysis of a recent packet sample from an ISP > customer of ours shows that less than 8 % of the packets are odd size. > Would you consider adding an unlikely() to the branch handling the odd > byte at the end? sure, I don't see a problem with adding unlikely() there. I'll post a version 2 of that patch then, tomorrow. Best regards Georg -- "No one can write decently who is distrustful of the reader's intelligence, or whose attitude is patronizing." (William Strunk, Jr. and E.B. White, The Elements of Style, p. 70, 1959)