Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Oct 2002 16:35:57 +0300
From:      "Ido Barnea" <ido@cwnt.com>
To:        "Steve Francis" <steve@expertcity.com>, <freebsd-net@freebsd.org>
Subject:   RE: Help with net.inet.ip.intr_queue_maxlen
Message-ID:  <C7DF4400240AFB4095D98C7C6EC2A34A08336F@bart.cwnt.com>

next in thread | raw e-mail | index | archive | help


> -----Original Message-----
> From: Steve Francis [mailto:steve@expertcity.com]
> Sent: Sunday, October 06, 2002 3:13 AM
> To: freebsd-net@freebsd.org
> Subject: Help with net.inet.ip.intr_queue_maxlen
>=20
>=20
> Can someone help me with net.inet.ip.intr_queue_maxlen tuning?
>=20
> Firstly, its the "size of the IP input queue", per the source.
>=20
> 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=20
> 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?
>=20

Absolutely correct

> 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=20
> 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=20
> I increase
> the input queue, I should be able to avoid these drops, correct? At
> least until the system gets a lot busier.
>=20

Correct again

> Is there a sane upper recommended limit to the queue length?
>=20

Basically there shouldn't be a problem incrementing the queue length, =
since the space is not allocated in advance.
So, you should experiment with few values until the drop rate drops to a =
reasonable value.
The only problem I can think of is that you (or an attacker) can exhaust =
your mbuf pool if you allow the queue length
to become too large. You can check out the state of your mbuf poll using =
'netstat -m'

> Or am I way off base here?
> Thanks
>=20
>=20
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>=20

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?C7DF4400240AFB4095D98C7C6EC2A34A08336F>