Date: Sun, 17 Aug 1997 01:36:44 -0700 From: David Greenman <dg@root.com> To: Vinay Bannai <vinay@agni.nuko.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Device drivers and DMA details?? Message-ID: <199708170836.BAA08684@implode.root.com> In-Reply-To: Your message of "Sun, 17 Aug 1997 01:09:46 PDT." <199708170809.BAA25936@agni.nuko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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. > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708170836.BAA08684>