[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3DBBD805E3BA064A87F551C0E8BD36740289740E@MAILSRV.intcomgrp.com>
Date: Tue, 12 Jan 2010 12:51:57 -0500
From: "James Kosin" <JKosin@...comgrp.com>
To: "Eric Dumazet" <eric.dumazet@...il.com>
Cc: <linux-kernel@...r.kernel.org>,
"Linux Netdev List" <netdev@...r.kernel.org>
Subject: RE: arm: Optimization for ethernet MAC handling at91_ether.c
On 1/12/2010 11:40 AM, Eric Dumazet wrote:
> CC to netdev
>
> Le 12/01/2010 16:39, James Kosin a écrit :
>> Everyone,
>>
>> Since, a AT91_EMAC_TUND only happens when the transmitter is unable to
>> transfer the frame in time for a frame to be sent. It makes sense to
>> RETRY the packet in this condition in the ISR.
>> Or would this overcomplicate a simple task?
>> ... see below ...
>>
> ...
>
>>
>> ...
>> I do know there needs to be a bit more code then to handle the
>> successful case below this; but, this is enough to understand what I am
>> talking about. The UNDERRUN error should happen infrequently and in
>> ideal circumstances not happen at all.
>>
>
>
> 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.
James
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists