Date: Thu, 9 May 2013 15:16:47 -0700 (PDT) From: Barney Cordoba <barney_cordoba@yahoo.com> To: Eugene Grosbein <egrosbein@rdtc.ru> Cc: freebsd-net@freebsd.org, =?iso-8859-1?Q?Cl=E9ment_Hermann_=28nodens=29?= <nodens2099@gmail.com> Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 Message-ID: <1368137807.20874.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: <518BCF2C.3080307@rdtc.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
=0A=0A--- On Thu, 5/9/13, Eugene Grosbein <egrosbein@rdtc.ru> wrote:=0A=0A>= From: Eugene Grosbein <egrosbein@rdtc.ru>=0A> Subject: Re: High CPU interr= upt load on intel I350T4 with igb on 8.3=0A> To: "Barney Cordoba" <barney_c= ordoba@yahoo.com>=0A> Cc: ""Cl=E9ment Hermann (nodens)"" <nodens2099@gmail.= com>, freebsd-net@freebsd.org=0A> Date: Thursday, May 9, 2013, 12:30 PM=0A>= On 09.05.2013 23:25, Barney Cordoba=0A> wrote:=0A> =0A> >> Network device = driver is not guilty here, that's=0A> just pf's=0A> >> contention=0A> >> ru= nning in igb's context.=0A> >>=0A> >> Eugene Grosbein=0A> > =0A> > They're = both at play. Single threadedness aggravates=0A> subsystems that =0A> > hav= e too many lock points.=0A> > =0A> > It can also be "solved" with using 1 q= ueue, because=0A> then you don't=0A> > have 4 queues going into a single th= read.=0A> =0A> Again, the problem is within pf(4)'s global lock, not in the= =0A> igb(4).=0A> =0A=0AAgain, you're wrong. It's not the bottleneck's fault= ; it's the fault of =0Athe multi-threaded code for only working properly wh= en there are no=0Abottlenecks.=0A=0ABC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1368137807.20874.YahooMailClassic>