From owner-freebsd-net@FreeBSD.ORG Sun Jan 3 18:33:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 092DF106568B for ; Sun, 3 Jan 2010 18:33:04 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 50E4E8FC18 for ; Sun, 3 Jan 2010 18:33:03 +0000 (UTC) Received: from [192.168.1.190] (p508FE5E5.dip.t-dialin.net [80.143.229.229]) by mail-n.franken.de (Postfix) with ESMTP id 3592F1C0C0BEA; Sun, 3 Jan 2010 19:33:02 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <608024.81055.qm@web63904.mail.re1.yahoo.com> Date: Sun, 3 Jan 2010 19:33:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <608024.81055.qm@web63904.mail.re1.yahoo.com> To: Barney Cordoba X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: igb interrupt moderation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2010 18:33:04 -0000 On Jan 3, 2010, at 6:35 PM, Barney Cordoba wrote: > --- On Sun, 1/3/10, Michael T=FCxen = wrote: >=20 >> From: Michael T=FCxen >> Subject: Re: igb interrupt moderation >> To: "Barney Cordoba" >> Cc: freebsd-net@freebsd.org, "Mike Tancsa" >> Date: Sunday, January 3, 2010, 12:14 PM >> On Jan 3, 2010, at 6:00 PM, Barney >> Cordoba wrote: >>=20 >>>=20 >>>=20 >>> --- On Sun, 1/3/10, Michael T=FCxen = >> wrote: >>>=20 >>>> From: Michael T=FCxen >>>> Subject: Re: igb interrupt moderation >>>> To: "Mike Tancsa" >>>> Cc: "Barney Cordoba" , >> jfvogel@gmail.com, >> freebsd-net@freebsd.org >>>> Date: Sunday, January 3, 2010, 11:38 AM >>>> On Jan 3, 2010, at 5:23 PM, Mike >>>> Tancsa wrote: >>>>=20 >>>>> At 11:13 AM 1/3/2010, Michael T=FCxen wrote: >>>>>>>=20 >>>>>>> Just a separate datapoint about this >> driver, >>>> unless I apply >>>>>>>=20 >>>>>>> http://people.freebsd.org/~yongari/igb/igb.buf.patch6 >>>>>>>=20 >>>>>>> the driver is not really usable for me >> in >>>> RELENG_8 on the dual port version of the card >>>>>> Could you elaborate on what you mean by >> "not >>>> really usable"? >>>>>=20 >>>>>=20 >>>>> Hi, >>>>> Some >> link state issues >>>> (getting confused about what port is up), problems >> at high >>>> packet rates. I dont have this card in >> production, but >>>> in my test environment it was much more stable on >> RELENG_8 >>>> with the above patch in that I was not able to >> wedge the >>>> box. pps rates were pretty ok on a low end >> i7 as >>>> well. >>>> Thanks for the information. I'll give it a try. I >> have a >>>> problem when I flood >>>> a system with SCTP INITs. The system under attack >> becomes >>>> completely unresponsive >>>> on the console. However, it continues to send >> INIT-ACKs >>>> back. After the last >>>> commit from Jack it recovers after the attack. Not >> yet sure >>>> what is going on. >>>> Using the em driver does not have the problem. >> However, >>>> when using the em >>>> driver only one core is fully used, when using the >> igb >>>> driver both cores are fully >>>> used. Unfortunately I do not have a more than dual >> core >>>> machine available for >>>> this testing... >>>=20 >>> Try em and lower the interrupt moderation to something >> like 500 (about >>> 100 packets per int is good). The latency isn't going >> to be noticable and >>> you'll see your cpu burden reduced quite a bit.=20 >> I'll try. Thanks. >>>=20 >>> Are you using a single NIC on a server, or do you have >> a firewall or >>> bridge? >> The system is a sender/receiver for SCTP. I'm interested in >> the 82576 >> since it provides checksum offloading for it. I use one or >> two ports >> for simultaneous data transfer. The cards using the em >> driver do >> not support this feature. So I'm trying to verify that the >> performance >> goes up when using hardware checksum. But under attack, >> this is currently >> not the case...=20 >>>=20 >>> Barney >=20 > I usually try to find something that actually works before I worry > about special features. But we all work differently. ... I want to make sure that the SCTP stuff works. So others can "just use it". SCTP checksum offloading is one important feature... >=20 > Barney >=20 >=20 >=20 >=20