Date: Wed, 17 Oct 2001 12:43:47 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: <freebsd-current@freebsd.org> Subject: Re: Some interrupt coalescing tests Message-ID: <20011017123225.B47595-100000@achilles.silby.com> In-Reply-To: <3BC951D4.E9638595@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Oct 2001, Terry Lambert wrote: > The one thing I _would_ add -- though I'm waiting for it to > be a problem before doing it -- is to limit the total number > of packets processed per interrupt by keeping a running count. > > You would have to be _AMAZINGLY_ loaded to hit this, though; > since it would mean absolutely continuous DMAs. I think it > is self-limiting, should that happen, since once you are out > of mbufs, you're out. The correct thing to do is probably to > let it run out, but keep a seperate transmit reserve, so that > you can process requests to completion. What probably should be done, if you have time, is to add a bit of profiling to your patch to find out how it helps most. I'm curious how many times it ends up looping, and also why it is looping (whether this is due to receive or transmit.) I think knowing this information would help optimize the drivers further, and perhaps suggest a tact we haven't thought of. > I don't know if anyone has tested what happens to apache in > a denial of service attack consisting of a huge number of > partial "GET" requests that are incomplete, and so leave state > hanging around in the HTTP server... I'm sure it would keel over and die, since it needs a process per socket. If you're talking about sockets in TIME_WAIT or such, see netkill.pl. > Yes. Floyd and Druschel recommend using high and low > watermarks on the amount of data pending processing in > user space. The most common approach is to use a fair > share scheduling algorithm, which reserves a certain > amount of CPU for user space processing, but this is > somewhat wasteful, if there is no work, since it denies > quantum to the interrupt processing, potentially wrongly. I'm not sure such an algorithm would be wasteful - there must be data coming in to trigger such a huge amount of interrupts. I guess this would depend on how efficient your application is, how you set the limits, etc. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011017123225.B47595-100000>