site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Oct 3, 2007, at 7:58 PM, Josh Graessley wrote: On Oct 3, 2007, at 9:55 AM, Brian Bergstrand wrote: On Oct 3, 2007, at 7:26 PM, Karl Pickett wrote: Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 _______________________________________________ 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! ut 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. -josh Well, for me, this code is in a separate thread not involved in the network stack. But if we aren't supposed to do this in a network callback (which again, I'm not doing) what are we supposed to do? As Karl pointed out, ctl_enquedata doesn't handle this case itself, so we have to. This email sent to site_archiver@lists.apple.com
participants (1)
-
Brian Bergstrand