On Sun, Aug 06, 2006 at 05:24:41PM +1000, Herbert Xu wrote:
> Edgar E. Iglesias <[EMAIL PROTECTED]> wrote:
> >
> > Not sure what you mean with "most of the time" but a while a go I played
> > around with a something like this for another driver. The tx path was
> > cleaning
> > up the tx ring at certain intervals while the tx irq-handler was not
> > touching
> > the ring unless it had become full. Actually the tx irq was disabled most
> > of
> > the time and ring manipulation became simpler.
>
> Yes that's exactly what I mean :)
>
> > Later I ended up throwing this away as it was causing some TCP connections
> > to
> > deadlock. If you let skb's sit in the tx-ring indefintely, the
> > sk->sk_wmem_queued accounting will be inacurate and this was causing the
> > TCP
> > retransmit logic to deadlock.
>
> Yes you need to clean the ring if the TX queue becomes empty or you'll
> risk dead locks.
>
> What driver was this and did you do any performance measurements?
>
It was for the cris/eth_v10.c driver. Performance bumped with 20% for UDP if I
remember correctly, TCP was much less. I'll try to dig up the numbers.
On UP non-preemptive kenrnels the tx-path used no interrupts and had no locks
to manipulate the ring. But I am guessing that part of the performance win also
came by freeing the skb's in chunks.
Best regards
--
Programmer
Edgar E. Iglesias <[EMAIL PROTECTED]> 46.46.272.1946
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
