Re: ctl_enqueuedata() woes
Re: ctl_enqueuedata() woes
- Subject: Re: ctl_enqueuedata() woes
- From: Brian Bergstrand <email@hidden>
- Date: Wed, 3 Oct 2007 19:55:00 +0300
On Oct 3, 2007, at 7:26 PM, Karl Pickett wrote:
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(...);
HTH.
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden