Creation of explicit packet sets had both a packet set delay and a list loop
delay set leading to lower than configured rate at tx. Earlier implicit
packet set always had set delay as 0 and only list loop delay was used.
Fix is to always set list loop delay to 0 in sequential mode as packet set
will have the correct delay set due to explicit packet sets.
Tx/Rx stream stats related threads no longer have a direct reference to the
port's stream stats - instead they have their own copy that they keep and
return (in a reset-on-read fashion) when asked for. Each copy also has it's
own lock to prevent contention for read/update/clear.
PcapPort now fetches Tx(Transmitter) and Rx(Poller) stats on demand and
updates the port's stream stats - under protection of a lock.
We are not rewriting L4Cksum for ttag packets at the moment. See
comment in packetsequence.h
Commenting out this code doesn't seem to observably improve tx
performance though.
The latency code seems to reduce stream stats max tx performance
by around 3 to 5%. Recovering this may be done separately as part
of overall performance optimzation of Tx code.
There are 2 changes -
1. Encode txPort in ttag packets and use it at TxTtagStats and
RxPcapStats to identify Tx and Rx packets respectively
2. Don't use pcap_sendqueue_transmit() if stream timing is in use -
since we can't modify TTAG packets inside that API
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
