site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W52xPvVzgxopjQtstFo3qxY542mX2LhBTkBKQKOe9aKqtvSchcbpYeC0dwvhrriA2x2rKqPA1VfOGnpws3KRSEZf/JYyZ3G7uA7ytCsLbjgqJGcwNTEiTOebLO1/5oGsc+uixuy/AsPuWU69r9Trcxd+bgxGenzz1l8Gi7WM+P8= 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 <jgraessley@apple.com> 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/jgraessley% 40apple.com

This email sent to jgraessley@apple.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