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
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.
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.
From: Joe Perches <[email protected]>
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.
On Wed, 2010-01-13 at 17:41 -0800, David Miller wrote:
> From: Joe Perches <[email protected]>
> 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.
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
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 :)