Most likely your driver is not advertising the HW checksum capability of
your driver to the gld framework. There is a following check before
checking the HCK_FULLCKSUM_OK flag.
/*
* Revert to software checksum calculation if the interface
* isn't capable of checksum offload.
* We clear DB_CKSUMFLAGS when going through IPsec in ip_fanout.
* Note: IRAF_NO_HW_CKSUM is not currently used.
*/
ASSERT(!IS_IPMP(ill));
if ((iraflags & IRAF_NO_HW_CKSUM) || !ILL_HCKSUM_CAPABLE(ill) ||
!dohwcksum) {
return (ip_input_sw_cksum_v4(mp, ipha, ira));
}
#define ILL_CAPAB_HCKSUM 0x08 /* Hardware checksumming */
#define ILL_HCKSUM_CAPABLE(ill) \
(((ill)->ill_capabilities & ILL_CAPAB_HCKSUM) != 0)
If you run into any issue just contact me directly and I can work with
you to resolve the issues as I am interested in knowing what benefit[s]
are you seeing with LRO.
Rao.
Tom Chen wrote:
Hello,
I am implementing LRO on a 10G nic. I encountered a lot of "packet out of
order" issues.
Here is how I process LRO rx interrupt which follows our Linux driver:
1. From rx descriptors, we know how many extra bytes appended behind the
current tcp packet and the last appended packet's sequence number.
2. Read the tcp packet and extended payload
3. Modify the IP header's total_length field to reflect those extra payloads
4. Since IP header has been changed, calculate new IP checksum and update it in
IP header
5. Update TCP header sequence field with new sequence number
6. Indicate to the OS that this LRO packet has good checksum by "mac_hcksum_set(mp,
0, 0, 0, 0, HCK_FULLCKSUM_OK);"
7. send to OS.
However, it looks like the packet is rejected by OS and netstat shows large number of
"tcpInErrs". I am not sure how does the OS know that the packet is corrupted?
Probably I changed tcp header's sequence number but did not re-calculate the TCP
checksum? I did not do because it is too time-consuming. Does the OS redo whole TCP
segments' checksum and verify even if the packet has HCK_FULLCKSUM_OK flag set?
Tom
bash-3.00# netstat -P ip -s
IPv4 ipForwarding = 2 ipDefaultTTL = 255
ipInReceives = 40475 ipInHdrErrors = 0
ipInAddrErrors = 0 ipInCksumErrs = 0
ipForwDatagrams = 0 ipForwProhibits = 0
ipInUnknownProtos = 145 ipInDiscards = 0
ipInDelivers = 25973 ipOutRequests = 26692
ipOutDiscards = 3 ipOutNoRoutes = 0
ipReasmTimeout = 60 ipReasmReqds = 0
ipReasmOKs = 0 ipReasmFails = 0
ipReasmDuplicates = 0 ipReasmPartDups = 0
ipFragOKs = 0 ipFragFails = 0
ipFragCreates = 0 ipRoutingDiscards = 0
tcpInErrs = 939 udpNoPorts = 13596
udpInCksumErrs = 0 udpInOverflows = 0
rawipInOverflows = 0 ipsecInSucceeded = 0
ipsecInFailed = 0 ipInIPv6 = 0
ipOutIPv6 = 0 ipOutSwitchIPv6 = 0
bash-3.00# netstat -P tcp -s
TCP tcpRtoAlgorithm = 4 tcpRtoMin = 400
tcpRtoMax = 60000 tcpMaxConn = -1
tcpActiveOpens = 16 tcpPassiveOpens = 9
tcpAttemptFails = 11 tcpEstabResets = 2
tcpCurrEstab = 1 tcpOutSegs = 24827
tcpOutDataSegs = 16437 tcpOutDataBytes =4305745
tcpRetransSegs = 1 tcpRetransBytes = 104
tcpOutAck = 8391 tcpOutAckDelayed = 234
tcpOutUrg = 1 tcpOutWinUpdate = 2
tcpOutWinProbe = 0 tcpOutControl = 50
tcpOutRsts = 14 tcpOutFastRetrans = 0
tcpInSegs = 23588
tcpInAckSegs = 8560 tcpInAckBytes =4305697
tcpInDupAck = 23 tcpInAckUnsent = 0
tcpInInorderSegs = 10394 tcpInInorderBytes =13383822
tcpInUnorderSegs = 3190 tcpInUnorderBytes =4210540
tcpInDupSegs = 40 tcpInDupBytes = 39460
tcpInPartDupSegs = 12 tcpInPartDupBytes = 10224
tcpInPastWinSegs = 0 tcpInPastWinBytes = 0
tcpInWinProbe = 0 tcpInWinUpdate = 0
tcpInClosed = 2 tcpRttNoUpdate = 2
tcpRttUpdate = 8548 tcpTimRetrans = 1
tcpTimRetransDrop = 0 tcpTimKeepalive = 10
tcpTimKeepaliveProbe= 0 tcpTimKeepaliveDrop = 0
tcpListenDrop = 0 tcpListenDropQ0 = 0
tcpHalfOpenDrop = 0 tcpOutSackRetrans = 0
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
