On Sun, Dec 09, 2007 at 07:24:13AM +0900, Izumi Tsutsui wrote:
> dyoung@pobox.com wrote:
> 
> > > The problem is that fxp(4) driver has to update cb_command
> > > bits during the cb_status possibly being updated by fxp chip.
> > 
> > Why?
> 
> Because the driver and chip are designed so?
> 
> >>		 * Cause the chip to interrupt and suspend command
> >>		 * processing once the last packet we've enqueued
> >>		 * has been transmitted.
> 
> > There is not any notion of NIC / host "ownership" of transmit descriptors?
> > I find that hard to believe.
> 
> There is a FXP_CB_STATUS_C (complete?) bit but I don't
> know if it's used to handle ownership.
> 
> We have to set "suspend" bit in the command desriptors
> of the last TX descriptor (because STATUS_C isn't used
> to see ownership?), but they have to be updated when
> we re-add free descriptors during TX might still be processed.
> 
> > How is the host able to modify any
> > descriptor at all without racing against the NIC?
> 
> By 16bit atomic ops on DMA-cache coherent CPUs?
> (only status bits are updated by chip and only command bits
>  are written by a host, and thay are in the different 16bit word)
> That's the reason why I said "it's designed for (and by) intel."

I understand, now.  Thanks for the explanation!

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24