Date: Mon, 18 Aug 1997 00:55:42 -0700 (PDT) From: Vinay Bannai <vinay@agni.nuko.com> To: dg@root.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Device drivers and DMA details?? Message-ID: <199708180755.AAA27888@agni.nuko.com> In-Reply-To: <199708170836.BAA08684@implode.root.com> from "David Greenman" at "Aug 17, 97 01:36:44 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708180755.AAA27888>