From patchwork Fri May 6 15:57:43 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shmulik Ladkani X-Patchwork-Id: 619345 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3r1bz42mYKz9t3s for ; Sat, 7 May 2016 01:58:08 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=e1o2v0bo; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758428AbcEFP6G (ORCPT ); Fri, 6 May 2016 11:58:06 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:33788 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758143AbcEFP6E (ORCPT ); Fri, 6 May 2016 11:58:04 -0400 Received: by mail-wm0-f67.google.com with SMTP id r12so9425515wme.0 for ; Fri, 06 May 2016 08:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=GoNXgec2joREm5fzfuEGd+760t3sprbGZ4X7MXRM5RI=; b=e1o2v0bofyvkhCBZL0knysyXj6z7BrBGmQbDareDrojOaUQ4Qbkb+OZ0E+XRKjQLl5 cPLEW5NysSLk1Rhsx/hQ2sgUMvgbAYYZKJRpZhamrHCfkaWP50TJdlZE5bourh7PPyid W6NNhPp3V0O8WIOe2rfMscK73nZCHRn+qyhg5UNfOgTIGDMbw1ZixWZYFDAL3ztGqtuE iaiQYg0ZHawKFfpdod/a5hGYaXXqXhNO2qnp1ed5bJOGsO5Rq63ZIMci/pVEwQG0/SYJ H30Z2UFowQKWqmQhdjgraPrbc3biavYhzmI8FeUNN9RKndlwN2F8AmIR/s334MiPQAEl xFhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=GoNXgec2joREm5fzfuEGd+760t3sprbGZ4X7MXRM5RI=; b=PbvRk22R+2iSWdAqo6TV18/sf13eiB2Td0buUiLCW10FhWgAcVuJOlh7i6e9//TQVc STI5aNgyZQpuKFNNswgF/lMHa2nWEe4M830ddXgdf+ExKjpd/8tLOdxoGhaXxtcsT3iT 00su0u0WGzLS22PTDrsoQOrV7zSKAkHxp5teRCcrB0BfB+HUbFGORACVaM1YUKV7al/l MxkUcLy29hNq2HpHSSIoF/JhQJ4CBsJlk0d5/gArdSKlrynCi91jo/+PRjrPEXsnpF6D UCqcjREuj1BxDp7NsMvg3qR2/O+0g/VR4LdT92c6fsRuxHgw64a+Xy+NeYQO4eZrb/VX DrmA== X-Gm-Message-State: AOPr4FUk6m63XUeUcEpBgWTn7Shwoep/AqKvBRKB/hpi/wioHPisBmVS9zJm2ir1wPZjmg== X-Received: by 10.194.58.195 with SMTP id t3mr19935502wjq.97.1462550282437; Fri, 06 May 2016 08:58:02 -0700 (PDT) Received: from halley.home ([94.230.86.111]) by smtp.gmail.com with ESMTPSA id u4sm15644373wjz.4.2016.05.06.08.58.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 May 2016 08:58:01 -0700 (PDT) From: Shmulik Ladkani To: "David S . Miller" , netdev@vger.kernel.org Cc: Edward Cree , shmulik.ladkani@gmail.com Subject: [PATCH] Documentation/networking: more accurate LCO explanation Date: Fri, 6 May 2016 18:57:43 +0300 Message-Id: <1462550263-9742-1-git-send-email-shmulik.ladkani@gmail.com> X-Mailer: git-send-email 2.7.4 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org In few places the term "ones-complement sum" was used but the actual meaning is "the complement of the ones-complement sum". Signed-off-by: Shmulik Ladkani Acked-by: Edward Cree --- I assume readers interpret the term "ones-complement sum" as the sum using one's complement arithmentic, without the final bitwise complement of sum's result. Hence I added "the complement of" where applicable. Documentation/networking/checksum-offloads.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/networking/checksum-offloads.txt b/Documentation/networking/checksum-offloads.txt index de2a327766..9567200e1f 100644 --- a/Documentation/networking/checksum-offloads.txt +++ b/Documentation/networking/checksum-offloads.txt @@ -69,17 +69,17 @@ LCO: Local Checksum Offload LCO is a technique for efficiently computing the outer checksum of an encapsulated datagram when the inner checksum is due to be offloaded. The ones-complement sum of a correctly checksummed TCP or UDP packet is - equal to the sum of the pseudo header, because everything else gets - 'cancelled out' by the checksum field. This is because the sum was + equal to the complement of the sum of the pseudo header, because everything + else gets 'cancelled out' by the checksum field. This is because the sum was complemented before being written to the checksum field. More generally, this holds in any case where the 'IP-style' ones complement checksum is used, and thus any checksum that TX Checksum Offload supports. That is, if we have set up TX Checksum Offload with a start/offset pair, we know that _after the device has filled in that checksum_, the ones complement sum from csum_start to the end of the packet will be equal to - _whatever value we put in the checksum field beforehand_. This allows us - to compute the outer checksum without looking at the payload: we simply - stop summing when we get to csum_start, then add the 16-bit word at + the complement of _whatever value we put in the checksum field beforehand_. + This allows us to compute the outer checksum without looking at the payload: + we simply stop summing when we get to csum_start, then add the 16-bit word at (csum_start + csum_offset). Then, when the true inner checksum is filled in (either by hardware or by skb_checksum_help()), the outer checksum will become correct by virtue of