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

[James Kosin]

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 so..so.  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.

James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/