Differential D16046
Add UDP receive probes Authored by tuexen on Jun 28 2018, 2:28 PM. Tags None Referenced Files
Details When a UDP packet is received and there is no endpoint to consume it, no UDP receive probe is fired. This is fixed by this patch. The corresponding dtrace test has been updated to verify this. When a UDP/IPv4 packet is received and the TTL is smaller than the minimum TTL required by the endpoint, no UDP receive probe is fired. This is different from the TCP/IPv4 case. To improve consistency, fix this also by this patch. Use the attached dtrace script udpio.d from the udp_dtrace man page and use nc -u 127.0.0.1 1234 and nc -u ::1 1234 to generate UDP packets assuming there is not endpoint on port 1234. The dtrace script should show the packets as sent and received.
Diff Detail
Event TimelineComment Actions It would be nice to add a test for this to cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/ip, but I don't think that should block the commit of this change. I'm happy to help with that if needed. Comment Actions Thanks for pointing me to the tests. I wasn't aware of them. Is there any documentation available how to run and/or write them? Adding tests makes sense since I'm also adding some probes to TCP and finally will add support for SCTP and UDPLite for which Comment Actions For the time being you need to set WITH_DTRACE_TESTS=YES in src.conf. Then, they get built and installed from cddl/usr.sbin/dtrace/tests. After adding tests, you need to run cddl/usr.sbin/dtrace/tests/tools/genmakefiles.sh to update the makefiles. The tests can be run using kyua. They get installed to /usr/tests/cddl/usr.sbin/dtrace/tests. Most of them depend on the shells/pdksh port. Comment Actions As root (required for dtrace), just run "kyua test" in the subdirectory containing the tests you wish to run. To run all dtrace tests, run it from /usr/tests/cddl/usr.sbin/dtrace. Comment Actions Update dtrace test for UDP to reflect this change. In particular, the reception of the UDP packet should be counted. Comment Actions This looks ok to me. It would be nice to amend the udp dtrace man page to state under what conditions the receive probe may fire, but I think that can be done as a separate revision. Comment Actions @markj I'll commit the changes to the dtrace scripts separately from the changes to the UDP source code. Should the change of the man page go with the first commit, with the second commit or be in a third commit? Comment Actions I think the man page change and kernel change can be committed together. Thanks!
Comment Actions If it's OK, I'd like to run some tests with dwatch to make sure that I don't need to patch my code for any change in functionality. I don't suspect this to be the case, but just want to make sure. If you're fine to wait another day or two for my testing, I'll definitely stamp approval Comment Actions Not yet. Working on it today. It's not just a 30-second test considering I have to recompile the kernel in the middle of the A/B test. Comment Actions I have used both your attached udpio.d (taken from dtrace_udp(4) in the EXAMPLES section) as well as: dwatch -X udp in the base system to confirm the pre-patch state. A probe fires when nc in the given test case of: nc -u 127.0.0.1 1234 sends the datagram but no probe fires for the receive. Going further, I compared UDP to TCP. The command: dwatch -t 'this->lport==1234 || this->rport==1234' -FX tcp tcp:::send,tcp:::receive combined with the test: nc 127.0.0.1 1234 shows that the TCP receive probe fires in the context of the kernel interrupt thread (intr, commonly pid 12). After patch, I will expect dwatch to catch intr processing the datagram. Now I have to recompile my kernel for the next test.
Comment Actions Aside from testing with what comes with FreeBSD base, I also wanted to make sure that this change would be handled well by my DTrace network visualizer (sysutils/dwatch-gource in ports). dteske@vm11 ~ $ dwatch -t 'this->family=="udp"' -X gource-net-raw INFO Sourcing gource-net-raw profile [found in /usr/local/libexec/dwatch] INFO Watching 'tcp:::debug-user, tcp:::state-change, udp:::send, fbt::soreceive_dgram:entry' ... INFO Setting test: this->family=="udp" 2018 Jul 17 09:02:24 1001.1001 nc[98845]: 1531843344 udp 127.0.0.1:62235 SEND 127.0.0.1:1234 12 bytes Here, I expect that after the patch I will still not see the RECV (desired) because it is not processed by an application (my network visualizer wants to know the application that is receiving the datagram and since udp:::receive only fires in the context of execname == "intr", the gource-net-raw profile instsead watches fbt::soreceive_dgram:entry with a predicate that indicates it is talking to the same socket). | ||||||||||||||||||||||||||||||||||||||||||||||||||||