Hello,
We are using e810 NICs in our work and mostly they are used to pass
through network traffic using QinQ.
We have noticed that when we receive TCP packets with the wrong
checksum from the internet, on
the receiving node it goes through, NIC compares the checksum, lets packet
further and increases the kernel counter for RX ERR. It doesn't make sense
as nothing can be done with such packets.
During the debugging process we found a place in code where it is not working
correctly, we think it goes straight to checksum_fail.
´´´
if (ipv4 && (rx_status0 & (BIT(ICE_RX_FLEX_DESC_STATUS0_XSUM_IPE_S))))
goto checksum_fail;
if (ipv6 && (rx_status0 & (BIT(ICE_RX_FLEX_DESC_STATUS0_IPV6EXADD_S))))
goto checksum_fail;
/* check for L4 errors and handle packets that were not able to be
* checksummed due to arrival speed
*/
if (rx_status0 & BIT(ICE_RX_FLEX_DESC_STATUS0_XSUM_L4E_S))
goto checksum_fail;
/* check for outer UDP checksum error in tunneled packets */
if ((rx_status1 & BIT(ICE_RX_FLEX_DESC_STATUS1_NAT_S)) &&
(rx_status0 & BIT(ICE_RX_FLEX_DESC_STATUS0_XSUM_EUDPE_S)))
goto checksum_fail;
´´´
instead of going to next session where the checksum for tunneled packets
are unnecessary and shouldn't increase counter
´´´
/* Only report checksum unnecessary for TCP, UDP, or SCTP */
switch (decoded.inner_prot) {
case ICE_RX_PTYPE_INNER_PROT_TCP:
case ICE_RX_PTYPE_INNER_PROT_UDP:
case ICE_RX_PTYPE_INNER_PROT_SCTP:
skb->ip_summed = CHECKSUM_UNNECESSARY;
´´´
The one way to deal with it is to disable rx checksumming in ethtool,
but we don't want to lose the monitoring for "normal" L2 packets.
Here is the example of such packet, the only difference the src and dst
IPs and checksum
Here are some examples for such packets:
Frame 2088: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Encapsulation type: Ethernet (1)
UTC Arrival Time: May 13, 2024 13:12:17.815209000 UTC
[Time shift for this packet: 0.000000000 seconds]
[Time delta from previous captured frame: 0.054763000 seconds]
[Time delta from previous displayed frame: 3.864796000 seconds]
[Time since reference or first frame: 5.132255000 seconds]
Frame Number: 2088
Frame Length: 70 bytes (560 bits)
Capture Length: 70 bytes (560 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:vlan:ethertype:ip:tcp]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String [truncated]: eth.fcs.status=="Bad"
ip.checksum.status=="Bad" tcp.checksum.status=="Bad"
udp.checksum.status=="Bad" sctp.checksum.status=="Bad"
mstp.checksum.status=="Bad" cdp.checksum.status=="Bad" ||]
Ethernet II, Src: , Dst:
Destination:
Source:
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 258
000. .... .... .... = Priority: Best Effort (default) (0)
...0 .... .... .... = DEI: Ineligible
.... 0001 0000 0010 = ID: 258
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: , Dst:
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 52
Identification: 0x1763 (5987)
000. .... = Flags: 0x0
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 119
Protocol: TCP (6)
Header Checksum: 0x42c9 [correct]
[Header checksum status: Good]
[Calculated Checksum: 0x42c9]
Source Address:
Destination Address:
Transmission Control Protocol, Src Port: 64455, Dst Port: 22, Seq: 0, Len: 0
Source Port: 64455
Destination Port: 22
[Stream index: 2]
[Conversation completeness: Incomplete, SYN_SENT (1)]
[TCP Segment Len: 0]
Sequence Number: 0 (relative sequence number)
Sequence Number (raw): 4100199712
[Next Sequence Number: 1 (relative sequence number)]
Acknowledgment Number: 0
Acknowledgment number (raw): 0
1000 .... = Header Length: 32 bytes (8)
Flags: 0x002 (SYN)
Window: 64240
[Calculated window size: 64240]
Checksum: 0x9bb8 incorrect, should be 0x8524(maybe caused by "TCP
checksum offload"?)
[Expert Info (Error/Checksum): Bad checksum [should be 0x8524]]
[Bad checksum [should be 0x8524]]
[Severity level: Error]
[Group: Checksum]
[Calculated Checksum: 0x8524]
[Checksum Status: Bad]
Urgent Pointer: 0
Options: (12 bytes), Maximum segment size, No-Operation (NOP),
Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
TCP Option - Maximum segment size: 1460 bytes
TCP Option - No-Operation (NOP)
TCP Option - Window scale: 8 (multiply by 256)
TCP Option - No-Operation (NOP)
TCP Option - No-Operation (NOP)
TCP Option - SACK permitted
[Timestamps]
[Time since first frame in this TCP stream: 0.000000000 seconds]
[Time since previous frame in this TCP stream: 0.000000000
seconds]
Looking forward to your reply on that matter
--
Mit freundlichen Grüßen
Alexander Kokorin
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit
https://community.intel.com/t5/Ethernet-Products/bd-p/ethernet-products
