[dpdk-dev] GRO-Flow-Chaining

[dpdk-dev] GRO-Flow-Chaining

[kumaraparameshwaran rathinavel]

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.