lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [patch #10111] [RFC] Hardware checksum offloading


From: Simon Kuenzer
Subject: [lwip-devel] [patch #10111] [RFC] Hardware checksum offloading
Date: Mon, 27 Sep 2021 05:32:10 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:92.0) Gecko/20100101 Firefox/92.0

Follow-up Comment #2, patch #10111 (project lwip):

[comment #1 comment #1:]
> > These patches implement the capability to offload checksum computation
> 
> Without having the time to look into the patches right now: You do know that
we have the stack prepared for checksum offloading? From reading the text, it
doesn't seem so. Please describe what the differences are to the existing
version.

Yes, I read the documentation and also I checked the code. Sorry for my long
formulation. In short: We need the following changes to make offloading work
with virtio-net and netfront:
- A software computed partial checksum of just the pseudo header in the
TCP/UDP header. The hardware unit will take this one to complete computation
from there. I could have done this within our netif driver and switch TCP/UDP
checksum generation completely off, but this is not very efficient: I would
need to parse protocol headers while we setup the transmission. If I really
missed that you already compute such a partial checksum for TCP and UDP, then
I am sorry.
- A per-packet flag and offsets that indicate where the checksum field is and
where to continue computation in hardware. Our netif driver needs to tell this
virtio and we should not parse headers in the driver.

As outlook (not part of these patches yet), I plan to extend this work with
another pbuf flag (for instance called DATA_VALID) that can tell the stack to
skip checksum checks for packets. We need this on a per packet base because we
need to be able to handle mixed traffic: (1) checksums might be already
checked (but not necessarily) by a physical network card attached to the
hypervisor, (2) the checksum field might be incomplete - actually incorrect -
because traffic is received from another virtual machine that did offloading.
Because this is an in-memory communication, no corruption is assumed. We have
an equivalent flag for each received packet that is set by the virtual network
cards for such cases.

> 
> Also, development takes place on the master branch. The STABLE-2_1_x branch
only gets cherry-picked patches applied for a fast release.

I already assumed so, but I got confused by your contributing guide. The
following two points would have helped me as newcomer: (1) Tell that you need
a Savannah account for submitting. For me, Savannah looked in-active because
the patch submission button was crossed out. (2) Shortly describe the branch
layout for contributors as you just did to me. I also picked STABLE-2_1_x
because it is the one I could test the work. We have currently a number of
other dependencies in Unikraft to lwip that do not apply with the master
branch that we obviously need to fix.
I attached you a rebased version that applies to master.

(file #51977, file #51978, file #51979)
    _______________________________________________________

Additional Item Attachment:

File name: master-0001-pbuf-Introduce-PBUF_FLAG_CSUM_PARTIAL.patch Size:3 KB
   
<https://file.savannah.nongnu.org/file/master-0001-pbuf-Introduce-PBUF_FLAG_CSUM_PARTIAL.patch?file_id=51977>

File name: master-0002-inet_chksum-Partial-checksums.patch Size:6 KB
   
<https://file.savannah.nongnu.org/file/master-0002-inet_chksum-Partial-checksums.patch?file_id=51978>

File name: master-0003-tcp_out-Partial-checksumming.patch Size:6 KB
   
<https://file.savannah.nongnu.org/file/master-0003-tcp_out-Partial-checksumming.patch?file_id=51979>



    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/patch/?10111>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]