From owner-freebsd-net@FreeBSD.ORG  Fri Apr  4 22:44:54 2003
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8BC5337B401; Fri,  4 Apr 2003 22:44:54 -0800 (PST)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 3F8D043F93; Fri,  4 Apr 2003 22:44:53 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA27354;
	Sat, 5 Apr 2003 16:44:50 +1000
Date: Sat, 5 Apr 2003 16:44:49 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Prafulla Deuskar <pdeuskar@freebsd.org>
In-Reply-To: <20030404094628.A59969@hub.freebsd.org>
Message-ID: <20030405163141.T37137@gamplex.bde.org>
References: <20030404094628.A59969@hub.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: freebsd-net@freebsd.org
Subject: Re: Disable/Enable Interrupts in ISR
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Apr 2003 06:44:54 -0000

On Fri, 4 Apr 2003, Prafulla Deuskar wrote:

> All,
>
> foo_intr()
> {
> ...
> disable_intr;
> ...
> process data;
> ...
> enable_intr;
> }
>
> Most of the network drivers currently do something like this in the ISR.
> Is this really necessary as by the time ISR is called interrupts have already been
> disabled on APIC and disabling interrupts on network card has no effect.

What sort of interrupt disabling?  I suppose disabling at the device level
might be useful (e.g., so that the interrupt handler can be returned from,
with the actual interrupt handling mostly done in a lower priority thread),
but most drivers shouldn't need or do this.  Maybe it is needed for
DEVICE_POLLING?

> Is there an issue on non-x86 architectures?

Not AFAIK.  Not far, but SMP and FreeBSD's ithread implementation need
something like an x86 ICU to work right.  The interrupt mask must be
global, and per-cpu ipls don't (naturally) work right even in the 1-cpu
case since they are designed for masking interrupts in a nested way with
the CPU determining the prioritization, but ithreads are non-nested and
want their own prioritization.

Bruce