RE: arm: Optimization for ethernet MAC handling at91_ether.c

From: James Kosin
Date: Tue Jan 12 2010 - 13:40:42 EST

-----Original Message-----
From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of Eric Dumazet
Sent: Tuesday, January 12, 2010 1:08 PM
To: James Kosin
Cc: linux-kernel@xxxxxxxxxxxxxxx; Linux Netdev List
Subject: Re: arm: Optimization for ethernet MAC handling at91_ether.c

Le 12/01/2010 18:51, James Kosin a écrit :
> On 1/12/2010 11:40 AM, Eric Dumazet wrote:

>> If this happens once in a while, why do you want driver to retry the transmit ?
> (a) It would improve performance by allowing the ISR to handle the re-transmit in this case.
> (b) It would help in the case of small glitches that may happen from external SDRAM without taxing the polling required to handle the re-transmit of the packet... ie: overhead required to re-queue and initiate a packet delivery... since the packet is already scheduled for delivery now.

OK, but then this also adds an extra check for each tx completion.

I dont have this piece of hardware, but seeing it has a one skb tx queue (!),
I suppose TX performance is not very good anyway...

at91ether_interrupt() should probably handle tx completion before rx, to feed
next frame faster.


I know. Actually, I am using the hardware; and the part is capable of more than this driver is displaying.

1) The part is able to queue up two packets (1) actively being transmitted, and (1) queued up behind that packet. The driver doesn't exploit this; probably because this would cause some confusion, since we wouldn't really know which packet failed when this happens.

2) TX performance is With bing on another computer using '-z' option it is reporting a fairly good value of 74Mbps. I'll have to try with a re-compiled kernel at some point to give better feedback if we can improve this more.

Your interpretation makes some sense on the transmit side. The RX currently has a DMA queue that extends to a depth of 9 (currently). So getting one transmit out before checking the RX may improve things a bit.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at