In checksum module, IPv4 checksum, TCP checksum, and UDP checksum are calculated for the eligible packets. The calculated value is compared with the checksum values received along with the packets. Based on the comparison, each packet is marked as a valid packet or error packet.
When the RX offload feature is CSO only, the packet status is updated in the status field and sent over through the S2MM status stream to the MCDMA along with packet data with a TDEST value of 0. The entire packet is sent as a single transaction on AXI4-Stream with both the EOF and SOF flag set in APP1 status fields.
When the RX offload feature is GRO + CSO, the header is parsed in the checksum offload module. Based on the values of the IP addresses, port addresses, and protocol, the packet is classified as GRO data or non-GRO data. The IP addresses and source port destination port are programmed for each GRO port. At least one of the parameters should be different for each of the GRO header fields. If the header matches with any of the GRO port parameters, the packet is sent to the corresponding GRO module. TDEST values of 1 to 15 of AXI4-Stream output define each GRO port. The number of ports of GRO can be from 1 to 15. The MCDMA must be configured with the number of channels as one greater than the number of GRO ports programmed in the Ethernet Offload Engine IP. All the other packets, which do not belong to any of the GRO ports, go to the non-GRO module sent out as a non-GRO packet with TDEST 0.
When the first GRO packet is detected and assigned to a corresponding port, the header and data of the packet are separated. The header alone is sent out with the corresponding TDEST value, and the SOF bit is set in the APP0 field of the status stream. The data is saved in the internal buffer. When the next GRO packet of the same port is received, the header is chopped, and the data is accumulated to the previous payload data in the internal buffer. When the internal buffer reaches the fragment size programmed in the registers and configured through the IP GUI (2K bytes or 4K bytes), the fragment is sent out with fragment number as 1 and the SOF and EOF bit as 0. The fragment length is updated in the status stream with each fragment being sent. The extra data, which is saved after the fragment size, is still saved in the internal buffer and waits for the next GRO packet. When a total of 8 or 16 (default) fragments are received, the last fragment is sent on the stream with the EOF as 1, the SOF as 0, and the corresponding fragment number. When the EOF is 1, the total length accumulated so far and the checksum value of the IPv4 header with the new total length, including the header and all the fragments until the EOF, are sent over the status stream. The GRO packet accumulation is terminated in any of the following cases:
- When the (number of fragments * fragment size) value is reached for the accumulated packet (maximum 64K bytes)
- When an error packet is received with the same header
- When the length of packet is less than the previous accumulated packets
- When the timeout occurs after receiving the last GRO packet on that port
The following figure illustrates how non-GRO packets are handled.
The complete packet from SOF to EOF is reconstructed in the AXI MCDMA IP through BDs. The checksum value and total length field updated in the last fragment with EOF are used to replace the fields in header fragment.
While comparing the GRO headers, the IP compares the following fields to decide the port of the GRO:
- Protocol
- Source port
- Destination port
- Source IP Address
- Destination IP Address
When the 3 tuple algorithm is selected, only the Destination IP Address, Destination port, and Protocol fields are compared for port mapping.
When the 5 tuple algorithm is selected, all the five fields mentioned above are compared for port mapping. Make sure different sets of header fields are configured for the different ports.