Hello Sergey, Thanks for the feedback. > -----Original Message----- > From: Sergey Shtylyov <s.shtylyov@xxxxxx> > Sent: Thursday, January 25, 2024 7:11 PM > Subject: Re: [PATCH net-next v2 0/2] Add HW checksum offload support for > RZ/G2L GbEthernet IP > > Hello! > > On 1/24/24 1:21 PM, Biju Das wrote: > > > This patch series aims to add HW checksum offload supported by TOE > > module found on the RZ/G2L Gb ethernet IP. > > Your previous try was back in 2021, still the cover letter has the same > issues (hm, I didn't point out those back then). Thanks for correcting my bad English. > > > The TOE has hw support for calculating IP header and TCP/UDP/ICMP > > checksum for both IPV4 and IPV6. > > > > For Rx, the result of checksum calculation is attached to last 4byte > > of ethernet frames. > > "For Rx, the 4-byte result of checksum calculation is attached to the > Ethernet frames", you wanted to say? Ok. > > > First 2bytes is result of IPV4 header checksum and next 2 bytes is > > TCP/UDP/ICMP. > > TCP/UDP/ICMP checksum, you mean? Yes. > > > If frame does not have error "0000" attached to checksum calculation > > "If a frame does not have error, 0x0000 is attached as a checksum > calculation result", you wanted to say? > > > result. For unsupported frames "ffff" is attached to checksum > > calculation > > s/to/as/, again? OK. > > > result. Cases like IPV6, IPV4 header is always set to "FFFF". > > In case of an IPv6 packet, IPv4 checksum is always set to 0xFFFF", you > wanted to say? > > > For Tx, the result of checksum calculation is set to the checksum > > field of each IPv4 Header/TCP/UDP/ICMP of ethernet frames. For the > > unsupported frames, those fields are not changed. If a transmission > > frame is an UDP frame of IPv4 and its checksum value in the UDP header > > field is H'0000, > > I think you can call it just UDPv4... OK. > > > TOE does not calculate checksum for UDP part of this frame as it is > > optional function as per standards. > > > > Add Tx/Rx checksum offload supported by TOE for IPV4 and TCP/UDP > protocols. > > > > Results of iperf3 in Mbps > > > > RZ/V2L: > > TCP(Tx/Rx) results with checksum offload Enabled: {921,932} > > TCP(Tx/Rx) results with checksum offload Disabled: {867,612} > > > > UDP(Tx/Rx) results with checksum offload Enabled: {950,946} > > UDP(Tx/Rx) results with checksum offload Disabled: {952,920} > > > > RZ/G2L: > > TCP(Tx/Rx) results with checksum offload Enabled: {920,936} > > TCP(Tx/Rx) results with checksum offload Disabled: {871,626} > > > > UDP(Tx/Rx) results with checksum offload Enabled: {953,950} > > UDP(Tx/Rx) results with checksum offload Disabled: {954,920} > > > > RZ/G2LC: > > TCP(Tx/Rx) results with checksum offload Enabled: {927,936} > > TCP(Tx/Rx) results with checksum offload Disabled: {889,626} > > > > UDP(Tx/Rx) results with checksum offload Enabled: {950,946} > > UDP(Tx/Rx) results with checksum offload Disabled: {949,944} > > Too many figures, I think... :-) > How RZ/G2L SoC is different from RZ/G2LC? Just want to share with the wider community how the HW checksum is improving the performance of various SoCs in the RZ/G2L family. and the results show improved performance on all 3 SoCs. > > > v1->v2: > > * Updated covering letter and results > > * Fixed the sparse warnings for patch#1 by replacing __sum16->__wsum. > > > > Note: > > This patches are tested with [1] without the CPU performance is not > > good > > Without CPU? I guess the performance would be 0. Seriously, this is > hardly parseable... :-) without the patch [1] CPU performance is not good which impacts the network throughput. [1] https://lore.kernel.org/all/20240117190545.596057-1-vincent.guittot@xxxxxxxxxx/ Cheers, Biju