All .pro file changes only
libostfile still has GUI dependency due to PCAP import options UI.
Need to see if we can remove that - maybe extract into a separate
libostfilegui.
This was a regression introduced in 1.3.0 as part of the port stats UX
improvement. The 'user' row was changed from the first (0) to the last,
but the proxy model continued to use a hard-coded value of 0 to check
for user to determine whether to show a port column or not.
The delegate was still rendering display text. But we didn't realize
because the only place where this delegate was used was returning a
QVariant() for DisplayText role earlier. Once we started returning a
valid QString (for copy-paste purposes), this bug showed up.
This didn't work because we further delegate the actual painting to
the base QStyledItemDelegate which re-initializes option.features
from the item index values, so removing HasDisplay does not work.
The fix is to override the displayText() to return a null string.
libpcap has a bug on Linux which leads to incorrect BPF generation for our
capture filter. This commit changes the filter expression on Linux such that
correct BPF is generated.
Fixes#354
* Resize columns to content (instead of using default width)
* Use Kpps/Mpps for Pkt Rate with 3 decimal
* Use 3 decimal places for bit-rates (is more logical because units change
every 1000 anyway)
* Use 2 decimal places for time interval
This just improves the chances of all columns fitting - but is not guaranteed
AbstractPort uses a value of UINT_MAX to signify 'all guids', but
StreamTiming uses 'invalid guid' value which are NOT the same value. But
UINT_MAX is guaranteed to be greater than invalid GUID - so instead of
equality we check for greater than comparison.
Since we now create an explicit packet set even for interleaved mode, we can
calculate and use the packet set delay instead of using the list loop delay.
With this change both sequential and interleaved mode do not use list loop
delay at all, but we still retain the code for that - in case we need to use
it later for some reason.
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.
Crash was due to loopDelay being 0 in case of topSpeed. For ttags, we
recalculatue loopDelay based on max line rate and avg pkt size.
The problem doesn't exist in interleaved mode because minGap and duration
are non-zero in the top speed tx case.
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.
The interleaved mode's single packet set MUST always have 0 delay
for accurate rate.
Before latency code, the interleaved packet set was added implicitly
and had 0 delay. Latency code added explicit packet set and used
avgDelay for the set. The avgDelay was needed for the original algo
used to determine when to send ttag packets. That algo is no longer
used (ttag markers are now explicitly configured by AbstractPort).
Turbo still needs avgDelay for other use, but changes will be made in
Turbo code for that.
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
In a previous commit, we start/stop these timers based on number of
ports tracking stream stats triggered by RPCs. However, timers cannot
be triggered across threads (RPC thread and main thread in this case).
This fix uses a queued connection to post it to the other queue.
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 stream timingHash is read by getStreamStats() while it is read/write
for processRecords(), the latter is a more frequent operation so there's
no real benefit of using a read-write lock instead of simple mutex.
