Hi All,
I just need few clarifications in the GRO code that is present
In the below code where the merge fails because the IP length is greater
than 65536 we do a insert_new_item but we send prev_idx rather than the
cur_idx. This would work for index 0 and 1 but when cur_idx is 1 and merge
fails, we would end up sending prev_idx which is 0 and the next_idx of 0
would be 2 rather than 1. We make sure that next_idx of items[2] would be 1
but stack would see re-ordered packets in the TCP stack. Functionally would
have zero impacts but if the thresholds of Dup ACKs are lesser we might see
un-necessary DUP ACKS. Is my understanding correct or am I missing
something? I did change to cur_idx and I did not see the reordering issue.
/*
* Check all packets in the flow and try to find a neighbor for
* the input packet.
*/
cur_idx = tbl->flows[i].start_index;
prev_idx = cur_idx;
do {
cmp = check_seq_option(&(tbl->items[cur_idx]), tcp_hdr,
sent_seq, ip_id, pkt->l4_len, tcp_dl, 0,
is_atomic);
if (cmp) {
if (merge_two_tcp4_packets(&(tbl->items[cur_idx]),
pkt, cmp, sent_seq, ip_id, 0))
return 1;
/*
* Fail to merge the two packets, as the packet
* length is greater than the max value. Store
* the packet into the flow.
*/
* if (insert_new_item(tbl, pkt, start_time, prev_idx,
sent_seq, ip_id, is_atomic) == INVALID_ARRAY_INDEX)*
return -1;
return 0;
}
prev_idx = cur_idx;
cur_idx = tbl->items[cur_idx].next_pkt_idx;
} while (cur_idx != INVALID_ARRAY_INDEX);
Thanks,
Param.
