[PATCH 1/2] net: at91_ether.c - Allow transmitter interrupt to be handled first in ISR

[PATCH 1/2] net: at91_ether.c - Allow transmitter interrupt to be handled first in ISR

[James Kosin]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

Ok,

This is an optimization to:

  Allow the transmitter to free the skb before the receiver allocates
many skbs from the system.  This should help with skb reuse and in
multi-core ARM systems allow the next transmitter to be started while we
service the receiver DMA blocks.

  This first patch is only a move of the service of the transmitter
interrupt to be first in the ISR.  This is not expensive; because the
transmitter queue to the MAC is only (1) one deep, and the receiver is
currently (9) nine deep.

James Kosin


[-- Attachment #2: ether_patch_1.patch --]
[-- Type: application/octet-stream, Size: 874 bytes --]

--- C:/Documents and Settings/jkosin/My Documents/junk/kernel/Copy of linux-2.6.31.5/drivers/net/arm/at91_ether.c	Thu Oct 22 18:57:56 2009
+++ C:/Documents and Settings/jkosin/My Documents/junk/kernel/linux-2.6.31.5/drivers/net/arm/at91_ether.c	Wed Jan 13 12:05:39 2010
@@ -925,9 +925,6 @@
 	   It is automatically cleared once read. */
 	intstatus = at91_emac_read(AT91_EMAC_ISR);
 
-	if (intstatus & AT91_EMAC_RCOM)		/* Receive complete */
-		at91ether_rx(dev);
-
 	if (intstatus & AT91_EMAC_TCOM) {	/* Transmit complete */
 		/* The TCOM bit is set even if the transmission failed. */
 		if (intstatus & (AT91_EMAC_TUND | AT91_EMAC_RTRY))
@@ -940,6 +937,9 @@
 		}
 		netif_wake_queue(dev);
 	}
+
+	if (intstatus & AT91_EMAC_RCOM)		/* Receive complete */
+		at91ether_rx(dev);
 
 	/* Work-around for Errata #11 */
 	if (intstatus & AT91_EMAC_RBNA) {

Re: [PATCH 1/2] net: at91_ether.c - Allow transmitter interrupt to be handled first in ISR

[David Miller]

Encoding your patches as base64 binary octet stream attachments
causes them to get missed by our automated patch tracking system:

	http://patchwork.ozlabs.org/project/netdev/list/

It works by detecting patches contained in emails posted to the netdev
mailing list.

Can you therefore please follow the guidelines in:

	linux/Documentation/email-clients.txt

for submitting your patches so that they get tracked instead of
lost?

Thanks.

netdev: patchwork.ozlabs.org vs patchwork.kernel.org ?

[Joe Perches]

On Wed, 2010-01-13 at 17:32 -0800, David Miller wrote:
> Encoding your patches as base64 binary octet stream attachments
> causes them to get missed by our automated patch tracking system:
> 
> 	http://patchwork.ozlabs.org/project/netdev/list/

What is the reason why netdev doesn't use patchwork.kernel.org?

It seems odd that it doesn't.  Odd like the arm mailing lists.

Re: netdev: patchwork.ozlabs.org vs patchwork.kernel.org ?

[David Miller]

From: Joe Perches <joe@perches.com>
Date: Wed, 13 Jan 2010 17:40:37 -0800

> On Wed, 2010-01-13 at 17:32 -0800, David Miller wrote:
>> Encoding your patches as base64 binary octet stream attachments
>> causes them to get missed by our automated patch tracking system:
>> 
>> 	http://patchwork.ozlabs.org/project/netdev/list/
> 
> What is the reason why netdev doesn't use patchwork.kernel.org?
> 
> It seems odd that it doesn't.  Odd like the arm mailing lists.

ozlabs was the original, and so just like powerpc port that's where we
started using the tool.

I honestly don't care where it's hosted.

Re: netdev: patchwork.ozlabs.org vs patchwork.kernel.org ?

[Joe Perches]

On Wed, 2010-01-13 at 17:41 -0800, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Wed, 13 Jan 2010 17:40:37 -0800
> > On Wed, 2010-01-13 at 17:32 -0800, David Miller wrote:
> >> Encoding your patches as base64 binary octet stream attachments
> >> causes them to get missed by our automated patch tracking system:
> >> 	http://patchwork.ozlabs.org/project/netdev/list/
> > What is the reason why netdev doesn't use patchwork.kernel.org?
> > It seems odd that it doesn't.  Odd like the arm mailing lists.
> ozlabs was the original, and so just like powerpc port that's where we
> started using the tool.
> I honestly don't care where it's hosted.

Neither do I, but it might be nice to put a link
to the patchwork.ozlabs.org queues on this page

http://patchwork.kernel.org/

(or the other way 'round, or both)

so there's a centralized listing of all linux related
patchwork queues.

RE: [PATCH 1/2] net: at91_ether.c - Allow transmitter interrupt to be handled first in ISR

[James Kosin]

Thanks David,

I'm checking out the latest git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
With git now...

A few items:
	a)  Is it OK to use git-diff to build a patch file?  Or does everyone still prefer
	    diff?

	b)  I'm going to try and test also; since, I do have an active platform I
	    can test on.  Are there any other developers using the ARM that may be able
	    to provide some feedback?  Eric Dumazet had some interesting comments
	    but, none of the original people in the file are around anymore I'm afraid.
	    That or they really don't want to be contacted.

Thanks Again,

James Kosin

Re: [PATCH 1/2] net: at91_ether.c - Allow transmitter interrupt to be handled first in ISR

[Eric Dumazet]

Le 14/01/2010 21:28, James Kosin a écrit :
> Thanks David,
> 
> I'm checking out the latest git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
> With git now...
> 
> A few items:
> 	a)  Is it OK to use git-diff to build a patch file?  Or does everyone still prefer
> 	    diff?

If you cook your patches using a git tree, git diff is very fine to send official patches.

> 
> 	b)  I'm going to try and test also; since, I do have an active platform I
> 	    can test on.  Are there any other developers using the ARM that may be able
> 	    to provide some feedback?  Eric Dumazet had some interesting comments
> 	    but, none of the original people in the file are around anymore I'm afraid.
> 	    That or they really don't want to be contacted.

If you can test patches, and other dev can review them, they can find their way in kernel,
dont worry :)