Date: Mon, 4 Jan 2010 05:01:13 -0800 (PST) From: Barney Cordoba <barney_cordoba@yahoo.com> To: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de> Cc: freebsd-net@freebsd.org, Mike Tancsa <mike@sentex.net> Subject: Re: igb interrupt moderation Message-ID: <488554.13788.qm@web63902.mail.re1.yahoo.com> In-Reply-To: <C213F93A-2A94-4189-A59C-515DF3EBC112@lurchi.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
=0A=0A--- On Sun, 1/3/10, Michael T=FCxen <Michael.Tuexen@lurchi.franken.de= > wrote:=0A=0A> From: Michael T=FCxen <Michael.Tuexen@lurchi.franken.de>=0A= > Subject: Re: igb interrupt moderation=0A> To: "Barney Cordoba" <barney_co= rdoba@yahoo.com>=0A> Cc: freebsd-net@freebsd.org, "Mike Tancsa" <mike@sente= x.net>=0A> Date: Sunday, January 3, 2010, 1:33 PM=0A> On Jan 3, 2010, at 6:= 35 PM, Barney=0A> Cordoba wrote:=0A> =0A> > --- On Sun, 1/3/10, Michael T= =FCxen <Michael.Tuexen@lurchi.franken.de>=0A> wrote:=0A> > =0A> >> From: Mi= chael T=FCxen <Michael.Tuexen@lurchi.franken.de>=0A> >> Subject: Re: igb in= terrupt moderation=0A> >> To: "Barney Cordoba" <barney_cordoba@yahoo.com>= =0A> >> Cc: freebsd-net@freebsd.org,=0A> "Mike Tancsa" <mike@sentex.net>=0A= > >> Date: Sunday, January 3, 2010, 12:14 PM=0A> >> On Jan 3, 2010, at 6:00= PM, Barney=0A> >> Cordoba wrote:=0A> >> =0A> >>> =0A> >>> =0A> >>> --- On = Sun, 1/3/10, Michael T=FCxen <Michael.Tuexen@lurchi.franken.de>=0A> >> wrot= e:=0A> >>> =0A> >>>> From: Michael T=FCxen <Michael.Tuexen@lurchi.franken.d= e>=0A> >>>> Subject: Re: igb interrupt moderation=0A> >>>> To: "Mike Tancsa= " <mike@sentex.net>=0A> >>>> Cc: "Barney Cordoba" <barney_cordoba@yahoo.com= >,=0A> >> jfvogel@gmail.com,=0A> >> freebsd-net@freebsd.org=0A> >>>> Date: = Sunday, January 3, 2010, 11:38 AM=0A> >>>> On Jan 3, 2010, at 5:23 PM, Mike= =0A> >>>> Tancsa wrote:=0A> >>>> =0A> >>>>> At 11:13 AM 1/3/2010, Michael T= =FCxen=0A> wrote:=0A> >>>>>>> =0A> >>>>>>> Just a separate datapoint=0A> ab= out this=0A> >> driver,=0A> >>>> unless I apply=0A> >>>>>>> =0A> >>>>>>> ht= tp://people.freebsd.org/~yongari/igb/igb.buf.patch6=0A> >>>>>>> =0A> >>>>>>= > the driver is not really=0A> usable for me=0A> >> in=0A> >>>> RELENG_8 on= the dual port version of the=0A> card=0A> >>>>>> Could you elaborate on wh= at you=0A> mean by=0A> >> "not=0A> >>>> really usable"?=0A> >>>>> =0A> >>>>= > =0A> >>>>> Hi,=0A> >>>>>=A0 =A0 =A0 =A0 =A0=0A> Some=0A> >> link state is= sues=0A> >>>> (getting confused about what port is up),=0A> problems=0A> >>= at high=0A> >>>> packet rates.=A0 I dont have this card=0A> in=0A> >> prod= uction, but=0A> >>>> in my test environment it was much more=0A> stable on= =0A> >> RELENG_8=0A> >>>> with the above patch in that I was not=0A> able t= o=0A> >> wedge the=0A> >>>> box.=A0 pps rates were pretty ok on a=0A> low e= nd=0A> >> i7 as=0A> >>>> well.=0A> >>>> Thanks for the information. I'll gi= ve it a=0A> try. I=0A> >> have a=0A> >>>> problem when I flood=0A> >>>> a s= ystem with SCTP INITs. The system under=0A> attack=0A> >> becomes=0A> >>>> = completely unresponsive=0A> >>>> on the console. However, it continues to= =0A> send=0A> >> INIT-ACKs=0A> >>>> back. After the last=0A> >>>> commit fr= om Jack it recovers after the=0A> attack. Not=0A> >> yet sure=0A> >>>> what= is going on.=0A> >>>> Using the em driver does not have the=0A> problem.= =0A> >> However,=0A> >>>> when using the em=0A> >>>> driver only one core i= s fully used, when=0A> using the=0A> >> igb=0A> >>>> driver both cores are = fully=0A> >>>> used. Unfortunately I do not have a more=0A> than dual=0A> >= > core=0A> >>>> machine available for=0A> >>>> this testing...=0A> >>> =0A>= >>> Try em and lower the interrupt moderation to=0A> something=0A> >> like= 500 (about=0A> >>> 100 packets per int is good). The latency=0A> isn't goi= ng=0A> >> to be noticable and=0A> >>> you'll see your cpu burden reduced qu= ite a=0A> bit. =0A> >> I'll try. Thanks.=0A> >>> =0A> >>> Are you using a s= ingle NIC on a server, or do=0A> you have=0A> >> a firewall or=0A> >>> brid= ge?=0A> >> The system is a sender/receiver for SCTP. I'm=0A> interested in= =0A> >> the 82576=0A> >> since it provides checksum offloading for it. I=0A= > use one or=0A> >> two ports=0A> >> for simultaneous data transfer. The ca= rds using=0A> the em=0A> >> driver do=0A> >> not support this feature. So I= 'm trying to verify=0A> that the=0A> >> performance=0A> >> goes up when usi= ng hardware checksum. But under=0A> attack,=0A> >> this is currently=0A> >>= not the case... =0A> >>> =0A> >>> Barney=0A> > =0A> > I usually try to fin= d something that actually works=0A> before I worry=0A> > about special feat= ures. But we all work differently.=0A> ... I want to make sure that the SCT= P stuff works. So=0A> others=0A> can "just use it". SCTP checksum offloadin= g is one=0A> important=0A> feature...=0A> > =0A> > Barney=0A> > =0A=0AIt ju= st seems a bit silly to worry about saving a few cpu cycles=0Aon checksum o= ffload when the general driver design is wholly =0Ainefficient and unsuitab= le for production. =0A=0ABarney=0A=0A=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?488554.13788.qm>