From owner-freebsd-hackers  Mon Aug 18 00:57:35 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id AAA05487
          for hackers-outgoing; Mon, 18 Aug 1997 00:57:35 -0700 (PDT)
Received: from agni.nuko.com (dummy.nuko.com [206.79.130.80])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA05482
          for <freebsd-hackers@FreeBSD.ORG>; Mon, 18 Aug 1997 00:57:33 -0700 (PDT)
Received: (from vinay@localhost) by agni.nuko.com (8.8.5/8.7.3) id AAA27888; Mon, 18 Aug 1997 00:55:42 -0700 (PDT)
From: Vinay Bannai <vinay@agni.nuko.com>
Message-Id: <199708180755.AAA27888@agni.nuko.com>
Subject: Re: Device drivers and DMA details??
To: dg@root.com
Date: Mon, 18 Aug 1997 00:55:42 -0700 (PDT)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199708170836.BAA08684@implode.root.com> from "David Greenman" at "Aug 17, 97 01:36:44 am"
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

According to David Greenman:
> >Ah!! I see that the interface's if_start() routine is called when the
> >network is not busy (IFF_OACTIVE). This means that IFF_OACTIVE is set for
> >the interface while receiving the packet or when the controller is
> >busy.
> 
>    Uh, no, IFF_OACTIVE indicates that the interface is busy transmitting
> one or more packets and that it can't handle any additional packets for
> xmit right now.
> 
> > In fact it appears that the fxp driver never has the need to set the
> >IFF_OACTIVE, so the fxp_start() gets called everytime a packet is queued
> >on the interface queue
> 
>    Yes, IFF_OACTIVE is optional and is meant as a sort of optimization to
> avoid calling the driver start routine. It doesn't make sense for if_fxp
> because the fxp card supports dynamic chaining; in other words, a DMA chain
> that is currently being transmitted can be extended with additional packets.
> The only limit to how much the chain can be extend is an arbitrary one
> having to do with the available DMA descriptors. I could actually set
> IFF_OACTIVE when all transmit descriptors are exhausted, but the extra
> overhead to deal with this wasn't worth it - it's a very rare condition
> and the check at the top of fxp_start() will handle this case and return
> immediately.
> 
> > unless it is running at a priority of the hardware
> >interrupt from the network controller. In that case since the hardware
> >interrupt from the network controller being higher than splimp() will make
> >it possible for the IF queues to be flushed before the priority drops back
> >to splimp or whatever.
> 
>    Huh? "network controller being higher than splimp()"? Huh? None of the
> above makes any sense.

Sorry about that. I was meaning to say splnet() (the software interrupt
for protocol processing) instead of splimp(). It is clear to me now. I was
a little confused by the interrupt levels and the names. :-)

> 
> > Is that a correct assesment?
> 
>    Yes, except for the last part. spl* protection is for protecting certain
> critical regions from modification by interrupt routines. While the code
> has an spl* level set, interrupts in that class will be blocked. splimp
> blocks network device interrupts. splnet blocks network (input) packet
> processing that would normally occur when the system returns to spl0. Received
> packets are processed at spl0 in order to avoid certain driver reentrancy
> problems when packets are being forwarded.
> 
> -DG
> 
> David Greenman
> Core-team/Principal Architect, The FreeBSD Project

Thanks for the clarification. 

Vinay