Re: msleep() in NKE?
Re: msleep() in NKE?
- Subject: Re: msleep() in NKE?
- From: Frank Thomas <email@hidden>
- Date: Thu, 28 Jul 2005 21:37:59 -0400
Josh, thanks the input.
I will put together a blank NKE that is just removing and re-injecting
packets tomorrow and see how the speed is. We had previously done
this by short-cutting the the evaluation process. But I will start
with a fresh IP Filter to ensure it is not me. My machine is running
10.4.2 but I'm not sure my fellow developers all are, so we will check
that too.
I will post back to the list once I have a chance to do more testing.
- Frank
On 7/28/05, Josh Graessley <email@hidden> wrote:
>
> Hello Frank,
>
> Allan is correct. You should not block the process for a long period
> of time. You should instead queue the packet and return EJUSTRETURN.
> When your process decides that it's ok to allow the packet, you can
> then inject the packet.
>
> You should not be seeing really long delays unless your process is
> taking a really long time to inject the packets.
>
> There is a slim chance that you might be running in to a problem that
> was fixed in 10.4.2, but that should only affect inbound traffic not
> outbound traffic. You really don't want to block the input thread
> while waiting on something else to get back to you. That will lead to
> deadlocks.
>
> -josh
>
> > Allan,
> >
> > Thanks for your response, we half expected to get this as our first
> > response. We actually had tried this...it was done before the sleep.
> > But we found it added a significant latency to the connection.
> >
> > We were doing almost exactly what you indicated. Take an HTTP stream
> > for example. Say we removed the "GET" packet from the stream. This
> > would hold the browser. We would do our user space stuff and send it
> > back down to demon on the sys_prot socket. When the request was
> > recv'd at the kernel we would re_inject the approiate packet.
> > However, it would add about a second delay to the request. For each
> > request including all images on the page etc this would really add up
> > to a very noticable delay. We felt like we were back on dialup.
> >
> > Have you seen anythhing like that? While the sleep might not be the
> > best way to handle the delay it gave us a noticable boost is speed for
> > the most part, only on occasion where we have to prompt userland do we
> > have a problem becuase the delay could be pretty long.
> >
> > - Frank
> > _______________________________________________
> > Do not post admin requests to the list. They will be ignored.
> > Darwin-kernel mailing list (email@hidden)
> > Help/Unsubscribe/Update your Subscription:
> > 40apple.com
> >
> > This email sent to email@hidden
> >
>
>
>
>
_______________________________________________
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