Re: [lwip-devel] HW checksum support and fragmented packets

[Ivan Delamer]

I think this is a good idea. Haven't worked with hardware CRC calculations
other than for Ethernet frames, so can't be of much help, but sounds like
a good approach.

Anyways, I need to take a look at pbufs again. There's been talk of and
some support for zero-copy netif drivers. I'll look into this in the near
future and while I'm poking in there will see if I can come up with
suggestions for CRC offloading. Seems like a good idea to make it generic
to fragmented/non-fragmented packets.

Cheers
Ivan


> Date: Wed, 18 Jul 2012 10:39:23 +0100
> From: "James G. Smith" <address@hidden>
> To: lwip-devel <address@hidden>
> Subject: [lwip-devel] HW checksum support and fragmented packets
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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