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."
---
Izumi Tsutsui