* Re: LRO disable warnings on kernel 2.6.38
From: Ben Hutchings @ 2011-03-18 15:40 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, Eric Dumazet, Neil Horman, Alexander Duyck
In-Reply-To: <1300446743.11985.317.camel@firesoul.comx.local>
On Fri, 2011-03-18 at 12:12 +0100, Jesper Dangaard Brouer wrote:
> Hi
>
> I'm seeing the LRO disable warnings using kernel 2.6.38:
>
> [ 8.664759] NET: Registered protocol family 10
> [ 8.838148] ADDRCONF(NETDEV_UP): eth71: link is not ready
> [ 8.872639] ------------[ cut here ]------------
> [ 8.872645] WARNING: at net/core/dev.c:1363 dev_disable_lro+0x7b/0x80()
> [ 8.872647] Hardware name: ProLiant DL370 G6
> [ 8.872648] Modules linked in: ipv6 nf_conntrack ip_tables loop i7core_edac edac_core ipmi_si ipmi_msghandler joydev hpilo pcspkr sg hpsa igb ata_piix netxen_nic dca [last unloaded: scsi_wait_scan]
> [ 8.872660] Pid: 2221, comm: sysctl Not tainted 2.6.38-comx04 #2
> [ 8.872662] Call Trace:
> [ 8.872671] [<ffffffff81056e1f>] ? warn_slowpath_common+0x7f/0xc0
> [ 8.872675] [<ffffffff81056e7a>] ? warn_slowpath_null+0x1a/0x20
> [ 8.872680] [<ffffffff8140c0ab>] ? dev_disable_lro+0x7b/0x80
> [ 8.872686] [<ffffffff81474f27>] ? devinet_sysctl_forward+0x147/0x180
> [ 8.872691] [<ffffffff811872f7>] ? proc_sys_call_handler+0x97/0xd0
> [ 8.872700] [<ffffffff81187344>] ? proc_sys_write+0x14/0x20
> [ 8.872704] [<ffffffff81124148>] ? vfs_write+0xc8/0x180
> [ 8.872707] [<ffffffff81124301>] ? sys_write+0x51/0x90
> [ 8.872712] [<ffffffff8100b8c2>] ? system_call_fastpath+0x16/0x1b
> [ 8.872714] ---[ end trace 6245283cb8d484cc ]---
>
> The strange part is that I didn't see this warning on my testlab and
> pre-prod servers. The warning is from the first production server,
> which got kernel 2.6.38 deployed this morning.
>
> The NIC driver is igb.
>
> The only difference in hardware between the production and
> pre-production server (which didn't show the warning), is the
> prod-server have an extra dual-port original Intel NIC, dev-named
> "eth71". And its just after the init of eth71, the warning occurs.
The warning is triggered if you enable forwarding or bridging on a
device without LRO, and the driver fails to disable LRO when requested.
You can see from the call chain that this is being triggered by a sysctl
write, not during registration.
> We usually use a 6 port NIC from Hotlava, which is based on the same
> chip 82576 and also uses the same igb driver.
>
> Intel orig NIC eth71
> albpd4:~# ethtool -i eth71
> driver: igb
> version: 2.1.0-k2
[...]
This appears to be the in-tree version of igb, which never enables LRO.
So I can't see how it could trigger this warning.
Are any other drivers being used for other interfaces?
And I'm sorry I forgot to include device & driver in this warning!
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Network performance with small packets - continued
From: Tom Lendacky @ 2011-03-18 15:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shirley Ma, Rusty Russell, Krishna Kumar2, David Miller, kvm,
netdev, steved
In-Reply-To: <201103101116.13212.tahm@linux.vnet.ibm.com>
On Thursday, March 10, 2011 11:16:11 am Tom Lendacky wrote:
> On Thursday, March 10, 2011 09:34:22 am Michael S. Tsirkin wrote:
> > On Thu, Mar 10, 2011 at 09:23:42AM -0600, Tom Lendacky wrote:
> > > On Thursday, March 10, 2011 12:54:58 am Michael S. Tsirkin wrote:
> > > > On Wed, Mar 09, 2011 at 05:25:11PM -0600, Tom Lendacky wrote:
> > > > > As for which CPU the interrupt gets pinned to, that doesn't matter
> > > > > - see below.
> > > >
> > > > So what hurts us the most is that the IRQ jumps between the VCPUs?
> > >
> > > Yes, it appears that allowing the IRQ to run on more than one vCPU
> > > hurts. Without the publish last used index patch, vhost keeps
> > > injecting an irq for every received packet until the guest eventually
> > > turns off notifications.
> >
> > Are you sure you see that? If yes publish used should help a lot.
>
> I definitely see that. I ran lockstat in the guest and saw the contention
> on the lock when the irq was able to run on either vCPU. Once the irq was
> pinned the contention disappeared. The publish used index patch should
> eliminate the extra irq injections and then the pinning or use of
> irqbalance shouldn't be required. I'm getting a kernel oops during boot
> with the publish last used patches that I pulled from the mailing list - I
> had to make some changes in order to get them to apply and compile and
> might not have done the right things. Can you re-spin that patchset
> against kvm.git?
>
Here are the results for the publish last used index patch (with the baseline
provided again for reference).
Here is the KVM baseline (average of six runs):
Txn Rate: 87,070.34 Txn/Sec, Pkt Rate: 172,992 Pkts/Sec
Exits: 148,444.58 Exits/Sec
TxCPU: 2.40% RxCPU: 99.35%
Virtio1-input Interrupts/Sec (CPU0/CPU1): 5,154/5,222
Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
Using the publish last used index w/o irqbalance (average of six runs):
Txn Rate: 112,180.10 Txn/Sec, Pkt Rate: 222,878.33 Pkts/Sec
Exits: 96,280.11 Exits/Sec
TxCPU: 1.14% RxCPU: 99.33%
Virtio1-input Interrupts/Sec (CPU0/CPU1): 3,400/3,400
Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
About a 29% increase over baseline.
Using the publish last used index w/ irqbalance (average of six runs):
Txn Rate: 110,891.12 Txn/Sec, Pkt Rate: 220,315.67 Pkts/Sec
Exits: 97,190.68 Exits/Sec
TxCPU: 1.10% RxCPU: 99.38%
Virtio1-input Interrupts/Sec (CPU0/CPU1): 7,040/0
Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
About a 27% increase over baseline.
Here is data from running without the publish last used index patch but with
irqbalance running (pinning results were near identical):
Txn Rate: 107,714.53 Txn/Sec, Pkt Rate: 214,006 Pkts/Sec
Exits: 121,050.45 Exits/Sec
TxCPU: 9.61% RxCPU: 99.45%
Virtio1-input Interrupts/Sec (CPU0/CPU1): 13,975/0
Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
The publish last used index patch provides a 3%-4% improvement while reducing
the exit rate and interrupt rate in the guest as well as reducing the
transmitting system CPU% quite dramatically.
> > > Because the irq injections end up overlapping we get contention on the
> > > irq_desc_lock_class lock. Here are some results using the "baseline"
> > > setup with irqbalance running.
> > >
> > > Txn Rate: 107,714.53 Txn/Sec, Pkt Rate: 214,006 Pkts/Sec
> > > Exits: 121,050.45 Exits/Sec
> > > TxCPU: 9.61% RxCPU: 99.45%
> > > Virtio1-input Interrupts/Sec (CPU0/CPU1): 13,975/0
> > > Virtio1-output Interrupts/Sec (CPU0/CPU1): 0/0
> > >
> > > About a 24% increase over baseline. Irqbalance essentially pinned the
> > > virtio irq to CPU0 preventing the irq lock contention and resulting in
> > > nice gains.
> >
> > OK, so we probably want some form of delayed free for TX
> > on top, and that should get us nice results already.
> >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Bug 16572] random panics in bridging on 2.6.34+
From: Herbert Xu @ 2011-03-18 15:27 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller, netdev; +Cc: bugzilla-daemon
In-Reply-To: <20110318081052.6ca134fb@nehalam>
On Fri, Mar 18, 2011 at 08:10:52AM -0700, Stephen Hemminger wrote:
> On Fri, 18 Mar 2011 13:49:03 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > https://bugzilla.kernel.org/show_bug.cgi?id=16572
>
> Herbert hasn't submitted the patch upstream.
Oops! Thanks for reminding me.
bridge: Reset IPCB when entering IP stack on NF_FORWARD
Whenever we enter the IP stack proper from bridge netfilter we
need to ensure that the skb is in a form the IP stack expects
it to be in.
The entry point on NF_FORWARD did not meet the requirements of
the IP stack, therefore leading to potential crashes/panics.
This patch fixes the problem.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 865fd76..7e9b167 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -752,6 +752,9 @@ static unsigned int br_nf_forward_ip(unsigned int hook, struct sk_buff *skb,
nf_bridge->mask |= BRNF_PKT_TYPE;
}
+ if (br_parse_ip_options(skb))
+ return NF_DROP;
+
/* The physdev module checks on this */
nf_bridge->mask |= BRNF_BRIDGED;
nf_bridge->physoutdev = skb->dev;
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH 01/36] net,rcu: convert call_rcu(free_dm_hw_stat) to kfree_rcu()
From: Neil Horman @ 2011-03-18 15:24 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Paul E. McKenney, Ingo Molnar, Jens Axboe, Robert Love,
James E.J. Bottomley, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Eric Dumazet, Stephen Hemminger, Tejun Heo,
Jarek Poplawski, linux-kernel, devel, linux-scsi, netdev
In-Reply-To: <4D82D3FF.2080303@cn.fujitsu.com>
On Fri, Mar 18, 2011 at 11:39:43AM +0800, Lai Jiangshan wrote:
>
>
> The rcu callback free_dm_hw_stat() just calls a kfree(),
> so we use kfree_rcu() instead of the call_rcu(free_dm_hw_stat).
>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
> ---
> net/core/drop_monitor.c | 12 ++----------
> 1 files changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
> index 36e603c..32365e7 100644
> --- a/net/core/drop_monitor.c
> +++ b/net/core/drop_monitor.c
> @@ -207,14 +207,6 @@ static void trace_napi_poll_hit(void *ignore, struct napi_struct *napi)
> rcu_read_unlock();
> }
>
> -
> -static void free_dm_hw_stat(struct rcu_head *head)
> -{
> - struct dm_hw_stat_delta *n;
> - n = container_of(head, struct dm_hw_stat_delta, rcu);
> - kfree(n);
> -}
> -
> static int set_all_monitor_traces(int state)
> {
> int rc = 0;
> @@ -245,7 +237,7 @@ static int set_all_monitor_traces(int state)
> list_for_each_entry_safe(new_stat, temp, &hw_stats_list, list) {
> if (new_stat->dev == NULL) {
> list_del_rcu(&new_stat->list);
> - call_rcu(&new_stat->rcu, free_dm_hw_stat);
> + kfree_rcu(new_stat, rcu);
> }
> }
> break;
> @@ -314,7 +306,7 @@ static int dropmon_net_event(struct notifier_block *ev_block,
> new_stat->dev = NULL;
> if (trace_state == TRACE_OFF) {
> list_del_rcu(&new_stat->list);
> - call_rcu(&new_stat->rcu, free_dm_hw_stat);
> + kfree_rcu(new_stat, rcu);
> break;
> }
> }
> --
> 1.7.4
>
^ permalink raw reply
* Re: LRO disable warnings on kernel 2.6.38
From: Stephen Hemminger @ 2011-03-18 15:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ben Hutchings, Jesper Dangaard Brouer, netdev, Neil Horman,
Alexander Duyck
In-Reply-To: <1300458784.2888.138.camel@edumazet-laptop>
On Fri, 18 Mar 2011 15:33:04 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 18 mars 2011 à 14:17 +0000, Ben Hutchings a écrit :
>
> > WARN is correct as this is a driver bug. But I agree that the
> > device/driver ID should be included.
>
> stack trace gives absolutely no useful indication here.
>
> Bug is in driver, yet we dump information on core network stack ?
>
> pr_err() is an error indication, not a warning by the way ;)
The advantage of WARN is that it doesn't get ignored and shows
up in kernel oops. But agreed it should print out as much device
info as possible to finger the broken device driver.
^ permalink raw reply
* Re: LRO disable warnings on kernel 2.6.38
From: Eric Dumazet @ 2011-03-18 14:33 UTC (permalink / raw)
To: Ben Hutchings
Cc: Jesper Dangaard Brouer, netdev, Neil Horman, Alexander Duyck
In-Reply-To: <1300457877.26693.53.camel@localhost>
Le vendredi 18 mars 2011 à 14:17 +0000, Ben Hutchings a écrit :
> WARN is correct as this is a driver bug. But I agree that the
> device/driver ID should be included.
stack trace gives absolutely no useful indication here.
Bug is in driver, yet we dump information on core network stack ?
pr_err() is an error indication, not a warning by the way ;)
^ permalink raw reply
* Re: SO_BINDTODEVICE inconsistency between IPv4 and IPv6
From: Brian Haley @ 2011-03-18 14:31 UTC (permalink / raw)
To: David Woodhouse
Cc: netdev, Yuniverg, Michael, Yedvab, Nadav, YOSHIFUJI Hideaki
In-Reply-To: <1300438473.16342.18.camel@macbook.infradead.org>
On 03/18/2011 04:54 AM, David Woodhouse wrote:
> On Thu, 2011-03-17 at 21:26 -0400, Brian Haley wrote:
>> Hmm, "connection refused", do you have any iptables rules installed? Connecting
>> to a local global address worked fine for me on 2.6.32-30 using a home-grown
>> test app.
>
> Thanks for looking at this.
>
> Just to confirm... after your server does SO_BINDTODEVICE to 'lo', your
> clients on the same host can make a successful connection to global IPv6
> addresses which are assigned to the *other* interfaces?
>
> Can you show your version of the test app, and your results? What kernel
> is this on?
Sorry, I just re-ran my test again and noticed the SO_BINDTODEVICE failed,
since I was running it as myself, not root, so I see the same behavior as
you. I'm not sure if this is a bug per-se, and there is this comment
in ip6_rcv() pointing towards this:
/*
* Store incoming device index. When the packet will
* be queued, we cannot refer to skb->dev anymore.
*
* BTW, when we send a packet for our own local address on a
* non-loopback interface (e.g. ethX), it is being delivered
* via the loopback interface (lo) here; skb->dev = loopback_dev.
* It, however, should be considered as if it is being
* arrived via the sending interface (ethX), because of the
* nature of scoping architecture. --yoshfuji
*/
IP6CB(skb)->iif = skb_dst(skb) ? ip6_dst_idev(skb_dst(skb))->dev->ifindex : dev->ifindex;
That's probably why it's not matching.
I think Yoshifuji would be the best one to ask, cc'd.
-Brian
^ permalink raw reply
* Re: LRO disable warnings on kernel 2.6.38
From: Ben Hutchings @ 2011-03-18 14:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jesper Dangaard Brouer, netdev, Neil Horman, Alexander Duyck
In-Reply-To: <1300453519.2888.118.camel@edumazet-laptop>
On Fri, 2011-03-18 at 14:05 +0100, Eric Dumazet wrote:
> Le vendredi 18 mars 2011 à 12:12 +0100, Jesper Dangaard Brouer a écrit :
> > Hi
> >
> > I'm seeing the LRO disable warnings using kernel 2.6.38:
> >
> > [ 8.664759] NET: Registered protocol family 10
> > [ 8.838148] ADDRCONF(NETDEV_UP): eth71: link is not ready
> > [ 8.872639] ------------[ cut here ]------------
> > [ 8.872645] WARNING: at net/core/dev.c:1363 dev_disable_lro+0x7b/0x80()
> > [ 8.872647] Hardware name: ProLiant DL370 G6
> > [ 8.872648] Modules linked in: ipv6 nf_conntrack ip_tables loop i7core_edac edac_core ipmi_si ipmi_msghandler joydev hpilo pcspkr sg hpsa igb ata_piix netxen_nic dca [last unloaded: scsi_wait_scan]
> > [ 8.872660] Pid: 2221, comm: sysctl Not tainted 2.6.38-comx04 #2
> > [ 8.872662] Call Trace:
> > [ 8.872671] [<ffffffff81056e1f>] ? warn_slowpath_common+0x7f/0xc0
> > [ 8.872675] [<ffffffff81056e7a>] ? warn_slowpath_null+0x1a/0x20
> > [ 8.872680] [<ffffffff8140c0ab>] ? dev_disable_lro+0x7b/0x80
> > [ 8.872686] [<ffffffff81474f27>] ? devinet_sysctl_forward+0x147/0x180
> > [ 8.872691] [<ffffffff811872f7>] ? proc_sys_call_handler+0x97/0xd0
> > [ 8.872700] [<ffffffff81187344>] ? proc_sys_write+0x14/0x20
> > [ 8.872704] [<ffffffff81124148>] ? vfs_write+0xc8/0x180
> > [ 8.872707] [<ffffffff81124301>] ? sys_write+0x51/0x90
> > [ 8.872712] [<ffffffff8100b8c2>] ? system_call_fastpath+0x16/0x1b
> > [ 8.872714] ---[ end trace 6245283cb8d484cc ]---
> >
> > The strange part is that I didn't see this warning on my testlab and
> > pre-prod servers. The warning is from the first production server,
> > which got kernel 2.6.38 deployed this morning.
> >
> > The NIC driver is igb.
> >
> > The only difference in hardware between the production and
> > pre-production server (which didn't show the warning), is the
> > prod-server have an extra dual-port original Intel NIC, dev-named
> > "eth71". And its just after the init of eth71, the warning occurs.
> >
> > We usually use a 6 port NIC from Hotlava, which is based on the same
> > chip 82576 and also uses the same igb driver.
> >
> > Intel orig NIC eth71
> > albpd4:~# ethtool -i eth71
> > driver: igb
> > version: 2.1.0-k2
> > firmware-version: 1.2-1
> > bus-info: 0000:21:00.0
> >
> > Hotlava Intel chip based NIC eth51:
> > albpd4:~# ethtool -i eth51
> > driver: igb
> > version: 2.1.0-k2
> > firmware-version: 1.2-1
> > bus-info: 0000:1d:00.1
> >
> > I don't understand why I don't see the warning on my pre-prod server,
> > which only have the Hotlava NIC?!?
> >
>
> Hmm, WARN_ON() message is not very nice in this case I'm afraid, we dont
> even know offender
WARN is correct as this is a driver bug. But I agree that the
device/driver ID should be included.
Ben.
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0b88eba..571ab70 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1361,7 +1361,8 @@ void dev_disable_lro(struct net_device *dev)
> dev->ethtool_ops->set_flags(dev, flags);
> }
> }
> - WARN_ON(dev->features & NETIF_F_LRO);
> + if (dev->features & NETIF_F_LRO)
> + netdev_err(dev, "Could not disable LRO\n");
> }
> EXPORT_SYMBOL(dev_disable_lro);
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] NET: smsc95xx: don't use stack for async writes to the device
From: Marc Zyngier @ 2011-03-18 13:53 UTC (permalink / raw)
To: netdev; +Cc: Steve Glendinning
The set_multicast operation performs asynchronous writes to the
device, with some addresses pointing to the stack. Bad things may
happen, and this is trapped CONFIG_DMA_API_DEBUG:
[ 5.237762] WARNING: at /build/buildd/linux-linaro-omap-2.6.38/lib/dma-debug.c:867 check_for_stack+0xd4/0x100()
[ 5.237792] ehci-omap ehci-omap.0: DMA-API: device driver maps memory fromstack [addr=d9c77dec]
[ 5.237792] Modules linked in: smsc95xx(+) usbnet twl6030_usb twl4030_pwrbutton leds_gpio omap_wdt omap2_mcspi
[ 5.237854] [<c006d618>] (unwind_backtrace+0x0/0xf8) from [<c00a6a14>] (warn_slowpath_common+0x54/0x64)
[ 5.237884] [<c00a6a14>] (warn_slowpath_common+0x54/0x64) from [<c00a6ab8>] (warn_slowpath_fmt+0x30/0x40)
[ 5.237915] [<c00a6ab8>] (warn_slowpath_fmt+0x30/0x40) from [<c034e9d8>] (check_for_stack+0xd4/0x100)
[ 5.237915] [<c034e9d8>] (check_for_stack+0xd4/0x100) from [<c034fea8>] (debug_dma_map_page+0xb4/0xdc)
[ 5.237976] [<c034fea8>] (debug_dma_map_page+0xb4/0xdc) from [<c04242f0>] (map_urb_for_dma+0x26c/0x304)
[ 5.237976] [<c04242f0>] (map_urb_for_dma+0x26c/0x304) from [<c0424594>] (usb_hcd_submit_urb+0x78/0x19c)
[ 5.238037] [<c0424594>] (usb_hcd_submit_urb+0x78/0x19c) from [<bf049c5c>] (smsc95xx_write_reg_async+0xb4/0x130 [smsc95xx])
[ 5.238067] [<bf049c5c>] (smsc95xx_write_reg_async+0xb4/0x130 [smsc95xx]) from [<bf049dd4>] (smsc95xx_set_multicast+0xfc/0x148 [smsc95xx])
[ 5.238098] [<bf049dd4>] (smsc95xx_set_multicast+0xfc/0x148 [smsc95xx]) from [<bf04a118>] (smsc95xx_reset+0x2f8/0x68c [smsc95xx])
[ 5.238128] [<bf04a118>] (smsc95xx_reset+0x2f8/0x68c [smsc95xx]) from [<bf04a8cc>] (smsc95xx_bind+0xcc/0x188 [smsc95xx])
[ 5.238159] [<bf04a8cc>] (smsc95xx_bind+0xcc/0x188 [smsc95xx]) from [<bf03ef1c>] (usbnet_probe+0x204/0x4c4 [usbnet])
[ 5.238220] [<bf03ef1c>] (usbnet_probe+0x204/0x4c4 [usbnet]) from [<c0429078>] (usb_probe_interface+0xe4/0x1c4)
[ 5.238250] [<c0429078>] (usb_probe_interface+0xe4/0x1c4) from [<c03a8770>] (really_probe+0x64/0x160)
[ 5.238250] [<c03a8770>] (really_probe+0x64/0x160) from [<c03a8a30>] (driver_probe_device+0x48/0x60)
[ 5.238281] [<c03a8a30>] (driver_probe_device+0x48/0x60) from [<c03a8ad4>] (__driver_attach+0x8c/0x90)
[ 5.238311] [<c03a8ad4>] (__driver_attach+0x8c/0x90) from [<c03a7b24>] (bus_for_each_dev+0x50/0x7c)
[ 5.238311] [<c03a7b24>] (bus_for_each_dev+0x50/0x7c) from [<c03a82ec>] (bus_add_driver+0x190/0x250)
[ 5.238311] [<c03a82ec>] (bus_add_driver+0x190/0x250) from [<c03a8cf8>] (driver_register+0x78/0x13c)
[ 5.238433] [<c03a8cf8>] (driver_register+0x78/0x13c) from [<c0428040>] (usb_register_driver+0x78/0x13c)
[ 5.238464] [<c0428040>] (usb_register_driver+0x78/0x13c) from [<c005b680>] (do_one_initcall+0x34/0x188)
[ 5.238494] [<c005b680>] (do_one_initcall+0x34/0x188) from [<c00e11f0>] (sys_init_module+0xb0/0x1c0)
[ 5.238525] [<c00e11f0>] (sys_init_module+0xb0/0x1c0) from [<c0065c40>] (ret_fast_syscall+0x0/0x30)
Move the two offenders to the private structure which is kmalloc-ed,
and thus safe.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Steve Glendinning <steve.glendinning@smsc.com>
---
drivers/net/usb/smsc95xx.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index bc86f4b..727874d 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -49,6 +49,8 @@
struct smsc95xx_priv {
u32 mac_cr;
+ u32 hash_hi;
+ u32 hash_lo;
spinlock_t mac_cr_lock;
bool use_tx_csum;
bool use_rx_csum;
@@ -370,10 +372,11 @@ static void smsc95xx_set_multicast(struct net_device *netdev)
{
struct usbnet *dev = netdev_priv(netdev);
struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);
- u32 hash_hi = 0;
- u32 hash_lo = 0;
unsigned long flags;
+ pdata->hash_hi = 0;
+ pdata->hash_lo = 0;
+
spin_lock_irqsave(&pdata->mac_cr_lock, flags);
if (dev->net->flags & IFF_PROMISC) {
@@ -394,13 +397,13 @@ static void smsc95xx_set_multicast(struct net_device *netdev)
u32 bitnum = smsc95xx_hash(ha->addr);
u32 mask = 0x01 << (bitnum & 0x1F);
if (bitnum & 0x20)
- hash_hi |= mask;
+ pdata->hash_hi |= mask;
else
- hash_lo |= mask;
+ pdata->hash_lo |= mask;
}
netif_dbg(dev, drv, dev->net, "HASHH=0x%08X, HASHL=0x%08X\n",
- hash_hi, hash_lo);
+ pdata->hash_hi, pdata->hash_lo);
} else {
netif_dbg(dev, drv, dev->net, "receive own packets only\n");
pdata->mac_cr &=
@@ -410,8 +413,8 @@ static void smsc95xx_set_multicast(struct net_device *netdev)
spin_unlock_irqrestore(&pdata->mac_cr_lock, flags);
/* Initiate async writes, as we can't wait for completion here */
- smsc95xx_write_reg_async(dev, HASHH, &hash_hi);
- smsc95xx_write_reg_async(dev, HASHL, &hash_lo);
+ smsc95xx_write_reg_async(dev, HASHH, &pdata->hash_hi);
+ smsc95xx_write_reg_async(dev, HASHL, &pdata->hash_lo);
smsc95xx_write_reg_async(dev, MAC_CR, &pdata->mac_cr);
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 35/36] net/mac80211,rcu: convert call_rcu(work_free_rcu) to kfree_rcu()
From: John W. Linville @ 2011-03-18 13:51 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Paul E. McKenney, Ingo Molnar, Johannes Berg, David S. Miller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D82DC17.2090106-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
On Fri, Mar 18, 2011 at 12:14:15PM +0800, Lai Jiangshan wrote:
>
>
> The rcu callback work_free_rcu() just calls a kfree(),
> so we use kfree_rcu() instead of the call_rcu(work_free_rcu).
>
> Signed-off-by: Lai Jiangshan <laijs-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
ACK -- seems fine to me...
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] virtio_net: remove send completion interrupts and avoid TX queue overrun through packet drop
From: Herbert Xu @ 2011-03-18 13:33 UTC (permalink / raw)
To: Shirley Ma; +Cc: mst, rusty, davem, kvm, netdev
In-Reply-To: <1300320775.3255.34.camel@localhost.localdomain>
Shirley Ma <mashirle@us.ibm.com> wrote:
>
> + /* Drop packet instead of stop queue for better performance */
I would like to see some justification as to why this is the right
way to go and not just papering over the real problem.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH net-next-2.6 4/6] be2net: remove redundant code in be_worker()
From: Sathya Perla @ 2011-03-18 13:21 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-4-git-send-email-sathya.perla@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 6be06df..0efa639 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1863,6 +1863,9 @@ static void be_worker(struct work_struct *work)
struct be_rx_obj *rxo;
int i;
+ if (!adapter->ue_detected && !lancer_chip(adapter))
+ be_detect_dump_ue(adapter);
+
/* when interrupts are not yet enabled, just reap any pending
* mcc completions */
if (!netif_running(adapter->netdev)) {
@@ -1875,9 +1878,6 @@ static void be_worker(struct work_struct *work)
be_cq_notify(adapter, mcc_obj->cq.id, false, mcc_compl);
}
- if (!adapter->ue_detected && !lancer_chip(adapter))
- be_detect_dump_ue(adapter);
-
goto reschedule;
}
@@ -1895,8 +1895,6 @@ static void be_worker(struct work_struct *work)
be_post_rx_frags(rxo, GFP_KERNEL);
}
}
- if (!adapter->ue_detected && !lancer_chip(adapter))
- be_detect_dump_ue(adapter);
reschedule:
schedule_delayed_work(&adapter->work, msecs_to_jiffies(1000));
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 6/6] be2net: remove one useless line
From: Sathya Perla @ 2011-03-18 13:21 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-6-git-send-email-sathya.perla@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index acd53e6..cfe986f 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -2325,7 +2325,6 @@ static int be_setup(struct be_adapter *adapter)
return 0;
- be_mcc_queues_destroy(adapter);
rx_qs_destroy:
be_rx_queues_destroy(adapter);
tx_qs_destroy:
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 5/6] be2net: cancel be_worker() in be_shutdown() even when i/f is down
From: Sathya Perla @ 2011-03-18 13:21 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-5-git-send-email-sathya.perla@emulex.com>
As the be_worker() workqueue is scheduled in be_probe() it must
be canceled unconditionally in be_shutdown().
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 0efa639..acd53e6 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -3150,8 +3150,7 @@ static void be_shutdown(struct pci_dev *pdev)
struct be_adapter *adapter = pci_get_drvdata(pdev);
struct net_device *netdev = adapter->netdev;
- if (netif_running(netdev))
- cancel_delayed_work_sync(&adapter->work);
+ cancel_delayed_work_sync(&adapter->work);
netif_device_detach(netdev);
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 3/6] be2net: parse vid and vtm fields of rx-compl only if vlanf bit is set
From: Sathya Perla @ 2011-03-18 13:20 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-3-git-send-email-sathya.perla@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 34 +++++++++++++++++++++++-----------
1 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 18c6da4..6be06df 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1096,8 +1096,12 @@ static void be_parse_rx_compl_v1(struct be_adapter *adapter,
AMAP_GET_BITS(struct amap_eth_rx_compl_v1, numfrags, compl);
rxcp->pkt_type =
AMAP_GET_BITS(struct amap_eth_rx_compl_v1, cast_enc, compl);
- rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vtm, compl);
- rxcp->vid = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vlan_tag, compl);
+ if (rxcp->vlanf) {
+ rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vtm,
+ compl);
+ rxcp->vid = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vlan_tag,
+ compl);
+ }
}
static void be_parse_rx_compl_v0(struct be_adapter *adapter,
@@ -1122,8 +1126,12 @@ static void be_parse_rx_compl_v0(struct be_adapter *adapter,
AMAP_GET_BITS(struct amap_eth_rx_compl_v0, numfrags, compl);
rxcp->pkt_type =
AMAP_GET_BITS(struct amap_eth_rx_compl_v0, cast_enc, compl);
- rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vtm, compl);
- rxcp->vid = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vlan_tag, compl);
+ if (rxcp->vlanf) {
+ rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vtm,
+ compl);
+ rxcp->vid = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vlan_tag,
+ compl);
+ }
}
static struct be_rx_compl_info *be_rx_compl_get(struct be_rx_obj *rxo)
@@ -1145,15 +1153,19 @@ static struct be_rx_compl_info *be_rx_compl_get(struct be_rx_obj *rxo)
else
be_parse_rx_compl_v0(adapter, compl, rxcp);
- /* vlanf could be wrongly set in some cards. ignore if vtm is not set */
- if ((adapter->function_mode & 0x400) && !rxcp->vtm)
- rxcp->vlanf = 0;
+ if (rxcp->vlanf) {
+ /* vlanf could be wrongly set in some cards.
+ * ignore if vtm is not set */
+ if ((adapter->function_mode & 0x400) && !rxcp->vtm)
+ rxcp->vlanf = 0;
- if (!lancer_chip(adapter))
- rxcp->vid = swab16(rxcp->vid);
+ if (!lancer_chip(adapter))
+ rxcp->vid = swab16(rxcp->vid);
- if ((adapter->pvid == rxcp->vid) && !adapter->vlan_tag[rxcp->vid])
- rxcp->vlanf = 0;
+ if ((adapter->pvid == rxcp->vid) &&
+ !adapter->vlan_tag[rxcp->vid])
+ rxcp->vlanf = 0;
+ }
/* As the compl has been parsed, reset it; we wont touch it again */
compl->dw[offsetof(struct amap_eth_rx_compl_v1, valid) / 32] = 0;
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 2/6] be2net: fix to not drop unfiltered vlan pkts
From: Sathya Perla @ 2011-03-18 13:20 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-2-git-send-email-sathya.perla@emulex.com>
When the device is in promiscuous mode, the driver can receive vlan packets
(tag is always stripped by card) even when there is no vlan configuration.
Such packets must be sent to the stack and not dropped.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 97c5167..18c6da4 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1013,15 +1013,10 @@ static void be_rx_compl_process(struct be_adapter *adapter,
skb->truesize = skb->len + sizeof(struct sk_buff);
skb->protocol = eth_type_trans(skb, adapter->netdev);
- if (unlikely(rxcp->vlanf)) {
- if (!adapter->vlan_grp || adapter->vlans_added == 0) {
- kfree_skb(skb);
- return;
- }
+ if (unlikely(rxcp->vlanf))
vlan_hwaccel_receive_skb(skb, adapter->vlan_grp, rxcp->vid);
- } else {
+ else
netif_receive_skb(skb);
- }
}
/* Process the RX completion indicated by rxcp when GRO is enabled */
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 0/6] be2net: patch series
From: Sathya Perla @ 2011-03-18 13:20 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
Please apply. Thanks!
Sathya Perla(6):
be2net: refactor code that decides adapter->num_rx_queues
be2net: fix to not drop unfiltered vlan pkts
be2net: parse vid and vtm fields of rx-compl only if vlanf bit is set
be2net: remove redundant code in be_worker()
be2net: cancel be_worker() in be_shutdown() even when i/f is down
be2net: remove one useless line
drivers/net/benet/be.h | 8 ++-
drivers/net/benet/be_main.c | 119 ++++++++++++++++++++++--------------------
2 files changed, 67 insertions(+), 60 deletions(-)
^ permalink raw reply
* [PATCH net-next-2.6 1/6] be2net: refactor code that decides adapter->num_rx_queues
From: Sathya Perla @ 2011-03-18 13:20 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-1-git-send-email-sathya.perla@emulex.com>
The code has been refactored to not set num_rx_qs inside be_enable_msix().
num_rx_qs is now set at the time of queue creation based on the number of
available msix vectors.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be.h | 8 +++--
drivers/net/benet/be_main.c | 64 ++++++++++++++++++++++---------------------
2 files changed, 38 insertions(+), 34 deletions(-)
diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
index f803c58..3937bca 100644
--- a/drivers/net/benet/be.h
+++ b/drivers/net/benet/be.h
@@ -84,7 +84,8 @@ static inline char *nic_name(struct pci_dev *pdev)
#define MCC_CQ_LEN 256
#define MAX_RSS_QS 4 /* BE limit is 4 queues/port */
-#define BE_MAX_MSIX_VECTORS (MAX_RSS_QS + 1 + 1)/* RSS qs + 1 def Rx + Tx */
+#define MAX_RX_QS (MAX_RSS_QS + 1) /* RSS qs + 1 def Rx */
+#define BE_MAX_MSIX_VECTORS (MAX_RX_QS + 1)/* RX + TX */
#define BE_NAPI_WEIGHT 64
#define MAX_RX_POST BE_NAPI_WEIGHT /* Frags posted at a time */
#define RX_FRAGS_REFILL_WM (RX_Q_LEN - MAX_RX_POST)
@@ -276,7 +277,7 @@ struct be_adapter {
spinlock_t mcc_cq_lock;
struct msix_entry msix_entries[BE_MAX_MSIX_VECTORS];
- bool msix_enabled;
+ u32 num_msix_vec;
bool isr_registered;
/* TX Rings */
@@ -287,7 +288,7 @@ struct be_adapter {
u32 cache_line_break[8];
/* Rx rings */
- struct be_rx_obj rx_obj[MAX_RSS_QS + 1]; /* one default non-rss Q */
+ struct be_rx_obj rx_obj[MAX_RX_QS];
u32 num_rx_qs;
u32 big_page_size; /* Compounded page size shared by rx wrbs */
@@ -351,6 +352,7 @@ struct be_adapter {
extern const struct ethtool_ops be_ethtool_ops;
+#define msix_enabled(adapter) (adapter->num_msix_vec > 0)
#define tx_stats(adapter) (&adapter->tx_stats)
#define rx_stats(rxo) (&rxo->stats)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index a71163f..97c5167 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1567,12 +1567,31 @@ static void be_rx_queues_destroy(struct be_adapter *adapter)
}
}
+static u32 be_num_rxqs_want(struct be_adapter *adapter)
+{
+ if (multi_rxq && (adapter->function_caps & BE_FUNCTION_CAPS_RSS) &&
+ !adapter->sriov_enabled && !(adapter->function_mode & 0x400)) {
+ return 1 + MAX_RSS_QS; /* one default non-RSS queue */
+ } else {
+ dev_warn(&adapter->pdev->dev,
+ "No support for multiple RX queues\n");
+ return 1;
+ }
+}
+
static int be_rx_queues_create(struct be_adapter *adapter)
{
struct be_queue_info *eq, *q, *cq;
struct be_rx_obj *rxo;
int rc, i;
+ adapter->num_rx_qs = min(be_num_rxqs_want(adapter),
+ msix_enabled(adapter) ?
+ adapter->num_msix_vec - 1 : 1);
+ if (adapter->num_rx_qs != MAX_RX_QS)
+ dev_warn(&adapter->pdev->dev,
+ "Can create only %d RX queues", adapter->num_rx_qs);
+
adapter->big_page_size = (1 << get_order(rx_frag_size)) * PAGE_SIZE;
for_all_rx_queues(adapter, rxo, i) {
rxo->adapter = adapter;
@@ -1878,51 +1897,35 @@ reschedule:
static void be_msix_disable(struct be_adapter *adapter)
{
- if (adapter->msix_enabled) {
+ if (msix_enabled(adapter)) {
pci_disable_msix(adapter->pdev);
- adapter->msix_enabled = false;
- }
-}
-
-static int be_num_rxqs_get(struct be_adapter *adapter)
-{
- if (multi_rxq && (adapter->function_caps & BE_FUNCTION_CAPS_RSS) &&
- !adapter->sriov_enabled && !(adapter->function_mode & 0x400)) {
- return 1 + MAX_RSS_QS; /* one default non-RSS queue */
- } else {
- dev_warn(&adapter->pdev->dev,
- "No support for multiple RX queues\n");
- return 1;
+ adapter->num_msix_vec = 0;
}
}
static void be_msix_enable(struct be_adapter *adapter)
{
#define BE_MIN_MSIX_VECTORS (1 + 1) /* Rx + Tx */
- int i, status;
+ int i, status, num_vec;
- adapter->num_rx_qs = be_num_rxqs_get(adapter);
+ num_vec = be_num_rxqs_want(adapter) + 1;
- for (i = 0; i < (adapter->num_rx_qs + 1); i++)
+ for (i = 0; i < num_vec; i++)
adapter->msix_entries[i].entry = i;
- status = pci_enable_msix(adapter->pdev, adapter->msix_entries,
- adapter->num_rx_qs + 1);
+ status = pci_enable_msix(adapter->pdev, adapter->msix_entries, num_vec);
if (status == 0) {
goto done;
} else if (status >= BE_MIN_MSIX_VECTORS) {
+ num_vec = status;
if (pci_enable_msix(adapter->pdev, adapter->msix_entries,
- status) == 0) {
- adapter->num_rx_qs = status - 1;
- dev_warn(&adapter->pdev->dev,
- "Could alloc only %d MSIx vectors. "
- "Using %d RX Qs\n", status, adapter->num_rx_qs);
+ num_vec) == 0)
goto done;
- }
}
return;
done:
- adapter->msix_enabled = true;
+ adapter->num_msix_vec = num_vec;
+ return;
}
static void be_sriov_enable(struct be_adapter *adapter)
@@ -2003,8 +2006,7 @@ err_msix:
err:
dev_warn(&adapter->pdev->dev,
"MSIX Request IRQ failed - err %d\n", status);
- pci_disable_msix(adapter->pdev);
- adapter->msix_enabled = false;
+ be_msix_disable(adapter);
return status;
}
@@ -2013,7 +2015,7 @@ static int be_irq_register(struct be_adapter *adapter)
struct net_device *netdev = adapter->netdev;
int status;
- if (adapter->msix_enabled) {
+ if (msix_enabled(adapter)) {
status = be_msix_register(adapter);
if (status == 0)
goto done;
@@ -2046,7 +2048,7 @@ static void be_irq_unregister(struct be_adapter *adapter)
return;
/* INTx */
- if (!adapter->msix_enabled) {
+ if (!msix_enabled(adapter)) {
free_irq(netdev->irq, adapter);
goto done;
}
@@ -2088,7 +2090,7 @@ static int be_close(struct net_device *netdev)
be_cq_notify(adapter, rxo->cq.id, false, 0);
}
- if (adapter->msix_enabled) {
+ if (msix_enabled(adapter)) {
vec = be_msix_vec_get(adapter, tx_eq);
synchronize_irq(vec);
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH 2/2] virtio_net: remove send completion interrupts and avoid TX queue overrun through packet drop
From: Michael S. Tsirkin @ 2011-03-18 13:15 UTC (permalink / raw)
To: Shirley Ma; +Cc: Rusty Russell, David Miller, kvm, netdev, Herbert Xu
In-Reply-To: <1300418927.3255.62.camel@localhost.localdomain>
On Thu, Mar 17, 2011 at 08:28:47PM -0700, Shirley Ma wrote:
> On Thu, 2011-03-17 at 08:18 -0700, Shirley Ma wrote:
> > On Thu, 2011-03-17 at 07:02 +0200, Michael S. Tsirkin wrote:
> > > So, this just tries to make sure there's enough space for
> > > max packet in the ring, if not - drop and return OK.
> > > Why bother checking beforehand though?
> > > If that's what we want to do, we can just call add_buf and see
> > > if it fails?
> >
> > In add_buf, there is an additional kick, see below. I added check
> > capacity to avoid this, thought it would be better performance. I will
> > retest it w/i add_buf to see the performance difference.
> >
> > if (vq->num_free < out + in) {
> > pr_debug("Can't add buf len %i - avail = %i\n",
> > out + in, vq->num_free);
> > /* FIXME: for historical reasons, we force a notify
> > here
> > if
> > * there are outgoing parts to the buffer. Presumably
> > the
> > * host should service the ring ASAP. */
> > if (out)
> > vq->notify(&vq->vq);
> > END_USE(vq);
> > return -ENOSPC;
> > }
> >
Rusty, could you pls clarify what are the historical reasons here?
Are they still valid?
If yes we could dedicate a feature flag to disabling this,
or guess that the host is new by looking at some
other feature flag.
> More test results:
>
> UDP_STREAM test results (% is guest vcpu, guest has 2 vpus):
>
> Send(netperf)
> ----
>
> size 2.6.38-rc8 2.6.38-rc8+ 2.6.38-rc8
> addbuf failure check capacity
> -----------------------------------------------------
> 1K 1541.0/50.14% 2169.1/50.03% 3018.9/50%
> 2K 1649.7/33.74% 3362.6/50.18% 4518.8/50.47%
> 4K 2957.8/44.83% 5965.9/50.03% 9592.5/50%
> 8K 3788/39.01% 9852.8/50.25% 15483.8/50%
> 16K 4736.1/34.13% 14946.5/50.01% 21645.0/50%
Is this the local or remote throughput?
With UDP_STREAM you are mostly interested in
remote throughput, local one can be pretty high
while most packets get dropped.
> Looks like the additional guest notify in add_buf doesn't cost that much
> than I thought to be.
>
> Thanks
> Shirley
^ permalink raw reply
* Re: LRO disable warnings on kernel 2.6.38
From: Eric Dumazet @ 2011-03-18 13:05 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, Neil Horman, Alexander Duyck
In-Reply-To: <1300446743.11985.317.camel@firesoul.comx.local>
Le vendredi 18 mars 2011 à 12:12 +0100, Jesper Dangaard Brouer a écrit :
> Hi
>
> I'm seeing the LRO disable warnings using kernel 2.6.38:
>
> [ 8.664759] NET: Registered protocol family 10
> [ 8.838148] ADDRCONF(NETDEV_UP): eth71: link is not ready
> [ 8.872639] ------------[ cut here ]------------
> [ 8.872645] WARNING: at net/core/dev.c:1363 dev_disable_lro+0x7b/0x80()
> [ 8.872647] Hardware name: ProLiant DL370 G6
> [ 8.872648] Modules linked in: ipv6 nf_conntrack ip_tables loop i7core_edac edac_core ipmi_si ipmi_msghandler joydev hpilo pcspkr sg hpsa igb ata_piix netxen_nic dca [last unloaded: scsi_wait_scan]
> [ 8.872660] Pid: 2221, comm: sysctl Not tainted 2.6.38-comx04 #2
> [ 8.872662] Call Trace:
> [ 8.872671] [<ffffffff81056e1f>] ? warn_slowpath_common+0x7f/0xc0
> [ 8.872675] [<ffffffff81056e7a>] ? warn_slowpath_null+0x1a/0x20
> [ 8.872680] [<ffffffff8140c0ab>] ? dev_disable_lro+0x7b/0x80
> [ 8.872686] [<ffffffff81474f27>] ? devinet_sysctl_forward+0x147/0x180
> [ 8.872691] [<ffffffff811872f7>] ? proc_sys_call_handler+0x97/0xd0
> [ 8.872700] [<ffffffff81187344>] ? proc_sys_write+0x14/0x20
> [ 8.872704] [<ffffffff81124148>] ? vfs_write+0xc8/0x180
> [ 8.872707] [<ffffffff81124301>] ? sys_write+0x51/0x90
> [ 8.872712] [<ffffffff8100b8c2>] ? system_call_fastpath+0x16/0x1b
> [ 8.872714] ---[ end trace 6245283cb8d484cc ]---
>
> The strange part is that I didn't see this warning on my testlab and
> pre-prod servers. The warning is from the first production server,
> which got kernel 2.6.38 deployed this morning.
>
> The NIC driver is igb.
>
> The only difference in hardware between the production and
> pre-production server (which didn't show the warning), is the
> prod-server have an extra dual-port original Intel NIC, dev-named
> "eth71". And its just after the init of eth71, the warning occurs.
>
> We usually use a 6 port NIC from Hotlava, which is based on the same
> chip 82576 and also uses the same igb driver.
>
> Intel orig NIC eth71
> albpd4:~# ethtool -i eth71
> driver: igb
> version: 2.1.0-k2
> firmware-version: 1.2-1
> bus-info: 0000:21:00.0
>
> Hotlava Intel chip based NIC eth51:
> albpd4:~# ethtool -i eth51
> driver: igb
> version: 2.1.0-k2
> firmware-version: 1.2-1
> bus-info: 0000:1d:00.1
>
> I don't understand why I don't see the warning on my pre-prod server,
> which only have the Hotlava NIC?!?
>
Hmm, WARN_ON() message is not very nice in this case I'm afraid, we dont
even know offender
diff --git a/net/core/dev.c b/net/core/dev.c
index 0b88eba..571ab70 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1361,7 +1361,8 @@ void dev_disable_lro(struct net_device *dev)
dev->ethtool_ops->set_flags(dev, flags);
}
}
- WARN_ON(dev->features & NETIF_F_LRO);
+ if (dev->features & NETIF_F_LRO)
+ netdev_err(dev, "Could not disable LRO\n");
}
EXPORT_SYMBOL(dev_disable_lro);
^ permalink raw reply related
* Re: dccp test-tree [RFC] [Patch 2/2] dccp: CCID2 check ack ratio when reducing cwnd
From: Gerrit Renker @ 2011-03-18 11:33 UTC (permalink / raw)
To: Samuel Jero; +Cc: dccp, netdev
In-Reply-To: <1300164797.20638.65.camel@jero-laptop>
| This patch causes CCID2 to check the ack ratio after reducing the
| congestion window.
Thanks a lot, it has been integrated with the other changes:
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=commitdiff;h=f7bcfc7ddf5c1f61c861c3d2b475df7874833ed3
^ permalink raw reply
* Re: dccp test-tree [RFC] [Patch 1/1] dccp: Only activate NN values after receiving the Confirm option
From: Gerrit Renker @ 2011-03-18 11:30 UTC (permalink / raw)
To: Samuel Jero; +Cc: dccp, netdev
In-Reply-To: <1300164791.20638.64.camel@jero-laptop>
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]
I have revised the patch set addressing the following comments of this thread:
1) Renamed function to dccp_feat_nn_get().
2) Added test to ensure that function is called for NN
features back in.
3) Replaced ccid2_ack_ratio_next() with calls to that
function (dccp_feat_nn_get(sk, DCCPF_ACK_RATIO)).
4) Replaced check for dccps_l_seq_win in ccid2_change_l_seq_window
with call to dccp_feat_nn_get(sk, DCCPF_SEQUENCE_WINDOW)
(for similar calls see separate, attached patch).
5) De-inlined ccid2_ack_ratio_next() wrapper as discussed.
6) Updated remaining patches with regard to 1-4.
In (4) I created a separate patch. You mentioned earlier replacing references to
local seq_window with a call to the accessor function, these were the remaining
references, I noticed no regression.
This is all in the test tree, just uploaded 2.6.38
git://eden-feed.erg.abdn.ac.uk/dccp_exp [subtree 'dccp']
| > I don't know if blocking the Ack Ratio code is the reason, but during the
| > initial slow-start there were ChangeL requests for Sequence Window on nearly
| > every packet, which seems too much.
|
| Right now, Change's are sent on every packet until the matching Confirm
| is received. That will be the cause of most of the Change's you are
| seeing.
|
| The other thing is that at the beginning of a connection the sequence
| window will be reduced and then increased. The initial window of 100
| packets is too wide for 5*cwnd at the start of the connection. So the
| window will be reduced as low as it will go at the very beginning of the
| connection. However, as slow start picks up, cwnd will increase and the
| sequence window will as well.
|
| I've seen the above behavior, but haven't thought of an effective
| solution (nor am I sure that we need a solution). Capping the minimum
| sequence window at the default (100 packets) would solve this, but that
| doesn't seem like a great solution.
|
| >
| > If low_threshold == high_threshold, it oscillates. I think you have already done
| > some work on this in the code using CCID2_WIN_CHANGE_FACTOR.
|
| I'm not entirely certain what low_threshold and high_threshold you are
| talking about. I have not seen sequence window oscillations other as the
| congestion window oscillates in congestion avoidance as is expected.
|
I meant a Schmitt Trigger like behaviour:
* low_threshold: to change from lower value to higher value
* hi_threshold: to revert from higher value back to lower value
In these electronic devices there is a gap between low and hi, to avoid fluctuations.
Also audio effect gates have a similar setting.
With regard to your comment about the 100 packets at the begin, I was wondering if
the connection could not grossly exaggerate, or maybe even use the 100 packets.
But all that is not a big deal, stuff for fine-tuning the now much better ccid2
engine.
Thank you for all your good work. The comments helped a great deal too.
[-- Attachment #2: remaining_l_seq_win_refs.diff --]
[-- Type: text/x-diff, Size: 1812 bytes --]
dccp ccid-2: replace remaining references to local Sequence Window value
This replaces the remaining references to dccps_l_seq_win with the corresponding
call to retrieve the current (STABLE if not in negotiation, CHANGING if being
negotiated) value of the feature-local sequence window.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccids/ccid2.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -441,10 +441,10 @@ static void ccid2_new_ack(struct sock *s
{
struct ccid2_hc_tx_sock *hc = ccid2_hc_tx_sk(sk);
struct dccp_sock *dp = dccp_sk(sk);
+ u64 l_seq_win = dccp_feat_nn_get(sk, DCCPF_SEQUENCE_WINDOW);
int r_seq_used = hc->tx_cwnd / dp->dccps_l_ack_ratio;
- if (hc->tx_cwnd < dp->dccps_l_seq_win &&
- r_seq_used < dp->dccps_r_seq_win) {
+ if (hc->tx_cwnd < l_seq_win && r_seq_used < dp->dccps_r_seq_win) {
if (hc->tx_cwnd < hc->tx_ssthresh) {
if (*maxincr > 0 && ++hc->tx_packets_acked >= 2) {
hc->tx_cwnd += 1;
@@ -466,10 +466,10 @@ static void ccid2_new_ack(struct sock *s
else if (r_seq_used * CCID2_WIN_CHANGE_FACTOR < dp->dccps_r_seq_win/2)
ccid2_change_l_ack_ratio(sk, dp->dccps_l_ack_ratio / 2 ? : 1U);
- if (hc->tx_cwnd * CCID2_WIN_CHANGE_FACTOR >= dp->dccps_l_seq_win)
- ccid2_change_l_seq_window(sk, dp->dccps_l_seq_win * 2);
- else if (hc->tx_cwnd * CCID2_WIN_CHANGE_FACTOR < dp->dccps_l_seq_win/2)
- ccid2_change_l_seq_window(sk, dp->dccps_l_seq_win / 2);
+ if (hc->tx_cwnd * CCID2_WIN_CHANGE_FACTOR >= l_seq_win)
+ ccid2_change_l_seq_window(sk, l_seq_win * 2);
+ else if (hc->tx_cwnd * CCID2_WIN_CHANGE_FACTOR < l_seq_win / 2)
+ ccid2_change_l_seq_window(sk, l_seq_win / 2);
/*
* FIXME: RTT is sampled several times per acknowledgment (for each
^ permalink raw reply
* LRO disable warnings on kernel 2.6.38
From: Jesper Dangaard Brouer @ 2011-03-18 11:12 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet, Neil Horman, Alexander Duyck
Hi
I'm seeing the LRO disable warnings using kernel 2.6.38:
[ 8.664759] NET: Registered protocol family 10
[ 8.838148] ADDRCONF(NETDEV_UP): eth71: link is not ready
[ 8.872639] ------------[ cut here ]------------
[ 8.872645] WARNING: at net/core/dev.c:1363 dev_disable_lro+0x7b/0x80()
[ 8.872647] Hardware name: ProLiant DL370 G6
[ 8.872648] Modules linked in: ipv6 nf_conntrack ip_tables loop i7core_edac edac_core ipmi_si ipmi_msghandler joydev hpilo pcspkr sg hpsa igb ata_piix netxen_nic dca [last unloaded: scsi_wait_scan]
[ 8.872660] Pid: 2221, comm: sysctl Not tainted 2.6.38-comx04 #2
[ 8.872662] Call Trace:
[ 8.872671] [<ffffffff81056e1f>] ? warn_slowpath_common+0x7f/0xc0
[ 8.872675] [<ffffffff81056e7a>] ? warn_slowpath_null+0x1a/0x20
[ 8.872680] [<ffffffff8140c0ab>] ? dev_disable_lro+0x7b/0x80
[ 8.872686] [<ffffffff81474f27>] ? devinet_sysctl_forward+0x147/0x180
[ 8.872691] [<ffffffff811872f7>] ? proc_sys_call_handler+0x97/0xd0
[ 8.872700] [<ffffffff81187344>] ? proc_sys_write+0x14/0x20
[ 8.872704] [<ffffffff81124148>] ? vfs_write+0xc8/0x180
[ 8.872707] [<ffffffff81124301>] ? sys_write+0x51/0x90
[ 8.872712] [<ffffffff8100b8c2>] ? system_call_fastpath+0x16/0x1b
[ 8.872714] ---[ end trace 6245283cb8d484cc ]---
The strange part is that I didn't see this warning on my testlab and
pre-prod servers. The warning is from the first production server,
which got kernel 2.6.38 deployed this morning.
The NIC driver is igb.
The only difference in hardware between the production and
pre-production server (which didn't show the warning), is the
prod-server have an extra dual-port original Intel NIC, dev-named
"eth71". And its just after the init of eth71, the warning occurs.
We usually use a 6 port NIC from Hotlava, which is based on the same
chip 82576 and also uses the same igb driver.
Intel orig NIC eth71
albpd4:~# ethtool -i eth71
driver: igb
version: 2.1.0-k2
firmware-version: 1.2-1
bus-info: 0000:21:00.0
Hotlava Intel chip based NIC eth51:
albpd4:~# ethtool -i eth51
driver: igb
version: 2.1.0-k2
firmware-version: 1.2-1
bus-info: 0000:1d:00.1
I don't understand why I don't see the warning on my pre-prod server,
which only have the Hotlava NIC?!?
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 05/36] block,rcu: convert call_rcu(disk_free_ptbl_rcu_cb) to kfree_rcu()
From: Matthew Wilcox @ 2011-03-18 11:20 UTC (permalink / raw)
To: Jens Axboe
Cc: Lai Jiangshan, Paul E. McKenney, Ingo Molnar, Robert Love,
James E.J. Bottomley, Neil Horman, David S. Miller,
Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet,
Stephen Hemminger, Tejun Heo, Jarek Poplawski, linux-kernel,
devel, linux-scsi, netdev
In-Reply-To: <4D8302E9.30303@kernel.dk>
On Fri, Mar 18, 2011 at 07:59:53AM +0100, Jens Axboe wrote:
> On 2011-03-18 04:42, Lai Jiangshan wrote:
> >
> >
> > The rcu callback disk_free_ptbl_rcu_cb() just calls a kfree(),
> > so we use kfree_rcu() instead of the call_rcu(disk_free_ptbl_rcu_cb).
>
> Thanks, I'll add this.
Don't be in too much of a hurry ... kfree_rcu() doesn't appear to have
hit Linus' tree yet.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* [PATCH RFC] net: unify features for drivers which use skb_copy_and_csum_dev
From: Cesar Eduardo Barros @ 2011-03-18 10:57 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Jeff Garzik, Lennert Buytenhek, Tristram Ha,
Roger Luethi, Michał Mirosław, Cesar Eduardo Barros
A few network drivers use skb_copy_and_csum_dev as the core of their
.ndo_start_xmit function. Which NETIF_F_* features these drivers can use
should depend only on the implementation of skb_copy_and_csum_dev, and
so should be the same for all of them. However, I could find three
different sets of feature flags on these drivers.
To prevent these drivers from getting out of sync again, move this set
of feature flags to a central location. With the advantage that if the
set of flags is later found to be wrong or skb_copy_and_csum_dev is
modified, it can be changed in a single place.
This also enables NETIF_F_FRAGLIST for these drivers. Unless I misread
the code behind skb_copy_and_csum_dev, it can also deal with frag lists.
There were other drivers using skb_copy_and_csum_dev (ksz884x and
via-rhine), but I did not touch them, since they are doing things on
their .ndo_start_xmit which are more complex than a simple call of
skb_copy_and_csum_dev.
Cc: Jeff Garzik <jgarzik@pobox.com> (8139too)
Cc: Lennert Buytenhek <kernel@wantstofly.org> (ep93xx_eth, ixp2000)
Cc: Tristram Ha <Tristram.Ha@micrel.com> (ksz884x)
Cc: Roger Luethi <rl@hellgate.ch> (via-rhine)
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
drivers/net/8139too.c | 2 +-
drivers/net/arm/ep93xx_eth.c | 2 +-
drivers/net/ixp2000/ixpdev.c | 2 +-
drivers/net/sc92031.c | 3 +--
include/linux/netdevice.h | 4 ++++
5 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 98517a3..0fc2127 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -991,7 +991,7 @@ static int __devinit rtl8139_init_one (struct pci_dev *pdev,
* through the use of skb_copy_and_csum_dev we enable these
* features
*/
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA;
+ dev->features |= NETIF_F_XMIT_COPY_AND_CSUM;
dev->irq = pdev->irq;
diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 5a77001..50ebd33 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -769,7 +769,7 @@ static struct net_device *ep93xx_dev_alloc(struct ep93xx_eth_data *data)
dev->ethtool_ops = &ep93xx_ethtool_ops;
dev->netdev_ops = &ep93xx_netdev_ops;
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM;
+ dev->features |= NETIF_F_XMIT_COPY_AND_CSUM;
return dev;
}
diff --git a/drivers/net/ixp2000/ixpdev.c b/drivers/net/ixp2000/ixpdev.c
index 78ddd8b..0df0734 100644
--- a/drivers/net/ixp2000/ixpdev.c
+++ b/drivers/net/ixp2000/ixpdev.c
@@ -303,7 +303,7 @@ struct net_device *ixpdev_alloc(int channel, int sizeof_priv)
dev->netdev_ops = &ixpdev_netdev_ops;
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM;
+ dev->features |= NETIF_F_XMIT_COPY_AND_CSUM;
ip = netdev_priv(dev);
ip->dev = dev;
diff --git a/drivers/net/sc92031.c b/drivers/net/sc92031.c
index 76290a8..63db429 100644
--- a/drivers/net/sc92031.c
+++ b/drivers/net/sc92031.c
@@ -1449,8 +1449,7 @@ static int __devinit sc92031_probe(struct pci_dev *pdev,
dev->irq = pdev->irq;
/* faked with skb_copy_and_csum_dev */
- dev->features = NETIF_F_SG | NETIF_F_HIGHDMA |
- NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
+ dev->features = NETIF_F_XMIT_COPY_AND_CSUM;
dev->netdev_ops = &sc92031_netdev_ops;
dev->watchdog_timeo = TX_TIMEOUT;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 5eeb2cd..680ed33 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1110,6 +1110,10 @@ struct net_device {
/* changeable features with no special hardware requirements */
#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO)
+ /* skb_copy_and_csum_dev is able to fake a few features */
+#define NETIF_F_XMIT_COPY_AND_CSUM (NETIF_F_SG | NETIF_F_HW_CSUM | \
+ NETIF_F_HIGHDMA | NETIF_F_FRAGLIST)
+
/* Interface index. Unique device identifier */
int ifindex;
int iflink;
--
1.7.4
^ 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