From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Duyck Subject: Re: [net-next PATCH v2 4/8] udp: Do not pass checksum as a parameter to GSO segmentation Date: Fri, 4 May 2018 15:28:38 -0700 Message-ID: References: <20180504182537.5194.72775.stgit@localhost.localdomain> <20180504182958.5194.62398.stgit@localhost.localdomain> <52c9b572-ddcd-94ea-b9b6-787ca924698a@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Netdev , Willem de Bruijn , David Miller To: Eric Dumazet Return-path: Received: from mail-oi0-f66.google.com ([209.85.218.66]:34522 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751630AbeEDW2n (ORCPT ); Fri, 4 May 2018 18:28:43 -0400 Received: by mail-oi0-f66.google.com with SMTP id l1-v6so20485122oii.1 for ; Fri, 04 May 2018 15:28:42 -0700 (PDT) In-Reply-To: <52c9b572-ddcd-94ea-b9b6-787ca924698a@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, May 4, 2018 at 1:19 PM, Eric Dumazet wrote: > > > On 05/04/2018 11:30 AM, Alexander Duyck wrote: >> From: Alexander Duyck >> >> This patch is meant to allow us to avoid having to recompute the checksum >> from scratch and have it passed as a parameter. >> >> Instead of taking that approach we can take advantage of the fact that the >> length that was used to compute the existing checksum is included in the >> UDP header. If we cancel that out by adding the value XOR with 0xFFFF we >> can then just add the new length in and fold that into the new result. >> > >> >> + uh = udp_hdr(segs); >> + >> + /* compute checksum adjustment based on old length versus new */ >> + newlen = htons(sizeof(*uh) + mss); >> + check = ~csum_fold((__force __wsum)((__force u32)uh->check + >> + ((__force u32)uh->len ^ 0xFFFF) + >> + (__force u32)newlen)); >> + > > > Can't this use csum_sub() instead of this ^ 0xFFFF trick ? I could but that actually adds more instructions to all this since csum_sub will perform the inversion across a 32b checksum when we only need to bitflip a 16 bit value. I had considered doing (u16)(~uh->len) but thought type casing it more than once would be a pain as well. What I wanted to avoid is having to do the extra math to account for the rollover. Adding 3 16 bit values will result in at most a 18 bit value which can then be folded. Doing it this way we avoid that extra add w/ carry logic that is needed for csum_add/sub.