From owner-freebsd-net Sat Oct 5 17:11:29 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 4E9CC37B401 for ; Sat, 5 Oct 2002 17:11:28 -0700 (PDT) Received: from csmail.commserv.ucsb.edu (cspdc.commserv.ucsb.edu [128.111.251.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBBC243E4A for ; Sat, 5 Oct 2002 17:11:27 -0700 (PDT) (envelope-from steve@expertcity.com) Received: from expertcity.com ([68.6.35.15]) by csmail.commserv.ucsb.edu (Netscape Messaging Server 3.62) with ESMTP id 587 for ; Sat, 5 Oct 2002 17:11:25 -0700 Message-ID: <3D9F8002.70500@expertcity.com> Date: Sat, 05 Oct 2002 17:12:50 -0700 From: Steve Francis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Help with net.inet.ip.intr_queue_maxlen Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Can someone help me with net.inet.ip.intr_queue_maxlen tuning? Firstly, its the "size of the IP input queue", per the source. So does that mean after the NIC has received the packet, the interupt from the NIC has been processed and the packet retrieved from the NIC, then the packet is placed in this queue, before the IP stack looks at it? i.e. its unrelated to interupt coalescing or polling, or NIC performance, as they have already occurred in order to put the packet into the queue. Yes? I am getting incrementing net.inet.ip.intr_queue_drops at around 8,000 pps (increasing drops at rate of 10 or so per second.) Yet, if my statement above about what the queue is, is correct, then it just means that the system was busy doing stuff before it had a chance to process the incoming packets, so there was no room for new ones to enter the queue. But as the system was only 50% busy, then if I increase the input queue, I should be able to avoid these drops, correct? At least until the system gets a lot busier. Is there a sane upper recommended limit to the queue length? Or am I way off base here? Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message