site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Oct 3, 2007, at 9:55 AM, Brian Bergstrand wrote: On Oct 3, 2007, at 7:26 PM, Karl Pickett wrote: -josh _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... I have modified the tcplognke example and it was pleasant sailing until now. I am sending packets to userspace that are about 2020 bytes long. Userspace reads each packet and responds with a setsockopt() call with a 2k structure. When a burst of packets gets sent, some packets will fail to be received by user space but no error was indicated from ctl_enqueuedata() Calling ctl_getenqueuespace(), the packets end up disappearing when ever the queuespace is not the maximum. Bumping up the socket recvbuf from 8k to 60k did not help one bit! [snip] Only packets 35 and 42 were received by userspace! The rest went to a bit bucket somewhere, and as you can see the ret 0 indicates no error by ctl_enqueuedata. In some cases when the space was completely exhausted ctl_enqueuedata would return an error, but otherwise the packets would just disappear when ever the enqueuespace was not at max. This is how control sockets work. Here's a way to get around the problem (if you can gracefully sleep that is): int retry = 3; retry_data: size_t recvsz = 0; if (0 == ctl_getenqueuespace(ctl_ref, ctlunit, &recvsz) && recvsz < datasize && retry > 0) { // msg q is full // Sleep one quantum giving the client a chance to wake struct timespec ts = {0, 10000000}; (void)msleep(NULL, NULL, PSOCK, __FUNCTION__, &ts); retry--; goto retry_data; } err = ctl_enqueuedata(...); Please don't do this. If you're running on the input thread you're going to hurt network performance. This email sent to site_archiver@lists.apple.com