From owner-freebsd-net Sun Oct 6 16:16:56 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 A634B37B401 for ; Sun, 6 Oct 2002 16:16:54 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B7BC43E42 for ; Sun, 6 Oct 2002 16:16:54 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g96NGqO2015528; Sun, 6 Oct 2002 16:16:52 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g96NGq2T015527; Sun, 6 Oct 2002 16:16:52 -0700 (PDT) (envelope-from rizzo) Date: Sun, 6 Oct 2002 16:16:52 -0700 From: Luigi Rizzo To: Steve Francis Cc: freebsd-net@FreeBSD.ORG Subject: Re: Help with net.inet.ip.intr_queue_maxlen Message-ID: <20021006161652.A15352@carp.icir.org> References: <3D9F8002.70500@expertcity.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: <3D9F8002.70500@expertcity.com>; from steve@expertcity.com on Sat, Oct 05, 2002 at 05:12:50PM -0700 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 On Sat, Oct 05, 2002 at 05:12:50PM -0700, Steve Francis wrote: ... > 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? yes, unless the packet is being forwarded and you are using fastforwarding. > 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? the only exception is polling, where after placing in the queue at most kern.polling.poll_burst packets per interface, the kernel will call the ip stack to give it a chance to drain the ip input queue. If the drops you are seeing are the result of some periodic bursts generated by clients, then it might make sense to raise the queue size to some higher value (100-200) to absorb the bursts -- consider that NICs have receive queues which can be as large as 256 entries. Also keep in mind that several drivers (some NICs, lpt, maybe others) are not very well behaved, and periodically tend to run at splimp() for long periods of time (up to 10's of milliseconds) thus causing large queues to build up in other drivers. E.g. the "xl" driver was recently reported to take a long time every second to read some info (statistics ?) from the NIC; at 8kpps, 10ms is roughly 80 packets, which would easily explain the drops you are seeing. Other effects of such delays could be drops in the NIC (often reported as input errors in netstat), delayed operation of the polling code (which used to report this as "poll stalled"), and delayed processing of timeouts. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2988 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message