Date: Sun, 12 May 2013 14:07:11 -0600 From: Scott Long <scott4long@yahoo.com> To: Hooman Fazaeli <hoomanfazaeli@gmail.com> Cc: freebsd-net@freebsd.org, =?iso-8859-1?Q?=22Cl=E9ment_Hermann_=28nodens=29=22?= <nodens2099@gmail.com>, Eugene Grosbein <egrosbein@rdtc.ru> Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 Message-ID: <195AF945-C1C9-4EE8-9A8E-A196E4658184@yahoo.com> In-Reply-To: <518EA643.5010505@gmail.com> References: <1368287797.70288.YahooMailClassic@web121603.mail.ne1.yahoo.com> <518EA643.5010505@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 11, 2013, at 2:12 PM, Hooman Fazaeli <hoomanfazaeli@gmail.com> = wrote: > On 5/11/2013 8:26 PM, Barney Cordoba wrote: >> Clearly you don't understand the problem. Your logic is that because = other drivers are defective also; therefore its not a driver problem? = The problem is caused by a multi-threaded driver that >> haphazardly launches tasks and that doesn't manage the case that the = rest of the system can't handle the load. It's no different than a = driver that barfs when mbuf clusters are exhausted. The answer >> isn't to increase memory or mbufs, even though that may alleviate the = problem. The answer is to fix the driver, so that it doesn't crash the = system for an event that is wholly predictable. igb has >> 1) too many locks and 2) exasperates the problem by binding to cpus, = which causes it to not only have to wait for the lock to free, but also = for a specific cpu to become free. So it chugs along >> happily until it encounters a bottleneck, at which point it quickly = blows up the entire system in a domino effect. It needs to manage locks = more efficiently, and also to detect when the backup is >> unmanageable. Ever since FreeBSD 5 the answer has been "it's fixed in = 7, or its fixed in 9, or it's fixed in 10". There will always be = bottlenecks, and no driver should blow up the system no matter >> what intermediate code may present a problem. Its the driver's = responsibility to behave and to drop packets if necessary. BC >=20 > And how the driver should behave? You suggest dropping the packets. = Even if we accept > that dropping packets is a good strategy in all configurations (which = I doubt), the driver is > definitely not the best place to implement it, since that involves = duplication of similar > code between drivers. Somewhere like the Ethernet layer is a much = better choice to watch > load of packets and drop them to prevent them to eat all the cores. = Furthermore, ignoring > the fact that pf is not optimized for multi-processors and blaming = drivers for not adjusting > themselves with the this pf's fault, is a bit unfair, I believe. >=20 Fortunately I no longer receive Barney's emails, but it still distresses = me to see him trolling the list. It should be a pretty big hint that Barney has nothing to offer the = conversation when he suggests on a technical level that dropping packets is an acceptable = policy for drivers. The conversation is also over when he resorts to the ad hominem attacks = and the blanket "driver X sucks and you all are too lazy to follow my brilliance = in fixing it" tripe. Can we all just put him on ignore and move on? A brief search of the PR = database shows no contributions from him. A brief search of the mailing lists = shows only inflamed diatribes and insults from him, with a brief smattering here = and there of benign but content-free posts. On the other hand, if the consensus here is to keep on baiting and = feeding him for our own amusement, I applaud the effort but ask for a bit more subtlety = =3D-) Thanks! Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?195AF945-C1C9-4EE8-9A8E-A196E4658184>