Re: ctl_enqueuedata() woes
Re: ctl_enqueuedata() woes
- Subject: Re: ctl_enqueuedata() woes
- From: Stephane Sudre <email@hidden>
- Date: Thu, 4 Oct 2007 16:56:01 +0200
On 3 oct. 07, at 21:12, Brian Bergstrand wrote:
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:
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.
IIRC, the tcpkernellogsomething example queues the data until it can
send it later. This can be a solution if the data to queue is not too
big (size or instances) and you don't need to receive the data as soon
as it's made available (and you can be sure that there will be a call
to ctl_enqueuedata after you've queued the data.
_______________________________________________
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