Date: Sun, 6 Oct 2002 16:16:52 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Steve Francis <steve@expertcity.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Help with net.inet.ip.intr_queue_maxlen Message-ID: <20021006161652.A15352@carp.icir.org> In-Reply-To: <3D9F8002.70500@expertcity.com>; from steve@expertcity.com on Sat, Oct 05, 2002 at 05:12:50PM -0700 References: <3D9F8002.70500@expertcity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021006161652.A15352>