* 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
* linux-next: build failure after merge of the suspend tree
From: Stephen Rothwell @ 2010-05-07 3:08 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-next, linux-kernel, Helmut Schaa, John W. Linville,
David Miller, netdev
Hi Rafael,
After merging the suspend tree, today's linux-next build (x86_64
allmodconfig) failed like this:
net/mac80211/scan.c: In function 'ieee80211_scan_state_decision':
net/mac80211/scan.c:510: error: implicit declaration of function 'pm_qos_requirement'
Caused by commit 62bad14fc6e0911a99882c261390968977d43283 ("PM QOS
update") from the suspend tree interacting with commit
df13cce53a7b28a81460e6bfc4857e9df4956141 ("mac80211: Improve software
scan timing") from the net tree.
I have added the following merge fixup patch and can carry it as
necessary:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 7 May 2010 13:02:54 +1000
Subject: [PATCH] wireless: update for pm_qos_requirement to pm_qos_request rename
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/mac80211/scan.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index e14c441..e1b0be7 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -510,7 +510,7 @@ static int ieee80211_scan_state_decision(struct ieee80211_local *local,
bad_latency = time_after(jiffies +
ieee80211_scan_get_channel_time(next_chan),
local->leave_oper_channel_time +
- usecs_to_jiffies(pm_qos_requirement(PM_QOS_NETWORK_LATENCY)));
+ usecs_to_jiffies(pm_qos_request(PM_QOS_NETWORK_LATENCY)));
listen_int_exceeded = time_after(jiffies +
ieee80211_scan_get_channel_time(next_chan),
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: virtio: put last_used and last_avail index into ring itself.
From: Rusty Russell @ 2010-05-07 3:05 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, s.hetze, Daniel Walker, Eric Dumazet
In-Reply-To: <20100506062755.GC8363@redhat.com>
On Thu, 6 May 2010 03:57:55 pm Michael S. Tsirkin wrote:
> On Thu, May 06, 2010 at 10:22:12AM +0930, Rusty Russell wrote:
> > On Wed, 5 May 2010 03:52:36 am Michael S. Tsirkin wrote:
> > > What do you think?
> >
> > I think everyone is settled on 128 byte cache lines for the forseeable
> > future, so it's not really an issue.
>
> You mean with 64 bit descriptors we will be bouncing a cache line
> between host and guest, anyway?
I'm confused by this entire thread.
Descriptors are 16 bytes. They are at the start, so presumably aligned to
cache boundaries.
Available ring follows that at 2 bytes per entry, so it's also packed nicely
into cachelines.
Then there's padding to page boundary. That puts us on a cacheline again
for the used ring; also 2 bytes per entry.
I don't see how any change in layout could be more cache friendly?
Rusty.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH 1/2] netdev/fec: fix performance impact from mdio poll operation
From: Bryan Wu @ 2010-05-07 2:27 UTC (permalink / raw)
To: davem, Sascha Hauer, Greg Ungerer, Amit Kucheria, netdev,
linux-kernel
In-Reply-To: <1273199239-11057-1-git-send-email-bryan.wu@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/546649
BugLink: http://bugs.launchpad.net/bugs/457878
After introducing phylib supporting, users experienced performace drop. That is
because of the mdio polling operation of phylib. Use msleep to replace the busy
waiting cpu_relax() and remove the warning message.
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
---
drivers/net/fec.c | 45 +++++++++++++++++++++------------------------
1 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 2b1651a..9c58f6b 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -203,7 +203,7 @@ static void fec_stop(struct net_device *dev);
#define FEC_MMFR_TA (2 << 16)
#define FEC_MMFR_DATA(v) (v & 0xffff)
-#define FEC_MII_TIMEOUT 10000
+#define FEC_MII_TIMEOUT 10
/* Transmitter timeout */
#define TX_TIMEOUT (2 * HZ)
@@ -611,13 +611,29 @@ spin_unlock:
/*
* NOTE: a MII transaction is during around 25 us, so polling it...
*/
-static int fec_enet_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
+static int fec_enet_mdio_poll(struct fec_enet_private *fep)
{
- struct fec_enet_private *fep = bus->priv;
int timeout = FEC_MII_TIMEOUT;
fep->mii_timeout = 0;
+ /* wait for end of transfer */
+ while (!(readl(fep->hwp + FEC_IEVENT) & FEC_ENET_MII)) {
+ msleep(1);
+ if (timeout-- < 0) {
+ fep->mii_timeout = 1;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+static int fec_enet_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
+{
+ struct fec_enet_private *fep = bus->priv;
+
+
/* clear MII end of transfer bit*/
writel(FEC_ENET_MII, fep->hwp + FEC_IEVENT);
@@ -626,15 +642,7 @@ static int fec_enet_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(regnum) |
FEC_MMFR_TA, fep->hwp + FEC_MII_DATA);
- /* wait for end of transfer */
- while (!(readl(fep->hwp + FEC_IEVENT) & FEC_ENET_MII)) {
- cpu_relax();
- if (timeout-- < 0) {
- fep->mii_timeout = 1;
- printk(KERN_ERR "FEC: MDIO read timeout\n");
- return -ETIMEDOUT;
- }
- }
+ fec_enet_mdio_poll(fep);
/* return value */
return FEC_MMFR_DATA(readl(fep->hwp + FEC_MII_DATA));
@@ -644,9 +652,6 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
u16 value)
{
struct fec_enet_private *fep = bus->priv;
- int timeout = FEC_MII_TIMEOUT;
-
- fep->mii_timeout = 0;
/* clear MII end of transfer bit*/
writel(FEC_ENET_MII, fep->hwp + FEC_IEVENT);
@@ -657,15 +662,7 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
FEC_MMFR_TA | FEC_MMFR_DATA(value),
fep->hwp + FEC_MII_DATA);
- /* wait for end of transfer */
- while (!(readl(fep->hwp + FEC_IEVENT) & FEC_ENET_MII)) {
- cpu_relax();
- if (timeout-- < 0) {
- fep->mii_timeout = 1;
- printk(KERN_ERR "FEC: MDIO write timeout\n");
- return -ETIMEDOUT;
- }
- }
+ fec_enet_mdio_poll(fep);
return 0;
}
--
1.7.0.1
^ permalink raw reply related
* [PATCH 2/2] netdev/fec: fix ifconfig eth0 down hang issue
From: Bryan Wu @ 2010-05-07 2:27 UTC (permalink / raw)
To: davem, Sascha Hauer, Greg Ungerer, Amit Kucheria, netdev,
linux-kernel
In-Reply-To: <1273199239-11057-1-git-send-email-bryan.wu@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/559065
In fec open/close function, we need to use phy_connect and phy_disconnect
operation before we start/stop phy. Otherwise it will cause system hang.
Only call fec_enet_mii_probe() in open function, because the first open
action will cause NULL pointer error.
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
---
drivers/net/fec.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 9c58f6b..af4243f 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -678,6 +678,8 @@ static int fec_enet_mii_probe(struct net_device *dev)
struct phy_device *phy_dev = NULL;
int phy_addr;
+ fep->phy_dev = NULL;
+
/* find the first phy */
for (phy_addr = 0; phy_addr < PHY_MAX_ADDR; phy_addr++) {
if (fep->mii_bus->phy_map[phy_addr]) {
@@ -708,6 +710,11 @@ static int fec_enet_mii_probe(struct net_device *dev)
fep->link = 0;
fep->full_duplex = 0;
+ printk(KERN_INFO "%s: Freescale FEC PHY driver [%s] "
+ "(mii_bus:phy_addr=%s, irq=%d)\n", dev->name,
+ fep->phy_dev->drv->name, dev_name(&fep->phy_dev->dev),
+ fep->phy_dev->irq);
+
return 0;
}
@@ -753,13 +760,8 @@ static int fec_enet_mii_init(struct platform_device *pdev)
if (mdiobus_register(fep->mii_bus))
goto err_out_free_mdio_irq;
- if (fec_enet_mii_probe(dev) != 0)
- goto err_out_unregister_bus;
-
return 0;
-err_out_unregister_bus:
- mdiobus_unregister(fep->mii_bus);
err_out_free_mdio_irq:
kfree(fep->mii_bus->irq);
err_out_free_mdiobus:
@@ -912,7 +914,12 @@ fec_enet_open(struct net_device *dev)
if (ret)
return ret;
- /* schedule a link state check */
+ /* Probe and connect to PHY when open the interface */
+ ret = fec_enet_mii_probe(dev);
+ if (ret) {
+ fec_enet_free_buffers(dev);
+ return ret;
+ }
phy_start(fep->phy_dev);
netif_start_queue(dev);
fep->opened = 1;
@@ -926,10 +933,12 @@ fec_enet_close(struct net_device *dev)
/* Don't know what to do yet. */
fep->opened = 0;
- phy_stop(fep->phy_dev);
netif_stop_queue(dev);
fec_stop(dev);
+ if (fep->phy_dev)
+ phy_disconnect(fep->phy_dev);
+
fec_enet_free_buffers(dev);
return 0;
@@ -1293,11 +1302,6 @@ fec_probe(struct platform_device *pdev)
if (ret)
goto failed_register;
- printk(KERN_INFO "%s: Freescale FEC PHY driver [%s] "
- "(mii_bus:phy_addr=%s, irq=%d)\n", ndev->name,
- fep->phy_dev->drv->name, dev_name(&fep->phy_dev->dev),
- fep->phy_dev->irq);
-
return 0;
failed_register:
--
1.7.0.1
^ permalink raw reply related
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