Date: Mon, 18 Nov 2002 15:11:09 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: David Gilbert <dgilbert@velocet.ca>, dolemite@wuli.nu, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Small initial LRP processing patch vs. -current Message-ID: <20021118151109.B19767@xorpc.icir.org> In-Reply-To: <3DD96FC0.B77331A1@mindspring.com>; from tlambert2@mindspring.com on Mon, Nov 18, 2002 at 02:54:56PM -0800 References: <20021109180321.GA559@unknown.nycap.rr.com> <3DCD8761.5763AAB2@mindspring.com> <15823.51640.68022.555852@canoe.velocet.net> <3DD1865E.B9C72DF5@mindspring.com> <15826.24074.605709.966155@canoe.velocet.net> <3DD2F33E.BE136568@mindspring.com> <3DD96FC0.B77331A1@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Strictly speaking it is not necessary to get rid of the ipintr() code, it will just remain unused, so the relevant part of the patch is the direct call of ip_input() instead of schednetisr(). This patch will not make any difference if you have device_polling enabled, because polling already does this -- queues a small number of packets (default is max 5 per card) and calls ip_input on them right away. The increase on the peak performance will be, i guess, largely dependent on the load and on caching effects -- one expects that processing packets right away will cause the cache to be warm and thus the overall processing be faster. I do not understand this claim: > The basic theory here is that ipintr processing can be delayed > indefinitely, if interrupt load is high enough, and there will > be a maximum latency of 10ms for IP processing after ether_input(), > in the normal stack case, without the patches. because netisr are not timer driven to the best of my knowledge -- they just fire right after the cards' interrupts are complete. cheers luigi On Mon, Nov 18, 2002 at 02:54:56PM -0800, Terry Lambert wrote: ... > Please try the attached patch, with and without DEVICE_POLLING. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021118151109.B19767>