Date: Wed, 21 Nov 2012 09:32:37 -0800 (PST) From: Barney Cordoba <barney_cordoba@yahoo.com> To: John Fretby <jfretby@googlemail.com> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD boxes as a 'router'... Message-ID: <1353519157.76595.YahooMailClassic@web121605.mail.ne1.yahoo.com> In-Reply-To: <CAN9kdQm_1NAkPPOjsbwRXoHMEMc81b%2B6EXoaHH99uv0dG%2B56Ng@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- On Wed, 11/21/12, John Fretby <jfretby@googlemail.com> wrote: > From: John Fretby <jfretby@googlemail.com> > Subject: Re: FreeBSD boxes as a 'router'... > To: "Victor Balada Diaz" <victor@bsdes.net> > Cc: freebsd-isp@freebsd.org > Date: Wednesday, November 21, 2012, 11:40 AM > On 21 November 2012 14:57, Victor > Balada Diaz <victor@bsdes.net> > wrote: > > > > I think you forgot to CC the list. I'll add it so you > can get > > more answers. > > > > I did forget, thanks for that! :) > > > > em(4) and igb(4) are both drivers for Intel NICs. They > just have > > different capabilities. The sysctl you're asking for > controls behavior > > of adaptive interrupt moderation. It's a recommended > tuning for end hosts > > more than routers. You can read more about interrupt > moderation on this > > document: > > > > http://www.intel.com/design/network/applnots/ap450.htm > > > > em(4) NICs don't have all the capabilities of igb(4) > ones. Some em(4) NICs > > have > > interrupt moderation (eg: 82574L) but not all of them > do. If your em(4) > > card does > > have interrupt moderation you can tune it with: > > > > hw.em.rx_int_delay > > hw.em.rx_abs_int_delay > > hw.em.tx_int_delay > > hw.em.tx_abs_int_delay > > > > Exchanging latency to get more throughput. > > > > You can take a look at this document explaining > capabilities of different > > NICs: > > > > > > http://www.intel.com/content/dam/doc/brochure/ethernet-controllers-phys-brochure.pdf > > > > You should ask supermicro what's the exact model > they'll put on your server > > and then decide if it's OK for you. > > > They are apparently: > > em0: <Intel(R) PRO/1000 Network Connection 7.3.2> port > 0xf020-0xf03f mem > 0xdfa00000-0xdfa1ffff,0xdfa25000-0xdfa25fff irq 20 at device > 25.0 on pci0 > em0: Using an MSI interrupt > ... > em0: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> > metric 0 mtu 1500 > options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO> > > > > About the interrupt storm: We've had various interrupt > storms that were > > caused by > > different problems. The most common was a software bug > with interrupts. > > After > > reporting on the lists it was fixed and we didn't have > problems again. > > > > If you have a problem with high interrupts because too > many small packets > > (eg a DoS), > > getting a card with interrupt moderation should help a > lot. Most probably > > your problem > > with interrupt storms was caused by something else like > a shared interrupt > > with other > > device or software bug. Without more analysis it's > impossible to really > > say. > > > > I have some details from when it happened - it doesn't look > like it was a > shared interrupt issue - it just literally looks like the > host came up, > with a stampeding hurd of "other" hosts hitting it for > services that > weren't yet running, and it folded :( > > That's why I was wondering if there was a similar sysctl for > the em driver > - in order to raise the number of interrupts the system > allows, before > declaring it "a storm". > > > > > > Keep in mind that i'm not an expert on this area, so > you might get better > > answers > > on frebsd-net@ :) > > > > Hope it helps. > > > > It has - half the problem is there are *so* many options, > combinations - > and no matter what you pick, if you look them up enough > you'll find someone > finding fault with them, or casting doubts on their > performance. > > Doesn't really help when all you want is something that has > a good chance > of "working" :) > The road to mediocrity is listening to people who are not experts. The admission that you dont understand something is a good disclosure. But the argument than understanding how to tune a system is too complicated only means that I don't want to listen to what you have to say. Polling implies that there are unnatural intervals between processing packets. So you're introducing delay into your network. The more often you poll, the less the gap. Suppose you poll every 1ms. Each received packet will have from 0-1ms of delay. Packets that are arriving as you ended you last poll will be delayed 1ms. The more knobs you have, the more you can determine what the system can do. An interrupt for every packet would have the least delay, but that's not practical for systems managing 100s of 1000s of pps. You make trade offs between delays and cpu usage. On a small network with a fast cpu, you can process every packet. On a very large network you cant. The idea that there is one way to tune a system for every environment is simply wrong. A bridge/filter has completely different requirements than a "router". And a "server" which only uses 1 NIC has different requirements than a system that forwards traffic and has to manage more locks at the hardware level. BC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1353519157.76595.YahooMailClassic>