net-test: packetdrill: tcpdump: reduce sleep #81
Conversation
|
Thanks. Should we also add the --packet-buffered flag for tcpdump? |
|
Adding author @wdebruij to the thread... |
|
Should it keep a 0.1s sleep to avoid a tight race between last packet and close? The proof is in the pudding. If there are no regressions in any of the (by now many) .pkt tests, sounds like a very nice speed-up indeed. |
As suggested by Davide, TCPDump's '--immediate-mode' will force the kernel to flush packets to userspace immediately after the reception. Thanks to that, the 'sleep 1' at the end of the test is no longer needed: the userspace will have all the packets when the kill signal will be received. Just to be on the safe side, we can keep a sleep 0.1, as recommended by Willem. It looks like this TCPDump option is usually not recommended but because there should not be too many packets generated here with Packetdrill, it seems fine to have it and saves 1 second for each test. Note that it is not an exotic option as it is used by default when packets are not written in a file. Also, we now use '--packet-buffered' to reduce IO. Now that the "immediate mode" is being used, it seems enough to just wait for the '.pcap' file to be created to know when TCPDump is ready. While at it, the directory where the capture will be store is created if it didn't exist. Suggested-by: Davide Caratti <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]>
matttbe
force-pushed
the
tcpdump-immediate
branch
2 times, most recently
from
ce6716c
to
74e1ded
Compare
|
Thank you both for the quick feedback!
@nealcardwell: Good idea!
@wdebruij: Good idea, just to be on the safe side.
That's quite hard to track down regressions. I ran 'tcp' tests and check the differences of size of the produced @nealcardwell @wdebruij: I just pushed a new version containing your two suggestions but also a way to reduce the sleep just after having started On my side, it seems to do the job well but I was able to do the tests only on one setup. I would be glad if someone else can try on their side, just to be on the safe side :) |
matttbe
changed the title
|
@nealcardwell : is there anything else I need to do for this PR? :) |
As suggested by Davide, TCPDump's '--immediate-mode' will force the kernel to flush packets to userspace immediately after the reception. Thanks to that, the 'sleep 1' at the end of the test is no longer needed: the userspace will have all the packets when the kill signal will be received. Just to be on the safe side, we can keep a sleep 0.1, as recommended by Willem.
It looks like this TCPDump option is usually not recommended but because there should not be too many packets generated here with Packetdrill, it seems fine to have it and saves 1 second for each test. Note that it is not an exotic option as it is used by default when packets are not written in a file. Also, we now use '--packet-buffered' to reduce IO.
Now that the "immediate mode" is being used, it seems enough to just wait for the '.pcap' file to be created to know when TCPDump is ready.
While at it, the directory where the capture will be store is created if it didn't exist.