All of lore.kernel.org
 help / color / mirror / Atom feed
From: Edward Cree <ecree.xilinx@gmail.com>
To: "J.J. Mars" <mars14850@gmail.com>, Cong Wang <xiyou.wangcong@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: Confused about ip_summed member in sk_buff
Date: Tue, 8 Nov 2022 17:12:58 +0000	[thread overview]
Message-ID: <d309d044-6e9f-e722-6d75-46b174736cc2@gmail.com> (raw)
In-Reply-To: <CAHUXu_Vf5f8G3YkWzNQhqi2ZTjNKGu_BwkuV7SzD-Tc_fHW63g@mail.gmail.com>

On 08/11/2022 12:32, J.J. Mars wrote:
> Thanks for your reply. I've been busy these days so that I can't reply on time.
> I've read the annotation about ip_summed in skbuff.h many times but it
> still puzzles me so I write my questions here directly.
> 
> First of all, I focus on the receive direction only.
> 
> Q1: In section 'CHECKSUM_COMPLETE' it said 'The device supplied
> checksum of the _whole_ packet as seen by netif_rx() and fills out in
> skb->csum. Meaning, the hardware doesn't need to parse L3/L4 headers
> to implement this.' So I assume the 'device' is a nic or something
> like that which supplied checksum, but the 'hardware' doesn't need to
> parse L3/L4 headers. So what's the difference between 'device' and
> 'hardware'? Which one is the nic?

Both.
To implement this feature, the NIC is supposed to treat the packet data
 as an unstructured array of 16-bit integers, and compute their (ones-
 complement) sum.
When the kernel parses the packet headers, it will subtract out from
 this sum the headers it consumes, and then check that what's left over
 matches the sum of the L4 pseudo header (as it should for a correctly
 checksummed packet).
Note that this design means protocol parsing happens only in software,
 with the NIC completely protocol-agnostic; thus upgrades to support
 new protocols only require a kernel upgrade and not a new NIC.

> Q2: Which layer does the checksum refer in section 'CHECKSUM_COMPLETE'
> as it said 'The device supplied checksum of the _whole_ packet'. I
> assume it refers to both L3 and L4 checksum because of the word
> 'whole'.

See above - the device is not supposed to know or care where L3 or L4
 headers start or where their checksum fields live, it just sums the
 whole thing, and the kernel mathematically derives the sum of the L4
 payload from that.

> Q3: The full checksum is not calculated when 'CHECKSUM_UNNECESSARY' is
> set. What does the word 'full' mean? Does it refer to both L3 and L4?
> As it said 'CHECKSUM_UNNECESSARY' is set for some L4 packets, what's
> the status of L3 checksum now? Does L3 checksum MUST be right when
> 'CHECKSUM_UNNECESSARY' is set?

'full' here refers to the CHECKSUM_COMPLETE sum described above.
CHECKSUM_UNNECESSARY refers to the L4 checksum, and may be set by the
 driver when the hardware has determined that the L4 checksum is
 correct.  This is an inferior hardware design because it can only
 support those specific protocols the hardware understands; but we
 handle it in the kernel because lots of hardware like that exists :(
L3 checksums are never offloaded to hardware (neither by
 CHECKSUM_COMPLETE nor by CHECKSUM_UNNECESSARY); because they only
 sum over the L3 header (not its payload), they are cheap to compute
 in software (the costly bit is actually bringing the data into cache,
 and we have to do that anyway to parse the header, so summing it at
 the same time is almost free).
AFAIK a driver may set CHECKSUM_UNNECESSARY even if the L3 checksum is
 incorrect, because it only covers the L4 sum; but I'm not 100% sure.

> Q4: In section 'CHECKSUM_PARTIAL' it described status of SOME part of
> the checksum is valid. As it said this value is set in GRO path, does
> it refer to L4 only?

Drivers should not use CHECKSUM_PARTIAL on the RX side; only on TX
 (for which see [1] for additional documentation).

> Q5: 'CHECKSUM_COMPLETE' and 'CHECKSUM_UNNECESSARY', which one supplies
> the most complete status of checksum? I assume it's
> CHECKSUM_UNNECESSARY.

CHECKSUM_COMPLETE is preferred, as per above remarks about protocols.

> Q6: The name ip_summed doesn't describe the status of L3 only but also
> L4? Or just L4?

Just L4.  It's called "ip_summed" because the "16-bit ones-complement
 sum" style of checksum is also known as the "Internet checksum"
 since it is used repeatedly in the Internet protocol suite, such as
 in TCP and UDP as well as IPv4.  Yes, this is confusing, but it's
 too late to rename it now.

HTH,
-ed

[1] https://www.kernel.org/doc/html/latest/networking/checksum-offloads.html#tx-checksum-offload

  reply	other threads:[~2022-11-08 17:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21  6:29 Confused about ip_summed member in sk_buff J.J. Mars
2022-10-22 19:51 ` Cong Wang
2022-11-08 12:32   ` J.J. Mars
2022-11-08 17:12     ` Edward Cree [this message]
2022-11-09  7:22       ` J.J. Mars

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d309d044-6e9f-e722-6d75-46b174736cc2@gmail.com \
    --to=ecree.xilinx@gmail.com \
    --cc=mars14850@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.