Comment 29 for bug 1579828

Reviewed: https://review.opencontrail.org/20283
Committed: http://github.org/Juniper/contrail-vrouter/commit/cab4c7c4a3a060c93902e4de0f84d470eb4d3146
Submitter: Zuul
Branch: R3.0

commit cab4c7c4a3a060c93902e4de0f84d470eb4d3146
Author: Anand H. Krishnan <email address hidden>
Date: Tue May 17 12:47:20 2016 +0530

Out Of Order Fragment handling fixes

. If any fragment other than the HEAD comes to the assembler, then
it means that datapath was not able to find the flow information
for that fragment, since HEAD had not yet passed through it. Hence,
there is an explicit assumption in the assembler that HEAD will
always come later than at least one fragment. Once the HEAD arrives,
the assembler will look for all the fragments of that packet and
flush the fragments.

Since the assembler is an asynchronous entity with respect to the
datapath, it is possible that by the time it gets the event and
processes the input fragments, HEAD also would have arrived, and
possibly in a different CPU than the other fragments. If the HEAD
then is processed first, the assembler will not find any fragments
that will need the information that is supplied by the HEAD and hence
the fragments that arrived in the system before the HEAD will stay in
the assembler queue till they get timed out.

. Because of the asynchronous nature of the assembler, the IP header
of the cloned HEAD is not a safe access, since the original packet
might have undergone NATing, resulting in wrong IPs being used for
selecting the queues to search for fragments. Hence, store the IPs
in the packet node along with the fragment information so that
assembler will make the right calculations.

. Initialize the packet node flags field to zero. Uninitialized pnode
flags resulted in the label being treated as a VNID and hence an unset
packet nexthop and thus a wrong key nexthop in the flow key, resulting
in HOLD flows.

Change-Id: I5d2c5abcda9c612c9d13378c79ae5d8392fd2c7b
Closes-BUG: #1579828