site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com How are you calling ctl_enqueuedata() -- i.e. what are its parameters? Adi On Oct 3, 2007, at 9:26 AM, Karl Pickett wrote: An example where I bumped the rcv_buff up to 60000: _______________________________________________ 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/adi%40apple.com _______________________________________________ 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... This email sent to site_archiver@lists.apple.com 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! Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 35: ret 0, space=60000 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 36: ret 0, space=57924 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 37: ret 0, space=55848 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 38: ret 0, space=53772 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 39: ret 0, space=51696 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 40: ret 0, space=49620 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 41: ret 0, space=47544 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 42: ret 0, space=60000 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. -- Karl Pickett "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin This email sent to adi@apple.com smime.p7s