On May 11, 2013, at 2:12 PM, Hooman Fazaeli <hoomanfaza...@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 > > 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. > 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 =-) Thanks! Scott _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
