* Re: [microblaze-uclinux] Re: [PATCH net-next-2.6] net: Increase NET_SKB_PAD to 64 bytes
From: David Miller @ 2010-05-07 6:29 UTC (permalink / raw)
To: john.williams; +Cc: microblaze-uclinux, netdev, hadi, therbert, monstr
In-Reply-To: <m2g1d3f23371005062228y267b398cue82f518c7638929e@mail.gmail.com>
From: John Williams <john.williams@petalogix.com>
Date: Fri, 7 May 2010 15:28:08 +1000
> There will be some patches coming from Michal that cleans all of this
> up - MicroBlaze has a configurable cacheline length, we have some
> patches that set this to the longest possible (32 bytes) in a
> conservative assumption.
32 it the old default, the new one is 64.
So either way, these settings are completely bogus.
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Eric Dumazet @ 2010-05-07 5:39 UTC (permalink / raw)
To: Bhaskar Dutta; +Cc: Stephen Hemminger, Ben Hutchings, netdev
In-Reply-To: <i2y571fb4001005060455m39bed7f7if5fcfc45b12bc4d3@mail.gmail.com>
Le jeudi 06 mai 2010 à 17:25 +0530, Bhaskar Dutta a écrit :
> On Thu, May 6, 2010 at 12:23 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > I am not familiar with this code, but I suspect same per_cpu data can be
> > used at both time by a sender (process context) and by a receiver
> > (softirq context).
> >
> > To trigger this, you need at least two active md5 sockets.
> >
> > tcp_get_md5sig_pool() should probably disable bh to make sure current
> > cpu wont be preempted by softirq processing
> >
> >
> > Something like :
> >
> > diff --git a/include/net/tcp.h b/include/net/tcp.h
> > index fb5c66b..e232123 100644
> > --- a/include/net/tcp.h
> > +++ b/include/net/tcp.h
> > @@ -1221,12 +1221,15 @@ struct tcp_md5sig_pool *tcp_get_md5sig_pool(void)
> > struct tcp_md5sig_pool *ret = __tcp_get_md5sig_pool(cpu);
> > if (!ret)
> > put_cpu();
> > + else
> > + local_bh_disable();
> > return ret;
> > }
> >
> > static inline void tcp_put_md5sig_pool(void)
> > {
> > __tcp_put_md5sig_pool();
> > + local_bh_enable();
> > put_cpu();
> > }
> >
> >
> >
>
> I put in the above change and ran some load tests with around 50
> active TCP connections doing MD5.
> I could see only 1 bad packet in 30 min (earlier the problem used to
> occur instantaneously and repeatedly).
>
> I think there is another possibility of being preempted when calling
> tcp_alloc_md5sig_pool()
> this function releases the spinlock when calling __tcp_alloc_md5sig_pool().
>
> I will run some more tests after changing the tcp_alloc_md5sig_pool
> and see if the problem is completely resolved.
I cant see a race with spinlock in
tcp_alloc_md5sig_pool/__tcp_alloc_md5sig_pool().
We allocate structures for all cpus, so preemption.migration should be
OK
Could you elaborate please ?
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Eric Dumazet @ 2010-05-07 5:32 UTC (permalink / raw)
To: David Miller; +Cc: bhaskie, shemminger, bhutchings, netdev
In-Reply-To: <20100506.220443.135536330.davem@davemloft.net>
Le jeudi 06 mai 2010 à 22:04 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> > This code should be completely rewritten for linux-2.6.35, its very ugly
> > and over complex, yet it is not scalable.
> >
> > It could use true percpu data, with no central lock or refcount.
>
> Yes I've always disliked the way the TCP MD5 pool stuff is coded, it's
> frankly crap and this is like the 5th major bug that had to get fixed
> in it. :-)
>
> But let's fix this as simply as possible in net-2.6 and -stable, so Eric
> let me know when you have a tested patch for me to apply.
There are so many things ...
I am comtemplating commit aa133076
__tcp_alloc_md5sig_pool() now do a :
p = kzalloc(sizeof(*p), sk->sk_allocation);
But later call :
hash = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
(GFP_KERNEL allocations for sure)
tcp_v4_parse_md5_keys() also use :
p = kzalloc(sizeof(*p), sk->sk_allocation);
right after a (possibly sleeping) copy_from_user()
Oh well...
I'll test the already suggested patch before official submission,
thanks.
^ permalink raw reply
* Re: [microblaze-uclinux] Re: [PATCH net-next-2.6] net: Increase NET_SKB_PAD to 64 bytes
From: John Williams @ 2010-05-07 5:28 UTC (permalink / raw)
To: microblaze-uclinux; +Cc: David Miller, netdev, hadi, therbert, monstr
In-Reply-To: <1273209321.2222.36.camel@edumazet-laptop>
On Fri, May 7, 2010 at 3:15 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 06 mai 2010 à 22:02 -0700, David Miller a écrit :
>
>> Seeing this made me go check who was overriding NET_IP_ALIGN or
>> NET_SKB_PAD.
>>
>> The powerpc bits are legitimate, but the microblaze case is complete
>> bogosity. It defines NET_IP_ALIGN to the default (2) and sets
>> NET_SKB_PAD to L1_CACHE_BYTES which on microblaze is 4 and
>> significantly smaller than the default.
>>
>> So I'm going to delete them in net-next-2.6 like so:
>>
>> --------------------
>> microblaze: Kill NET_SKB_PAD and NET_IP_ALIGN overrides.
>>
>> NET_IP_ALIGN defaults to 2, no need to override.
>>
>> NET_SKB_PAD is now 64, which is much larger than microblaze's
>> L1_CACHE_SIZE so no need to override that either.
>>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>> ---
>> arch/microblaze/include/asm/system.h | 10 ----------
>> 1 files changed, 0 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/microblaze/include/asm/system.h b/arch/microblaze/include/asm/system.h
>> index 48c4f03..b1e2f07 100644
>> --- a/arch/microblaze/include/asm/system.h
>> +++ b/arch/microblaze/include/asm/system.h
>> @@ -97,14 +97,4 @@ extern struct dentry *of_debugfs_root;
>>
>> #define arch_align_stack(x) (x)
>>
>> -/*
>> - * MicroBlaze doesn't handle unaligned accesses in hardware.
>> - *
>> - * Based on this we force the IP header alignment in network drivers.
>> - * We also modify NET_SKB_PAD to be a cacheline in size, thus maintaining
>> - * cacheline alignment of buffers.
>> - */
>> -#define NET_IP_ALIGN 2
>> -#define NET_SKB_PAD L1_CACHE_BYTES
>> -
>> #endif /* _ASM_MICROBLAZE_SYSTEM_H */
>
> Yes, this seems strange it actually worked if L1_CACHE_BYTES = 4
There will be some patches coming from Michal that cleans all of this
up - MicroBlaze has a configurable cacheline length, we have some
patches that set this to the longest possible (32 bytes) in a
conservative assumption.
John
^ permalink raw reply
* Re: [PATCH -next 2/3 v2] bnx2: Add prefetches to rx path.
From: David Miller @ 2010-05-07 5:18 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1273172293-10241-2-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 6 May 2010 11:58:13 -0700
> Add prefetches of the skb and the next rx descriptor to speed up rx path.
>
> Use prefetchw() for the skb [suggested by Eric Dumazet].
>
> The rx descriptor is in skb->data which is mapped for streaming mode DMA.
> Eric Dumazet pointed out that we should not prefetch the data before
> dma_sync. So we prefetch only if dma_sync is no_op on the system.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Also applied, thanks!
^ permalink raw reply
* Re: [PATCH -next 1/3 v2] bnx2: Add GRO support.
From: David Miller @ 2010-05-07 5:17 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1273172293-10241-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 6 May 2010 11:58:12 -0700
> And turn on NETIF_F_GRO by default [requested by DaveM].
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks Michael.
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: Various optimizations
From: Eric Dumazet @ 2010-05-07 5:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, therbert
In-Reply-To: <20100506.220759.25136752.davem@davemloft.net>
Le jeudi 06 mai 2010 à 22:07 -0700, David Miller a écrit :
> Looks great, applied, thanks Eric.
Thanks, I have a followup to avoid one atomic in enqueue phase too ;)
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Increase NET_SKB_PAD to 64 bytes
From: Eric Dumazet @ 2010-05-07 5:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, hadi, therbert, monstr, microblaze-uclinux
In-Reply-To: <20100506.220221.90798296.davem@davemloft.net>
Le jeudi 06 mai 2010 à 22:02 -0700, David Miller a écrit :
> Seeing this made me go check who was overriding NET_IP_ALIGN or
> NET_SKB_PAD.
>
> The powerpc bits are legitimate, but the microblaze case is complete
> bogosity. It defines NET_IP_ALIGN to the default (2) and sets
> NET_SKB_PAD to L1_CACHE_BYTES which on microblaze is 4 and
> significantly smaller than the default.
>
> So I'm going to delete them in net-next-2.6 like so:
>
> --------------------
> microblaze: Kill NET_SKB_PAD and NET_IP_ALIGN overrides.
>
> NET_IP_ALIGN defaults to 2, no need to override.
>
> NET_SKB_PAD is now 64, which is much larger than microblaze's
> L1_CACHE_SIZE so no need to override that either.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> arch/microblaze/include/asm/system.h | 10 ----------
> 1 files changed, 0 insertions(+), 10 deletions(-)
>
> diff --git a/arch/microblaze/include/asm/system.h b/arch/microblaze/include/asm/system.h
> index 48c4f03..b1e2f07 100644
> --- a/arch/microblaze/include/asm/system.h
> +++ b/arch/microblaze/include/asm/system.h
> @@ -97,14 +97,4 @@ extern struct dentry *of_debugfs_root;
>
> #define arch_align_stack(x) (x)
>
> -/*
> - * MicroBlaze doesn't handle unaligned accesses in hardware.
> - *
> - * Based on this we force the IP header alignment in network drivers.
> - * We also modify NET_SKB_PAD to be a cacheline in size, thus maintaining
> - * cacheline alignment of buffers.
> - */
> -#define NET_IP_ALIGN 2
> -#define NET_SKB_PAD L1_CACHE_BYTES
> -
> #endif /* _ASM_MICROBLAZE_SYSTEM_H */
Yes, this seems strange it actually worked if L1_CACHE_BYTES = 4
Thanks
^ permalink raw reply
* Re: [PATCH 8/8] tehuti: Remove unnecessary memset of netdev private data
From: David Miller @ 2010-05-07 5:11 UTC (permalink / raw)
To: tklauser; +Cc: baum, netdev, kernel-janitors, andy
In-Reply-To: <1273160584-13387-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 6 May 2010 17:43:04 +0200
> The memory for the private data is allocated using kzalloc in
> alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
> set it to 0 again.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH 7/8] sunhme: Remove unnecessary memset of netdev private data
From: David Miller @ 2010-05-07 5:11 UTC (permalink / raw)
To: tklauser; +Cc: netdev, kernel-janitors
In-Reply-To: <1273160504-13308-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 6 May 2010 17:41:44 +0200
> The memory for the private data is allocated using kzalloc in
> alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
> set it to 0 again.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH 6/8] smc9194: Remove unnecessary memset of netdev private data
From: David Miller @ 2010-05-07 5:11 UTC (permalink / raw)
To: tklauser; +Cc: netdev, kernel-janitors
In-Reply-To: <1273160491-13228-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 6 May 2010 17:41:31 +0200
> The memory for the private data is allocated using kzalloc in
> alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
> set it to 0 again.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH 5/8] ethoc: Remove unnecessary memset of napi member in netdev private data
From: David Miller @ 2010-05-07 5:11 UTC (permalink / raw)
To: tklauser; +Cc: netdev, kernel-janitors
In-Reply-To: <1273160472-13127-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 6 May 2010 17:41:12 +0200
> The memory for the private data is allocated using kzalloc in
> alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
> set the napi member it to 0 explicitely.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH 4/8] bcm63xx_enet: Remove unnecessary memset of netdev private data
From: David Miller @ 2010-05-07 5:11 UTC (permalink / raw)
To: tklauser; +Cc: netdev, kernel-janitors
In-Reply-To: <1273160458-13039-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 6 May 2010 17:40:58 +0200
> The memory for the private data is allocated using kzalloc in
> alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
> set it to 0 again.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH 3/8] KS8695: Remove unnecessary memset of netdev private data
From: David Miller @ 2010-05-07 5:11 UTC (permalink / raw)
To: tklauser; +Cc: netdev, kernel-janitors
In-Reply-To: <1273160429-12964-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 6 May 2010 17:40:29 +0200
> The memory for the private data is allocated using kzalloc in
> alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
> set it to 0 again.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH 2/8] 3c523: Remove unnecessary memset of netdev private data
From: David Miller @ 2010-05-07 5:11 UTC (permalink / raw)
To: tklauser; +Cc: netdev, kernel-janitors
In-Reply-To: <1273160386-12845-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 6 May 2010 17:39:46 +0200
> The memory for the private data is allocated using kzalloc in
> alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
> set it to 0 again.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH 1/8] 3c507: Remove unnecessary memset of netdev private data
From: David Miller @ 2010-05-07 5:11 UTC (permalink / raw)
To: tklauser; +Cc: netdev, kernel-janitors
In-Reply-To: <1273160351-12710-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 6 May 2010 17:39:11 +0200
> The memory for the private data is allocated using kzalloc in
> alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
> set it to 0 again.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: Various optimizations
From: David Miller @ 2010-05-07 5:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, therbert
In-Reply-To: <1273136322.2357.15.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 May 2010 10:58:42 +0200
> Introduce ____napi_schedule() helper for callers in irq disabled
> contexts. rps_trigger_softirq() becomes a leaf function.
>
> Use container_of() in process_backlog() instead of accessing per_cpu
> address.
>
> Use a custom inlined version of __napi_complete() in process_backlog()
> to avoid one locked instruction :
>
> only current cpu owns and manipulates this napi,
> and NAPI_STATE_SCHED is the only possible flag set on backlog.
> we can use a plain write instead of clear_bit(),
> and we dont need an smp_mb() memory barrier, since RPS is on,
> backlog is protected by a spinlock.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Looks great, applied, thanks Eric.
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: David Miller @ 2010-05-07 5:04 UTC (permalink / raw)
To: eric.dumazet; +Cc: bhaskie, shemminger, bhutchings, netdev
In-Reply-To: <1273147586.2357.63.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 May 2010 14:06:26 +0200
> Le jeudi 06 mai 2010 à 17:25 +0530, Bhaskar Dutta a écrit :
>
>> I put in the above change and ran some load tests with around 50
>> active TCP connections doing MD5.
>> I could see only 1 bad packet in 30 min (earlier the problem used to
>> occur instantaneously and repeatedly).
>>
>> I think there is another possibility of being preempted when calling
>> tcp_alloc_md5sig_pool()
>> this function releases the spinlock when calling __tcp_alloc_md5sig_pool().
>>
>> I will run some more tests after changing the tcp_alloc_md5sig_pool
>> and see if the problem is completely resolved.
>>
>
> This code should be completely rewritten for linux-2.6.35, its very ugly
> and over complex, yet it is not scalable.
>
> It could use true percpu data, with no central lock or refcount.
Yes I've always disliked the way the TCP MD5 pool stuff is coded, it's
frankly crap and this is like the 5th major bug that had to get fixed
in it. :-)
But let's fix this as simply as possible in net-2.6 and -stable, so Eric
let me know when you have a tested patch for me to apply.
Thanks a lot!
^ permalink raw reply
* RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
From: Arce, Abraham @ 2010-05-07 5:02 UTC (permalink / raw)
To: Ha, Tristram, Ben Dooks
Cc: David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Jan, Sebastien
In-Reply-To: <14385191E87B904DBD836449AA30269D021A64@MORGANITE.micrel.com>
Hi,
[snip]
> There is a driver option no_tx_opt so that the driver can revert to original
> implementation. This allows user to verify if the transmit performance
> actually improves.
Should we limit patch description to 80 characters also?
> Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
> ---
> This replaces the [patch 01/13] patch I submitted and was objected by David.
>
> Other users with Micrel KSZ8851 SNL chip please verify the transmit
> performance does improve or not.
Tested-by: Abraham Arce <x0066660@ti.com>
Executing some nuttcp scenarios:
- Without Patch -
# /testsuites/ethernet/bin/nuttcp -u -i -Ri50m <serverip>
1.2676 MB / 1.00 sec = 10.6330 Mbps 0 / 1298 ~drop/pkt 0.00 ~%loss
1.2705 MB / 1.00 sec = 10.6579 Mbps 0 / 1301 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6414 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2695 MB / 1.00 sec = 10.6496 Mbps 0 / 1300 ~drop/pkt 0.00 ~%loss
1.2695 MB / 1.00 sec = 10.6496 Mbps 0 / 1300 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6414 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6414 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2646 MB / 1.00 sec = 10.6086 Mbps 0 / 1295 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6412 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2695 MB / 1.00 sec = 10.6498 Mbps 0 / 1300 ~drop/pkt 0.00 ~%loss
12.7314 MB / 10.02 sec = 10.6637 Mbps 4 %TX 0 %RX 0 / 13037 drop/pkt 0.00 %loss
- With Patch -
# /testsuites/ethernet/bin/nuttcp -u -i -Ri50m 10.87.231.229
1.2891 MB / 1.00 sec = 10.8133 Mbps 0 / 1320 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8217 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8217 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2910 MB / 1.00 sec = 10.8298 Mbps 0 / 1322 ~drop/pkt 0.00 ~%loss
1.2910 MB / 1.00 sec = 10.8299 Mbps 0 / 1322 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8216 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8216 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2891 MB / 1.00 sec = 10.8135 Mbps 0 / 1320 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8216 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2910 MB / 1.00 sec = 10.8298 Mbps 0 / 1322 ~drop/pkt 0.00 ~%loss
12.9492 MB / 10.02 sec = 10.8461 Mbps 4 %TX 0 %RX 0 / 13260 drop/pkt 0.00
%loss
Also simulated heavy transmission consisting of 40 processes executed in parallel:
- 20 ping instances using packet size of 32768
- 20 dd instances creating a 50MB file each under the nfs rootfs
If any specific test scenario/application is required please do let me know...
Best Regards
Abraham
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Increase NET_SKB_PAD to 64 bytes
From: David Miller @ 2010-05-07 5:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, hadi, therbert, monstr, microblaze-uclinux
In-Reply-To: <1273037049.2304.7.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 05 May 2010 07:24:09 +0200
> eth_type_trans() & get_rps_cpus() currently need two 64bytes cache lines
> in packet to compute rxhash.
>
> Increasing NET_SKB_PAD from 32 to 64 reduces the need to one cache line
> only, and makes RPS faster.
>
> NET_IP_ALIGN(2) + ethernet_header(14) + IP_header(20/40) + ports(8)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
Seeing this made me go check who was overriding NET_IP_ALIGN or
NET_SKB_PAD.
The powerpc bits are legitimate, but the microblaze case is complete
bogosity. It defines NET_IP_ALIGN to the default (2) and sets
NET_SKB_PAD to L1_CACHE_BYTES which on microblaze is 4 and
significantly smaller than the default.
So I'm going to delete them in net-next-2.6 like so:
--------------------
microblaze: Kill NET_SKB_PAD and NET_IP_ALIGN overrides.
NET_IP_ALIGN defaults to 2, no need to override.
NET_SKB_PAD is now 64, which is much larger than microblaze's
L1_CACHE_SIZE so no need to override that either.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/microblaze/include/asm/system.h | 10 ----------
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/microblaze/include/asm/system.h b/arch/microblaze/include/asm/system.h
index 48c4f03..b1e2f07 100644
--- a/arch/microblaze/include/asm/system.h
+++ b/arch/microblaze/include/asm/system.h
@@ -97,14 +97,4 @@ extern struct dentry *of_debugfs_root;
#define arch_align_stack(x) (x)
-/*
- * MicroBlaze doesn't handle unaligned accesses in hardware.
- *
- * Based on this we force the IP header alignment in network drivers.
- * We also modify NET_SKB_PAD to be a cacheline in size, thus maintaining
- * cacheline alignment of buffers.
- */
-#define NET_IP_ALIGN 2
-#define NET_SKB_PAD L1_CACHE_BYTES
-
#endif /* _ASM_MICROBLAZE_SYSTEM_H */
--
1.7.0.4
^ permalink raw reply related
* Re: r8169 transmit queue time outs
From: Kyle McMartin @ 2010-05-07 4:51 UTC (permalink / raw)
To: Francois Romieu; +Cc: Kyle McMartin, netdev
In-Reply-To: <20100506201024.GA3541@electric-eye.fr.zoreil.com>
On Thu, May 06, 2010 at 10:10:24PM +0200, Francois Romieu wrote:
> Kyle McMartin <kmcmartin@redhat.com> :
> [...]
> > Some of our users have been seeing their r8169 cards just up and stop
> > transmitting packets pretty quickly after boot with recent kernels.
> [...]
> > Pid: 0, comm: swapper Not tainted 2.6.31.5-127.fc12.i686.PAE #1
>
> Can they upgrade to 2.6.32.11-99.fc12.i686 and try an out-of-tree build
> of the driver at http://userweb.kernel.org/~romieu/r8169/2.6.32.11-99.fc12/ ?
>
> It should be quite close to the current git kernel.
>
Thanks Francois, I've done a build for F-12 and F-13 with that driver
for the users, and updated the bugs with links to the builds.
I'll let you know if it helps things.
Thanks again, Kyle.
^ permalink raw reply
* Re: [PATCH] ipv6: udp: make short packet logging consistent with ipv4
From: David Miller @ 2010-05-07 4:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: bjorn, netdev
In-Reply-To: <1273157366.2853.10.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 May 2010 16:49:26 +0200
> Le jeudi 06 mai 2010 à 15:44 +0200, Bjørn Mork a écrit :
>> Adding addresses and ports to the short packet log message,
>> like ipv4/udp.c does it, makes these messages a lot more useful:
>>
>> [ 822.182450] UDPv6: short packet: From [2001:db8:ffb4:3::1]:47839 23715/178 to [2001:db8:ffb4:3:5054:ff:feff:200]:1234
>>
>> This requires us to drop logging in case pskb_may_pull() fails,
>> which also is consistent with ipv4/udp.c
>>
>> Signed-off-by: Bjørn Mork <bjorn@mork.no>
>> ---
>> net/ipv6/udp.c | 11 ++++++++---
>> 1 files changed, 8 insertions(+), 3 deletions(-)
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: udp: fix short packet and bad checksum logging
From: David Miller @ 2010-05-07 4:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: bjorn, netdev, stable
In-Reply-To: <1273157280.2853.9.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 May 2010 16:48:00 +0200
> Le jeudi 06 mai 2010 à 15:44 +0200, Bjørn Mork a écrit :
>> commit 2783ef23 moved the initialisation of saddr and daddr after
>> pskb_may_pull() to avoid a potential data corruption. Unfortunately
>> also placing it after the short packet and bad checksum error paths,
>> where these variables are used for logging. The result is bogus
>> output like
>>
>> [92238.389505] UDP: short packet: From 2.0.0.0:65535 23715/178 to 0.0.0.0:65535
>>
>> Moving the saddr and daddr initialisation above the error paths, while still
>> keeping it after the pskb_may_pull() to keep the fix from commit 2783ef23.
>>
>> Signed-off-by: Bjørn Mork <bjorn@mork.no>
>> Cc: stable@kernel.org
>> ---
>> net/ipv4/udp.c | 6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> Well done :)
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> To be backported to 2.6.29 and up kernels ;)
Applied to net-2.6 and queued up for -stable, thanks!
^ permalink raw reply
* Re: [v5 Patch 1/3] netpoll: add generic support for bridge and bonding devices
From: Cong Wang @ 2010-05-07 3:24 UTC (permalink / raw)
To: David Miller
Cc: mpm, linux-kernel, netdev, bridge, gospo, nhorman, jmoyer,
shemminger, bonding-devel, fubar
In-Reply-To: <20100506.004457.71584133.davem@davemloft.net>
On 05/06/10 15:44, David Miller wrote:
> From: Matt Mackall<mpm@selenic.com>
> Date: Wed, 05 May 2010 21:05:30 -0500
>
>> On Wed, 2010-05-05 at 04:11 -0400, Amerigo Wang wrote:
>>> V5:
>>> Fix coding style problems pointed by David.
>>
>> Aside from my concern about the policy of disabling netpoll on
>> bridges/bonds with only partial netpoll support, I don't have any
>> remaining issues with this. But I'll leave it to other folks to ack the
>> underlying driver bits for this series.
>
> Yes the partial support handling is a thorny issue.
>
> But this patch set makes things better than they were before, because
> support over such devices didn't work at all previously.
>
> So I'll toss these patches into net-next-2.6, thanks everyone!
Thank you, David.
^ permalink raw reply
* Re: ixgbe and mac-vlans problem
From: Ben Greear @ 2010-05-07 3:12 UTC (permalink / raw)
To: Tantilov, Emil S; +Cc: Arnd Bergmann, NetDev, Patrick McHardy
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FEA26A969@rrsmsx501.amr.corp.intel.com>
On 05/06/2010 05:06 PM, Tantilov, Emil S wrote:
> Ben Greear wrote:
>> On 05/06/2010 10:51 AM, Tantilov, Emil S wrote:
>>
>>> Hi Ben,
>>>
>>> We do have a patch in testing (see attached). It may not apply
>>> cleanly as it is on top of some other patches currently in
>>> validation. Let me know if it works for you.
>>
>> It wasn't difficult to backport this patch to 2.6.31.12....
>>
>> I just tested this on an 85998 NIC and 50 MAC-VLANs worked fine.
>>
>> The NIC doesn't show as PROMISC in any way I can detect, but I guess
>> it must actually be in PROMISC mode:
>
> Yes the interface is in promisc mode. The driver sets the FCTRL.UPE bit
> (unicast promisc mode) when the number of allowed rar_entries is exceeded.
Is there any way to get this setting from ethtool or similar? It would be nice
to know the actual PROMISC state of the NIC regardless of what user-space has or has not
configured.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox