Re: [PATCH] [e1000]: Remove unnecessary tx_lock

["Edgar E. Iglesias" <edgar.iglesias@axis.com>]

On Mon, Aug 07, 2006 at 11:40:49AM -0400, jamal wrote:
> 
> On Mon, 2006-07-08 at 17:21 +0200, Edgar E. Iglesias wrote:
> [..]
> > I have a question regarding your patch. In clean_tx_irq, it seems you dont
> > clean the ring unless fdesc < tx_ring->prunet. Won't this cause deadlocks for
> > local TCP connections if transmit goes quiet?
> > 
> 
> I have not tested the TCP case; however, note that the specific part you
> reference is commented out. There are no deadlock issues in the case of
> forwarding (as in my testcases). 
> 
> I did not quiet follow the ensuing discussion after your post:
> These descriptors being pruned in the tx path happen only after the
> packets have been sent out on the wire. Why would this contribute to a
> deadlock but not when it happens on the receive path? It is true that
> tcp retransmit queue will still be referencing the skbs, but why is it
> any different because in one case it happens in the tx and in the other
> on the receive? Is there dependency on waking up the queue?
> 

Hi again Jamal,

Not sure if it is doable, but to I'll post the thoughts anyway.

Assuming you would get the code inside the jamal ifdefs working without
deadlocks, you now have a tx_irq function which if fdesc >= tx_ring->prunet
essentially just checks for hw lockups. Let's speculate and further assume you
could do the detect_tx_hung from some other context (timer or whatever) then
you end up having a tx_irq function which most of the time does nothing.

The next step could be to move the fdesc >= tx_ring->prunet logic into the
transmit path and completely disable the tx_irq when the condition is not met.

Now you end up not taking the irq at all as long as fdesc >= tx_ring->prunet.

This was the logic I tried on the cris driver but ended up with deadlocks :)

Best regards
-- 
        Programmer
        Edgar E. Iglesias <edgar.iglesias@axis.com> 46.46.272.1946