From owner-freebsd-net Mon Nov 18 15:11:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D84137B401; Mon, 18 Nov 2002 15:11:11 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E74F43E8A; Mon, 18 Nov 2002 15:11:10 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id gAINBAAh022558; Mon, 18 Nov 2002 15:11:10 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id gAINB9Hv022557; Mon, 18 Nov 2002 15:11:09 -0800 (PST) (envelope-from rizzo) Date: Mon, 18 Nov 2002 15:11:09 -0800 From: Luigi Rizzo To: Terry Lambert Cc: David Gilbert , 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> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DD96FC0.B77331A1@mindspring.com>; from tlambert2@mindspring.com on Mon, Nov 18, 2002 at 02:54:56PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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