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

From: James Kosin
Date: Tue Jan 12 2010 - 14:02:12 EST

On 1/12/2010 1:50 PM, James Kosin wrote:
> -----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:
> 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.

Scratch that. The interrupt doesn't queue up or send another packet directly. So, it wouldn't help on performance here. But, may in other implementations that queue/transmit packets in the ISR. At least in the case where the transmitter is limited to one.

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