From owner-freebsd-net  Sun Oct 20 15:34:20 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1C22837B401
	for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 15:34:19 -0700 (PDT)
Received: from pop015.verizon.net (pop015pub.verizon.net [206.46.170.172])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5A0A343E42
	for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 15:34:18 -0700 (PDT)
	(envelope-from jimmcgra@bellatlantic.net)
Received: from Default ([141.154.237.113]) by pop015.verizon.net
          (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP
          id <20021020223417.BJEE28019.pop015.verizon.net@Default>;
          Sun, 20 Oct 2002 17:34:17 -0500
From: "Jim McGrath" <jimmcgra@bellatlantic.net>
To: "Petri Helenius" <pete@he.iki.fi>,
	"Don Bowman" <don@sandvine.com>, <Kevin_Stevens@pursued-with.net>
Cc: <freebsd-net@FreeBSD.ORG>
Subject: RE: ENOBUFS
Date: Sun, 20 Oct 2002 18:34:53 -0400
Message-ID: <NDBBKKEELKBCJJBEGDECMEIGCGAA.jimmcgra@bellatlantic.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <046c01c27880$c7c727a0$3500080a@PHE>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at pop015.verizon.net from [141.154.237.113] at Sun, 20 Oct 2002 17:34:17 -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

You really need Intel documentation.  The Receive Interrupt Delay Value
helped a lot, but in the case of the 82544, caused chip lockup under very
high load.  It has been a while, but the optimal value in my implementation
was 22 ticks.  The on chip cache is skewed in favor of receive processing,
something like 70/30.  In a pass through application, setting it to 50/50
helps.  I'm speaking from 82543/82544 experience.  Things may have changed
since then.

Jim
> What would be the best course of action to implement optimizations
> possible with later chips like 82546 to the em driver? Talk to Intel?
>
> Pete
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message