If and when we remove PacketSequence::ttagL4ChecksumOffset we will take a call
if we should revert back to passing seq->sendQueue instead of seq at that time
The algo works for the following cases of interleaved streams -
* pktListDuration < ttagTimeInterval
* pktListDuration > ttagTimeInterval
* some streams have Ttag, some don't
- first stream has Ttag
- first stream does NOT have Ttag
* no streams have Ttag
Changes for sequential mode are pending
As part of Turbo changes, we made changes to create explicit packet
sets, but for the base code we continued creating implicit packet
sets for some cases. With this change we don't create any implicit
packet set.
This change needs to be tested thoroughly for multiple cases.
The problem happens for bidirectional flows. The sequence of events is
as follows when you start Tx on Ports p1, p2 with the current code -
1. Clear stream stats on p1
2. Start tx on p1
3. Clear stream stats on p2
4. Start tx on p2
By the time #3 is executed, it may have already rx packets from p1 which
are being incorrectly cleared, this will cause these number of packets
to show up as dropped instead - incorrectly.
The fix is to change the order like this -
1. Clear stream stats on p1
2. Clear stream stats on p2
3. Start tx on p1
4. Start tx on p2
Unidirectional flows will not see this problem - as long as startTx is
done only on the Tx port and not the Rx port.
This bug is a regression caused due to the code changes introduced for the
stream stats rates feature implemented in 1.2.0
