lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] HW checksum support and fragmented packets


From: James G. Smith
Subject: [lwip-devel] HW checksum support and fragmented packets
Date: Wed, 18 Jul 2012 10:39:23 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16

A lot of ethernet hardware implementations now support the ability for
verifying received packet checksums, or generating transmit checksums,
and lwIP currently has the "all-or-nothing" support for
enabling/disabling the various CHECKSUM_GEN_* and CHECKSUM_CHECK_* options.

However at the moment if IP_REASSEMBLY or LWIP_IPV6_REASS are defined to
provide support for fragmented packet re-assembly BUT the corresponding
CHECKSUM_CHECK_TCP option is disabled due to wanting to make use of
hardware driver checksum support there is (for obvious reasons) the
window for fragmented packets to not be verified.

Would there be an objection to a 3rd approach being configurable where
the hardware driver would mark packets passed into lwIP as
checked/unchecked as regards the TCP checksum (so, for example,
requiring a new "pbuf->flags" bitmask (0x40U or 0x80U) manifest), and
the "tcp_input()" code would have something like (just written here so
never seen a compiler :-)

  #if CHECKSUM_CHECK_TCP || CHECKSUM_CHECK_TCP_FLAG
  # if CHECKSUM_CHECK_TCP_FLAG
    if (!(p->flags & PBUF_FLAG_CSUM))
  # endif /* CHECKSUM_CHECK_TCP_FLAG */
    {
      /* Verify TCP checksum. */
      ...
    }
  #endif /* CHECKSUM_CHECK_TCP || CHECKSUM_CHECK_TCP_FLAG */

The polarity of the new pbuf flag can be whatever is decided for minimal
impact on the existing source, and of-course there will be some magic
needed in the source to maintain the flag over re-assembly to allow
"tcp_input()" to make use of it.

However it would at least allow lwIP to be configured to off-load most
checksum calculations to the hardware, and for the IP fragmentation case
where hardware would not necessarily be able to validate the checksum to
keep the software verification.

For those configurations with CHECKSUM_CHECK_TCP disabled and that do
not care about fragmented packets not being verified then
CHECKSUM_CHECK_TCP_FLAG does not need to be defined and there is no hit.
However if a configuration does want soft-checksum verification for
fragmented packets then they can only suffer the performance cost of the
conditional flag check which for non-fragmented packets will indicate
the HW having verified the checksum and the soft checksum not being
executed.

What do people think?

In reality the new pbuf flag does not need to be specific to the TCP
checksum case; but could be a general indicator of whether the hardware
has verified a checksum on reception OR as a flag passed with transmit
packets to indicate to the hardware whether a checksum has already been
calculated (for those cases where a pre-calculated checksum is being
used, etc.). However such a generic approach would really need an extra
flag to mark the IPv4 header checksum CHECK/GEN requirement as being
distinct from the TCP, UDP, ICMPv6 payload checksums. This would eat up
the last two available PBUF_FLAG_ bits though.

-- Jamie



reply via email to

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