• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: ctl_enqueuedata() woes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ctl_enqueuedata() woes


  • Subject: Re: ctl_enqueuedata() woes
  • From: Brian Bergstrand <email@hidden>
  • Date: Wed, 3 Oct 2007 22:12:31 +0300


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.


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


  • Follow-Ups:
    • Re: ctl_enqueuedata() woes
      • From: Stephane Sudre <email@hidden>
References: 
 >ctl_enqueuedata() woes (From: "Karl Pickett" <email@hidden>)
 >Re: ctl_enqueuedata() woes (From: Brian Bergstrand <email@hidden>)
 >Re: ctl_enqueuedata() woes (From: Josh Graessley <email@hidden>)

  • Prev by Date: Re: ctl_enqueuedata() woes
  • Next by Date: Re: ctl_enqueuedata() woes
  • Previous by thread: Re: ctl_enqueuedata() woes
  • Next by thread: Re: ctl_enqueuedata() woes
  • Index(es):
    • Date
    • Thread