Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <fe807f09-9e4a-52d6-c057-b159bee55510@linux.intel.com>
Date:   Tue, 27 Jun 2023 16:05:31 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: [GIT PULL] x86/misc for 6.5
Content-Language: en-US
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Borislav Petkov <bp@alien8.de>,
        Noah Goldstein <goldstein.w.n@gmail.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>
References: <20230627110038.GCZJrBVqu/4BfdyBeN@fat_crate.local>
 <CAHk-=wghuOwXtMH9u7RAW694BOwf_Q9TeWR2v=GgLy0gjTfu4A@mail.gmail.com>
 <1982e4b4-3858-d456-6c90-92782b95726a@linux.intel.com>
 <CAHk-=wiQEj1cP7tnQ6Uw1jjFYnZmMdNgodga3b+rw98vBBvENg@mail.gmail.com>
 <CAHk-=wgMw2VE8afWp4p6RyJKCvnkhNXx4XUByUOHUWKiAo=WLQ@mail.gmail.com>
 <51f58d51-d5bf-79a2-a32a-e6849a118123@linux.intel.com>
 <CAHk-=wgtrxkRDR95y=U685LMd_ZR5TrLW0_LGoQi3v8Or11Yrw@mail.gmail.com>
From:   Arjan van de Ven <arjan@linux.intel.com>
In-Reply-To: <CAHk-=wgtrxkRDR95y=U685LMd_ZR5TrLW0_LGoQi3v8Or11Yrw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 6/27/2023 4:02 PM, Linus Torvalds wrote:
> On Tue, 27 Jun 2023 at 15:51, Arjan van de Ven <arjan@linux.intel.com> wrote:
>>
>> I'm not surprised though; running 2 parallel streams (where one stream has a fixed zero as input,
>> so can run OOO any time) .. can really have a performance change like this
> 
> How much do people care?
> 
> One of the advantages of just having that single "update_csum_40b()"
> function is that it's trivial to then manually unroll.
> 
> With a 4-way unrolling, I get
> 
>    02: 184.0 / 184.5 cycles (8b414316) Upcoming linux kernel version
>    04: 184.0 / 184.2 cycles (8b414316) Specialized to size 40
>    06: 89.4 / 102.5 cycles (512daed6) New version
>    22: 184.6 / 184.4 cycles (8b414316) Odd-alignment handling removed
> 
> but doesn't most network hardware do the csum on its own anyway? How
> critical is csum_partial(), really?

the hardware does most cases..
in
https://lore.kernel.org/netdev/20211111181025.2139131-1-eric.dumazet@gmail.com/
Eric kind of implies it's for IPv6 headers in practice