Add support for computing IP, TCP, UDP checksums in hardware

[zephyrbot]

Reported by Piotr Mienkowski:

Modern Ethernet modules in most of the SoC devices/Ethernet cards have ability to generate IP, TCP and UDP checksums in hardware.

Add support in the networking stack for computing IP, TCP, UDP checksums in hardware.

(Imported from Jira ZEP-1520)

[zephyrbot]

by Andrei Laperie:

Tomasz, could you please have a look at this one?

[zephyrbot]

by Tomasz Bursztyka:

crc.h made it into Zephyr recently, with a simple software implementation. So now it's all about enabling any hw available around.

[zephyrbot]

by Tomasz Bursztyka:

Let's close this.

hw network checksum acceleration is usually made either with contiguous network frame, in the device's memory, or through DMA.

DMA: not possible at the moment in Zephyr (not much dma controller supported and the API is not ready for this)
In the device driver: sounds possible if only the device has enough memory to hold one packet in its memory.

All in all it's a local optimization, not at all a priority, moreover on Ethernet which is really not the bearer of choice in Zephyr.

We might come back to this in some future.

[zephyrbot]

by Piotr Mienkowski:

I believe we shouldn't close this ticket as the issue is not resolved and should not be forgotten. We can change its priority to low if there are other more important topics to work on at the moment. However, it's one of the points which should not be overlooked when re-working networking stack.

Currently at least Atmel SAM Ethernet driver is ready to support checksum generation in hardware. Other existing Ethernet drivers may not have the software support yet, but their hardware does provide the feature.

[zephyrbot]

by Tomasz Bursztyka:

Piotr Mienkowski It's not ready at all to support this anywhere. The problem is the whole integration within the net stack, this one currently computes the checksum no matter what. On rx or tx.

On Tx, what will be required is a way for the L3 part of net stack to know whether or not the current iface it is working against supports hw checksum. If yes, it would skip calculating it. If not, it would do as usual. Then, up to the device driver to do whatever it takes to use the necessary hw capabilities. Hopefully, the pkt metadata are available on tx, so it's possible for the driver to let the hw knows about protocol place in the buffer, etc...

On Rx, looks like much trickier, unless the chip is smart enough to do all by itself.

As I said, Ethernet is really not the most prioritized bearer in Zephyr. To me, this sounds like feature n°4578154 but we are at feature n°245.

Let's not close it if you want, but I'll downgrade the priority anyway.

[zephyrbot]

by Piotr Mienkowski:

{quote}
It's not ready at all to support this anywhere. The problem is the whole integration within the net stack, this one currently computes the checksum no matter what. On rx or tx.
{quote}

I was talking specifically about Atmel SAM Ethernet driver and other Ethernet device drivers. It's clear that the networking stack does not support computing checksums in hardware. That's why we have this Jira issue.

All it takes to enable computing checksum in hardware for Atmel SAM Ethernet driver is flipping one bit in the configuration register during the driver initialization phase. This has been tested and is working. With hardware support enabled networking stack can send a bogus checksum yet the Ethernet module will transmit a correctly formatted frame on the cable. For RX direction checksum validation is already enabled. All invalid frames are rejected. Only those with a valid checksum are passed onto the stack.

Implementing feature like this can be cheap or expensive depending on the system architecture. Since networking stack is still being actively worked on it's good to keep requirements like this one in mind when re-working the stack. This will ensure that when the time to implement the feature finally comes it will be easy to do.

[zephyrbot]

by Piotr Mienkowski:

I'm changing the status to "To Do" since we agreed that the feature should be implemented.

[laperie]

We would like to add support for the TX checksum hardware offload in the following way:

1. Check if given adapter supports HW checksums and
2. Do not calculate the checksum for IP, TCP and UDP and put zero in the field instead if it does