* Re: [BUG net-next-2.6] vlan, bonding, bnx2 problems
From: Jay Vosburgh @ 2010-07-19 20:19 UTC (permalink / raw)
To: Michael Chan
Cc: Eric Dumazet, David Miller, pedro.netdev@dondevamos.com,
netdev@vger.kernel.org, kaber@trash.net,
bhutchings@solarflare.com
In-Reply-To: <1279563291.20559.10.camel@HP1>
Michael Chan <mchan@broadcom.com> wrote:
>Adding Jay to CC.
>
>On Mon, 2010-07-19 at 06:24 -0700, Eric Dumazet wrote:
>> [ 32.046479] BUG: scheduling while atomic: ifenslave/4586/0x00000100
>> [ 32.046540] Modules linked in: ipmi_si ipmi_msghandler hpilo
>> bonding ipv6
>> [ 32.046784] Pid: 4586, comm: ifenslave Tainted: G W
>> 2.6.35-rc1-01453-g3e12451-dirty #836
>> [ 32.046860] Call Trace:
>> [ 32.046910] [<c13421c4>] ? printk+0x18/0x1c
>> [ 32.046965] [<c10315c9>] __schedule_bug+0x59/0x60
>> [ 32.047019] [<c1342a2c>] schedule+0x57c/0x850
>> [ 32.047074] [<c104a106>] ? lock_timer_base+0x26/0x50
>> [ 32.047128] [<c1342f78>] schedule_timeout+0x118/0x250
>> [ 32.047183] [<c104a2c0>] ? process_timeout+0x0/0x10
>> [ 32.047238] [<c13430c5>] schedule_timeout_uninterruptible
>> +0x15/0x20
>> [ 32.047295] [<c104a345>] msleep+0x15/0x20
>> [ 32.047350] [<c1227082>] bnx2_napi_disable+0x52/0x80
>> [ 32.047405] [<c122b56f>] bnx2_netif_stop+0x3f/0xa0
>> [ 32.047460] [<c122b62a>] bnx2_vlan_rx_register+0x5a/0x80
>> [ 32.047516] [<f8ced776>] bond_enslave+0x526/0xa90 [bonding]
>> [ 32.047576] [<f8b8f0d0>] ? fib6_clean_node+0x0/0xb0 [ipv6]
>> [ 32.047634] [<f8b8dda0>] ? fib6_age+0x0/0x90 [ipv6]
>> [ 32.047689] [<c129d2d3>] ? netdev_set_master+0x3/0xc0
>> [ 32.047746] [<f8cee4cb>] bond_do_ioctl+0x31b/0x430 [bonding]
>> [ 32.047804] [<c105b19a>] ? raw_notifier_call_chain+0x1a/0x20
>> [ 32.047861] [<c12abd5d>] ? __rtnl_unlock+0xd/0x10
>> [ 32.047915] [<c129f8cd>] ? __dev_get_by_name+0x7d/0xa0
>> [ 32.047970] [<c12a19b0>] dev_ifsioc+0xf0/0x290
>> [ 32.048025] [<f8cee1b0>] ? bond_do_ioctl+0x0/0x430 [bonding]
>> [ 32.048081] [<c12a1ce1>] dev_ioctl+0x191/0x610
>> [ 32.048136] [<c12eeb20>] ? udp_ioctl+0x0/0x70
>> [ 32.048189] [<c128f67c>] sock_ioctl+0x6c/0x240
>> [ 32.048243] [<c10d3a44>] vfs_ioctl+0x34/0xa0
>> [ 32.048297] [<c10c7cab>] ? alloc_file+0x1b/0xa0
>> [ 32.048351] [<c128f610>] ? sock_ioctl+0x0/0x240
>> [ 32.048404] [<c10d4186>] do_vfs_ioctl+0x66/0x550
>> [ 32.048459] [<c1022ca0>] ? do_page_fault+0x0/0x350
>> [ 32.048513] [<c1022e41>] ? do_page_fault+0x1a1/0x350
>> [ 32.048568] [<c129098c>] ? sys_socket+0x5c/0x70
>> [ 32.048622] [<c1291860>] ? sys_socketcall+0x60/0x270
>> [ 32.048677] [<c10d46a9>] sys_ioctl+0x39/0x60
>> [ 32.048730] [<c1002bd0>] sysenter_do_call+0x12/0x26
>> [ 32.052025] bonding: bond0: enslaving eth1 as a backup interface
>> with a down link.
>> [ 32.100207] tg3 0000:14:04.0: PME# enabled
>> [ 32.100222] pci0000:00: wake-up capability enabled by ACPI
>> [ 32.224488] pci0000:00: wake-up capability disabled by ACPI
>> [ 32.224492] tg3 0000:14:04.0: PME# disabled
>> [ 32.348516] tg3 0000:14:04.0: BAR 0: set to [mem
>> 0xfdff0000-0xfdffffff 64bit] (PCI address [0xfdff0000-0xfdffffff]
>> [ 32.348524] tg3 0000:14:04.0: BAR 2: set to [mem
>> 0xfdfe0000-0xfdfeffff 64bit] (PCI address [0xfdfe0000-0xfdfeffff]
>> [ 32.363711] bonding: bond0: enslaving eth2 as a backup interface
>> with a down link.
>>
>>
>>
>> For bnx2, it seems commit 212f9934afccf9c9739921
>> was not sufficient to correct the "scheduling while atomic" bug...
>> enslaving a bnx2 on a bond device with one vlan already set :
>> bond_enslave -> bnx2_vlan_rx_register -> bnx2_netif_stop ->
>> bnx2_napi_disable -> msleep()
>>
>
>There are a number of drivers that call napi_disable() during
>->ndo_vlan_rx_regsiter(). bnx2 is lockless in the rx path and so we
>need to disable NAPI rx processing and wait for it to be done before
>modifying the vlgrp.
>
>Jay, is there an alternative to holding the bond->lock when calling the
>slave's ->ndo_vlan_rx_register()?
I believe so. The lock is held here nominally to mutex
bonding's vlan_list. The bond_add_vlans_on_slave function actually does
the lock and call to ndo_vlan_rx_register (plus one add_vid call per
configured VLAN); I think the call frame in the above stack has been
optimized out.
For the specific cases of bond_add_vlans_on_slave and
bond_del_vlans_from_slave, we should be able to get away without holding
the bond->lock because we also hold RTNL, and it looks like all changes
to the vlan_list are implicitly mutexed by RTNL because all VLAN add /
remove for device or vid end up being done under RTNL.
The cases within bonding that change the vlan_list will still
have to hold bond->lock, because other call sites within bonding check
the vlan_list without RTNL (and it would be impractical to have them do
so).
The patch is as follows; I'm compiling this now to test. If it
pans out, I'll post a formal submission in a bit.
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 8228088..decddf5 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -565,10 +565,8 @@ static void bond_add_vlans_on_slave(struct bonding *bond, struct net_device *sla
struct vlan_entry *vlan;
const struct net_device_ops *slave_ops = slave_dev->netdev_ops;
- write_lock_bh(&bond->lock);
-
if (list_empty(&bond->vlan_list))
- goto out;
+ return;
if ((slave_dev->features & NETIF_F_HW_VLAN_RX) &&
slave_ops->ndo_vlan_rx_register)
@@ -576,13 +574,10 @@ static void bond_add_vlans_on_slave(struct bonding *bond, struct net_device *sla
if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) ||
!(slave_ops->ndo_vlan_rx_add_vid))
- goto out;
+ return;
list_for_each_entry(vlan, &bond->vlan_list, vlan_list)
slave_ops->ndo_vlan_rx_add_vid(slave_dev, vlan->vlan_id);
-
-out:
- write_unlock_bh(&bond->lock);
}
static void bond_del_vlans_from_slave(struct bonding *bond,
@@ -592,10 +587,8 @@ static void bond_del_vlans_from_slave(struct bonding *bond,
struct vlan_entry *vlan;
struct net_device *vlan_dev;
- write_lock_bh(&bond->lock);
-
if (list_empty(&bond->vlan_list))
- goto out;
+ return;
if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) ||
!(slave_ops->ndo_vlan_rx_kill_vid))
@@ -614,9 +607,6 @@ unreg:
if ((slave_dev->features & NETIF_F_HW_VLAN_RX) &&
slave_ops->ndo_vlan_rx_register)
slave_ops->ndo_vlan_rx_register(slave_dev, NULL);
-
-out:
- write_unlock_bh(&bond->lock);
}
/*------------------------------- Link status -------------------------------*/
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply related
* Re: [PATCH 2.6.35-rc1] net-next: vmxnet3 fixes [5/5] Respect the interrupt type in VM configuration
From: David Miller @ 2010-07-19 20:16 UTC (permalink / raw)
To: sbhatewara; +Cc: netdev, linux-kernel, pv-drivers
In-Reply-To: <alpine.LRH.2.00.1007151458580.10176@localhost.localdomain>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Thu, 15 Jul 2010 18:21:27 -0700 (PDT)
> Respect the interrupt type set in VM configuration.
>
> When interrupt type is not auto, do not ignore the interrupt type set from
> VM configuration.
>
> Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2.6.35-rc1] net-next: vmxnet3 fixes [4/5] Do not reset when the device is not opened
From: David Miller @ 2010-07-19 20:16 UTC (permalink / raw)
To: sbhatewara; +Cc: netdev, linux-kernel, pv-drivers, ronghua, matthieu
In-Reply-To: <alpine.LRH.2.00.1007190958480.9943@localhost.localdomain>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Mon, 19 Jul 2010 10:02:13 -0700 (PDT)
> Hold rtnl_lock to get the right link state.
>
> While asynchronously resetting the device, hold rtnl_lock to get the
> right value from netif_running. If a reset is scheduled, and the device
> goes thru close and open, it may happen that reset and open may run in
> parallel. Holding rtnl_lock will avoid this.
>
> Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
Applied.
^ permalink raw reply
* Re: [PATCHv2] tcp: fix crash in tcp_xmit_retransmit_queue
From: David Miller @ 2010-07-19 19:55 UTC (permalink / raw)
To: eric.dumazet
Cc: ilpo.jarvinen, lennart.schulte, tj, linux-kernel, netdev,
henning.fehrmann, carsten.aulbert
In-Reply-To: <1279561148.2553.150.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 19 Jul 2010 19:39:08 +0200
> Do you know in what exact circumstance the bug triggers ?
>
> It's hard to believe thousand of machines on the Internet never hit
> it :(
>
> Maybe another problem in congestion control ?
This is something to investigate, but the conditions under which
tcp_fastretrans_alert() (the main invoker of tcp_xmit_retransmit_queue())
does it's thing are complicated enough that I'm going to add this fix
for the time being and push it out to stable too.
Thanks everyone.
^ permalink raw reply
* Re: bnx2/5709: Strange interrupts spread
From: Eric Dumazet @ 2010-07-19 19:47 UTC (permalink / raw)
To: Michael Chan; +Cc: Christophe Ngo Van Duc, netdev@vger.kernel.org
In-Reply-To: <1279565231.20559.14.camel@HP1>
Le lundi 19 juillet 2010 à 11:47 -0700, Michael Chan a écrit :
> On Mon, 2010-07-19 at 08:55 -0700, Christophe Ngo Van Duc wrote:
> > So i've been able to do some test today:
> > If I put the 2 interface in a bridge with no IP adress, the interrupts
> > are on 1 CPU
> > If I put the 2 interface in a bridge with IP adress, the interrupts
> > are still on 1 CPU
> > If I put the 2 interface outside the bridge with IP address,
> > everything works fine the interrupts get spread on the CPU
> >
> > So the conclusion seems to be that when the bnx2 is put into
> > promiscuous mode by the bridge, the RSS hash stop to work even if
> > traffic is IP in nature.
>
> I did a quick test with bridging and saw no problem with RSS. I did see
> this though:
>
> br0 received packet on queue 4, but number of RX queues is 1
>
> Looks like it is a warning message from RPS.
>
Christophe uses an old kernel, not RPS enabled ;)
^ permalink raw reply
* Re: Very low latency TCP for clusters
From: Mitchell Erblich @ 2010-07-19 19:46 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev
In-Reply-To: <AANLkTilNmNZbFWS8LF-UHU65QYIC32HZlgVZ7lXJHxPh@mail.gmail.com>
Tom, et al,
To possibly remove 3-way handshake costs for
small data transfers a number of years ago, their
was an experimental RFC that was a Transactional
TCP, where the SYN, data, and FIN were sent as
a tuple in the first segmernt.
If a company has control of the two end systems
and the intermediate systems, then it should be
possible for an app to declare in a setsockopt call
this experimental flow.
Mitchell Erblich
============
On Jul 19, 2010, at 10:05 AM, Tom Herbert wrote:
> We have been looking at best case TCP latencies that might be achieved
> within a cluster (low loss fabric). The goal is to have latency
> numbers roughly comparable to that which can be produced using RDMA/IB
> in a low latency configuration (<5 usecs round trip on netperf TCP_RR
> test with one byte data for directly connected hosts as a starting
> point). This would be without changing sockets API, fabric, and
> preferably not using TCP offload or a user space stack.
>
> I think there are at least two techniques that will drive down TCP
> latency: per connection queues and polling queues. Per connection
> queues (supported by device) should eliminate costs of connection
> look-up, hopefully some locking. Polling becomes viable as core
> counts on systems increase, and burning a few CPUs for networking
> polling on behalf of very low-latency threads would be reasonable.
>
> Are there any efforts in progress to integrate per connection queues
> in the stack or integrate polling of queues?
>
> Thanks,
> Tom
> --
> 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
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-07-19
From: David Miller @ 2010-07-19 19:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100719191709.GA6115@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 19 Jul 2010 15:17:09 -0400
> In this round we have two more-or-less-one-liners intended for 2.6.25.
>
> The hostap fix is the third (and hopefully final) bite at the apple
> for correcting an initialization failure. The first two attempts
> created and then reinstated a regression caused by a discrepency
> between the PCI and PCMCIA support within hostap. The regression
> was caused by checking the value of dev->base_addr, which the PCI
> code was not setting. Testing by the regression reporter indicates
> that his device is finally working again with this fix.
>
> The rt2x00 fix merely reorders some initialization so that unwinding
> that init in an error path works as expected.
Pulled, thanks John.
^ permalink raw reply
* Re: [RFC 1/2] netfilter: xt_condition: export list management code
From: Luciano Coelho @ 2010-07-19 19:31 UTC (permalink / raw)
To: ext Jan Engelhardt
Cc: Netfilter Developer Mailing List, netdev@vger.kernel.org,
Patrick McHardy, sameo@linux.intel.com
In-Reply-To: <1279566876.11662.102.camel@powerslave>
On Mon, 2010-07-19 at 21:14 +0200, Coelho Luciano (Nokia-MS/Helsinki)
wrote:
> On Mon, 2010-07-19 at 18:13 +0200, ext Jan Engelhardt wrote:
> > On Monday 2010-07-19 16:15, Luciano Coelho wrote:
> > >@@ -3,12 +3,27 @@
> > >
> > > #include <linux/types.h>
> > >
> > >+#define XT_CONDITION_MAX_NAME_SIZE 30
> > >+
> > > struct xt_condition_mtinfo {
> > >- char name[31];
> > >+ char name[XT_CONDITION_MAX_NAME_SIZE + 1];
> > > __u8 invert;
> >
> > Oh noes. Please please avoid any math operations inside []. It has
> > already driven XT_FUNCTION_MAXNAMELEN into nuts ("was it now +1 or -1,
> > or even -2 that we needed to pass for various functions?"). Just let MAX
> > be 31 and have name[MAX].
>
> Yeah, I had already done as you suggested in my previous module
> (IDLETIMER), I don't know what I had in my head today when I did it
> differently. Even the name of the macro is totally wrong (_SIZE), it
> would make a tiny little bit more sense if it was _LEN. I'll change it.
I was not very clear here, I meant I'll change to what you proposed, ie.
keep it _SIZE and use 31, of course.
--
Cheers,
Luca.
^ permalink raw reply
* Re: Very low latency TCP for clusters
From: David Miller @ 2010-07-19 19:27 UTC (permalink / raw)
To: therbert; +Cc: eric.dumazet, netdev
In-Reply-To: <AANLkTiniRmnwG4vT-MrQQHQjrdQ4sfOn6Uxi42Dsr8nu@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 19 Jul 2010 11:44:05 -0700
> I am thinking of a device that supports multi-queue where individual
> queues can be programming to accept an exact 4-tuple,
NIU can already do this by programming the TCAM and segregating the
queues the TCAM entries map to.
There has also been talk of just having "a lot" of queues. Maybe, on
the order of thousands.
^ permalink raw reply
* pull request: wireless-2.6 2010-07-19
From: John W. Linville @ 2010-07-19 19:17 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
In this round we have two more-or-less-one-liners intended for 2.6.25.
The hostap fix is the third (and hopefully final) bite at the apple
for correcting an initialization failure. The first two attempts
created and then reinstated a regression caused by a discrepency
between the PCI and PCMCIA support within hostap. The regression
was caused by checking the value of dev->base_addr, which the PCI
code was not setting. Testing by the regression reporter indicates
that his device is finally working again with this fix.
The rt2x00 fix merely reorders some initialization so that unwinding
that init in an error path works as expected.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 91a72a70594e5212c97705ca6a694bd307f7a26b:
net/core: neighbour update Oops (2010-07-14 18:02:16 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
John W. Linville (1):
hostap_pci: set dev->base_addr during probe
Stephen Boyd (1):
rt2x00: Fix lockdep warning in rt2x00lib_probe_dev()
drivers/net/wireless/hostap/hostap_pci.c | 1 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 10 +++++-----
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_pci.c b/drivers/net/wireless/hostap/hostap_pci.c
index d24dc7d..972a9c3 100644
--- a/drivers/net/wireless/hostap/hostap_pci.c
+++ b/drivers/net/wireless/hostap/hostap_pci.c
@@ -330,6 +330,7 @@ static int prism2_pci_probe(struct pci_dev *pdev,
dev->irq = pdev->irq;
hw_priv->mem_start = mem;
+ dev->base_addr = (unsigned long) mem;
prism2_pci_cor_sreset(local);
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 3ae468c..f20d3ee 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -854,6 +854,11 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
BIT(NL80211_IFTYPE_WDS);
/*
+ * Initialize configuration work.
+ */
+ INIT_WORK(&rt2x00dev->intf_work, rt2x00lib_intf_scheduled);
+
+ /*
* Let the driver probe the device to detect the capabilities.
*/
retval = rt2x00dev->ops->lib->probe_hw(rt2x00dev);
@@ -863,11 +868,6 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
}
/*
- * Initialize configuration work.
- */
- INIT_WORK(&rt2x00dev->intf_work, rt2x00lib_intf_scheduled);
-
- /*
* Allocate queue array.
*/
retval = rt2x00queue_allocate(rt2x00dev);
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [RFC 1/2] netfilter: xt_condition: export list management code
From: Luciano Coelho @ 2010-07-19 19:14 UTC (permalink / raw)
To: ext Jan Engelhardt
Cc: Netfilter Developer Mailing List, netdev@vger.kernel.org,
Patrick McHardy, sameo@linux.intel.com
In-Reply-To: <alpine.LSU.2.01.1007191807020.19191@obet.zrqbmnf.qr>
On Mon, 2010-07-19 at 18:13 +0200, ext Jan Engelhardt wrote:
> On Monday 2010-07-19 16:15, Luciano Coelho wrote:
>
> >From: Luciano Coelho <coelho@testbed>
> >
> >This patch isolates and exports the condition list management code, in
> >preparation for the CONDITION target to use it. No functional change,
> >just reorganization of the code.
>
> Well, I guess it would make more sense if the two extensions be in a
> single file. That would alleviate the need for export reorganizations,
> and also works because the module metadata overhead is large already.
Right. I'll change the code so that the two extensions are in the same
file/module. You're the second person to mention this already. ;)
> >@@ -3,12 +3,27 @@
> >
> > #include <linux/types.h>
> >
> >+#define XT_CONDITION_MAX_NAME_SIZE 30
> >+
> > struct xt_condition_mtinfo {
> >- char name[31];
> >+ char name[XT_CONDITION_MAX_NAME_SIZE + 1];
> > __u8 invert;
>
> Oh noes. Please please avoid any math operations inside []. It has
> already driven XT_FUNCTION_MAXNAMELEN into nuts ("was it now +1 or -1,
> or even -2 that we needed to pass for various functions?"). Just let MAX
> be 31 and have name[MAX].
Yeah, I had already done as you suggested in my previous module
(IDLETIMER), I don't know what I had in my head today when I did it
differently. Even the name of the macro is totally wrong (_SIZE), it
would make a tiny little bit more sense if it was _LEN. I'll change it.
> > MODULE_ALIAS("ip6t_condition");
> >
> >-struct condition_variable {
> >- struct list_head list;
> >- struct proc_dir_entry *status_proc;
> >- unsigned int refcount;
> >- bool enabled;
> >-};
>
> Given your excellent usage example of a CONDITION target, I think it
> even makes sense to enlarge the "enabled" variable to a full-fledged
> 32-bit value that can be &, | and ^'d, similar to nfmark.
Ok, that's a good idea, I'll do that.
Thanks for your comments!
--
Cheers,
Luca.
^ permalink raw reply
* Re: bnx2/5709: Strange interrupts spread
From: Michael Chan @ 2010-07-19 18:47 UTC (permalink / raw)
To: Christophe Ngo Van Duc; +Cc: netdev@vger.kernel.org
In-Reply-To: <AANLkTikfEED5Hvt80G6EnMwPBByMuw4r1Xg2ITjuZ0eV@mail.gmail.com>
On Mon, 2010-07-19 at 08:55 -0700, Christophe Ngo Van Duc wrote:
> So i've been able to do some test today:
> If I put the 2 interface in a bridge with no IP adress, the interrupts
> are on 1 CPU
> If I put the 2 interface in a bridge with IP adress, the interrupts
> are still on 1 CPU
> If I put the 2 interface outside the bridge with IP address,
> everything works fine the interrupts get spread on the CPU
>
> So the conclusion seems to be that when the bnx2 is put into
> promiscuous mode by the bridge, the RSS hash stop to work even if
> traffic is IP in nature.
I did a quick test with bridging and saw no problem with RSS. I did see
this though:
br0 received packet on queue 4, but number of RX queues is 1
Looks like it is a warning message from RPS.
^ permalink raw reply
* Re: Very low latency TCP for clusters
From: Tom Herbert @ 2010-07-19 18:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1279561319.2553.153.camel@edumazet-laptop>
On Mon, Jul 19, 2010 at 10:41 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 19 juillet 2010 à 10:05 -0700, Tom Herbert a écrit :
>> We have been looking at best case TCP latencies that might be achieved
>> within a cluster (low loss fabric). The goal is to have latency
>> numbers roughly comparable to that which can be produced using RDMA/IB
>> in a low latency configuration (<5 usecs round trip on netperf TCP_RR
>> test with one byte data for directly connected hosts as a starting
>> point). This would be without changing sockets API, fabric, and
>> preferably not using TCP offload or a user space stack.
>>
>> I think there are at least two techniques that will drive down TCP
>> latency: per connection queues and polling queues. Per connection
>> queues (supported by device) should eliminate costs of connection
>> look-up, hopefully some locking. Polling becomes viable as core
>> counts on systems increase, and burning a few CPUs for networking
>> polling on behalf of very low-latency threads would be reasonable.
>>
>> Are there any efforts in progress to integrate per connection queues
>> in the stack or integrate polling of queues?
>
> aka "net channel" ;)
>
I don't think this is the same. I am thinking of a device that
supports multi-queue where individual queues can be programming to
accept an exact 4-tuple, from the device's point of view I don't think
there's much beyond that and it is otherwise treated as just another
packet queue. However, kernel may be able to use it to shortcut some
processing. I believe such functionality is already supported in
Intel's flow director and possibly by some other vendors.
> What a nightmare...
>
I prefer to think of it as challenge, needing to resort to stateful
offload to get low latency would be the nightmare ;-)
> Anyway, 5 us roundtrip TCP_RR (including user thread work), seems a bit
> utopic right now.
>
> Even on loopback
>
I see about 7 usecs as best number on loopback, so I believe this is
in the ballpark. As I mentioned above, this about "best case" latency
of a single thread, so we assume any amount of pinning or other
customized configuration to that purpose.
>
>
>
^ permalink raw reply
* Re: Very low latency TCP for clusters
From: Nivedita Singhvi @ 2010-07-19 18:28 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev
In-Reply-To: <AANLkTilNmNZbFWS8LF-UHU65QYIC32HZlgVZ7lXJHxPh@mail.gmail.com>
Tom Herbert wrote:
> We have been looking at best case TCP latencies that might be achieved
> within a cluster (low loss fabric). The goal is to have latency
> numbers roughly comparable to that which can be produced using RDMA/IB
> in a low latency configuration (<5 usecs round trip on netperf TCP_RR
> test with one byte data for directly connected hosts as a starting
> point). This would be without changing sockets API, fabric, and
> preferably not using TCP offload or a user space stack.
Over what media are you doing this? 10gbe? gbe? Whatever numbers
I've seen for latency have been superior on IB, and I'd be very
interested in any effort to get lower latencies over other transport.
> I think there are at least two techniques that will drive down TCP
> latency: per connection queues and polling queues. Per connection
> queues (supported by device) should eliminate costs of connection
> look-up, hopefully some locking. Polling becomes viable as core
> counts on systems increase, and burning a few CPUs for networking
> polling on behalf of very low-latency threads would be reasonable.
Have you got any profiling data that captures where your
particular latencies are? Also, have you tried a real-time
kernel?
thanks,
Nivedita
^ permalink raw reply
* Re: [BUG net-next-2.6] vlan, bonding, bnx2 problems
From: Michael Chan @ 2010-07-19 18:14 UTC (permalink / raw)
To: Eric Dumazet, fubar
Cc: David Miller, pedro.netdev@dondevamos.com, netdev@vger.kernel.org,
kaber@trash.net, bhutchings@solarflare.com
In-Reply-To: <1279545854.2553.37.camel@edumazet-laptop>
Adding Jay to CC.
On Mon, 2010-07-19 at 06:24 -0700, Eric Dumazet wrote:
> [ 32.046479] BUG: scheduling while atomic: ifenslave/4586/0x00000100
> [ 32.046540] Modules linked in: ipmi_si ipmi_msghandler hpilo
> bonding ipv6
> [ 32.046784] Pid: 4586, comm: ifenslave Tainted: G W
> 2.6.35-rc1-01453-g3e12451-dirty #836
> [ 32.046860] Call Trace:
> [ 32.046910] [<c13421c4>] ? printk+0x18/0x1c
> [ 32.046965] [<c10315c9>] __schedule_bug+0x59/0x60
> [ 32.047019] [<c1342a2c>] schedule+0x57c/0x850
> [ 32.047074] [<c104a106>] ? lock_timer_base+0x26/0x50
> [ 32.047128] [<c1342f78>] schedule_timeout+0x118/0x250
> [ 32.047183] [<c104a2c0>] ? process_timeout+0x0/0x10
> [ 32.047238] [<c13430c5>] schedule_timeout_uninterruptible
> +0x15/0x20
> [ 32.047295] [<c104a345>] msleep+0x15/0x20
> [ 32.047350] [<c1227082>] bnx2_napi_disable+0x52/0x80
> [ 32.047405] [<c122b56f>] bnx2_netif_stop+0x3f/0xa0
> [ 32.047460] [<c122b62a>] bnx2_vlan_rx_register+0x5a/0x80
> [ 32.047516] [<f8ced776>] bond_enslave+0x526/0xa90 [bonding]
> [ 32.047576] [<f8b8f0d0>] ? fib6_clean_node+0x0/0xb0 [ipv6]
> [ 32.047634] [<f8b8dda0>] ? fib6_age+0x0/0x90 [ipv6]
> [ 32.047689] [<c129d2d3>] ? netdev_set_master+0x3/0xc0
> [ 32.047746] [<f8cee4cb>] bond_do_ioctl+0x31b/0x430 [bonding]
> [ 32.047804] [<c105b19a>] ? raw_notifier_call_chain+0x1a/0x20
> [ 32.047861] [<c12abd5d>] ? __rtnl_unlock+0xd/0x10
> [ 32.047915] [<c129f8cd>] ? __dev_get_by_name+0x7d/0xa0
> [ 32.047970] [<c12a19b0>] dev_ifsioc+0xf0/0x290
> [ 32.048025] [<f8cee1b0>] ? bond_do_ioctl+0x0/0x430 [bonding]
> [ 32.048081] [<c12a1ce1>] dev_ioctl+0x191/0x610
> [ 32.048136] [<c12eeb20>] ? udp_ioctl+0x0/0x70
> [ 32.048189] [<c128f67c>] sock_ioctl+0x6c/0x240
> [ 32.048243] [<c10d3a44>] vfs_ioctl+0x34/0xa0
> [ 32.048297] [<c10c7cab>] ? alloc_file+0x1b/0xa0
> [ 32.048351] [<c128f610>] ? sock_ioctl+0x0/0x240
> [ 32.048404] [<c10d4186>] do_vfs_ioctl+0x66/0x550
> [ 32.048459] [<c1022ca0>] ? do_page_fault+0x0/0x350
> [ 32.048513] [<c1022e41>] ? do_page_fault+0x1a1/0x350
> [ 32.048568] [<c129098c>] ? sys_socket+0x5c/0x70
> [ 32.048622] [<c1291860>] ? sys_socketcall+0x60/0x270
> [ 32.048677] [<c10d46a9>] sys_ioctl+0x39/0x60
> [ 32.048730] [<c1002bd0>] sysenter_do_call+0x12/0x26
> [ 32.052025] bonding: bond0: enslaving eth1 as a backup interface
> with a down link.
> [ 32.100207] tg3 0000:14:04.0: PME# enabled
> [ 32.100222] pci0000:00: wake-up capability enabled by ACPI
> [ 32.224488] pci0000:00: wake-up capability disabled by ACPI
> [ 32.224492] tg3 0000:14:04.0: PME# disabled
> [ 32.348516] tg3 0000:14:04.0: BAR 0: set to [mem
> 0xfdff0000-0xfdffffff 64bit] (PCI address [0xfdff0000-0xfdffffff]
> [ 32.348524] tg3 0000:14:04.0: BAR 2: set to [mem
> 0xfdfe0000-0xfdfeffff 64bit] (PCI address [0xfdfe0000-0xfdfeffff]
> [ 32.363711] bonding: bond0: enslaving eth2 as a backup interface
> with a down link.
>
>
>
> For bnx2, it seems commit 212f9934afccf9c9739921
> was not sufficient to correct the "scheduling while atomic" bug...
> enslaving a bnx2 on a bond device with one vlan already set :
> bond_enslave -> bnx2_vlan_rx_register -> bnx2_netif_stop ->
> bnx2_napi_disable -> msleep()
>
There are a number of drivers that call napi_disable() during
->ndo_vlan_rx_regsiter(). bnx2 is lockless in the rx path and so we
need to disable NAPI rx processing and wait for it to be done before
modifying the vlgrp.
Jay, is there an alternative to holding the bond->lock when calling the
slave's ->ndo_vlan_rx_register()?
^ permalink raw reply
* Re: Very low latency TCP for clusters
From: Rick Jones @ 2010-07-19 18:13 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev
In-Reply-To: <AANLkTilNmNZbFWS8LF-UHU65QYIC32HZlgVZ7lXJHxPh@mail.gmail.com>
Tom Herbert wrote:
> We have been looking at best case TCP latencies that might be achieved
> within a cluster (low loss fabric). The goal is to have latency
> numbers roughly comparable to that which can be produced using RDMA/IB
> in a low latency configuration (<5 usecs round trip on netperf TCP_RR
> test with one byte data for directly connected hosts as a starting
> point). This would be without changing sockets API, fabric, and
> preferably not using TCP offload or a user space stack.
>
> I think there are at least two techniques that will drive down TCP
> latency: per connection queues and polling queues. Per connection
> queues (supported by device) should eliminate costs of connection
> look-up, hopefully some locking. Polling becomes viable as core
> counts on systems increase, and burning a few CPUs for networking
> polling on behalf of very low-latency threads would be reasonable.
Likely preaching to the choir - but "just so long as it doesn't give the
system's coherence fits." Every once and again there are things stuck into the
idle loop of various OSes on the premis that it is only burning cycles on that
idle core, but ends-up trashing cache lines and/or the memory subsystem and so
drags-down other cores.
Just how close to even 5 usecs/tran is the service demand on a TCP_RR test now?
The best I've seen for a 10GbE NIC under SLES11 SP1 (sorry, not latest
upstream) has been 10-12.6 usec/tran, but the range went as high as 20 or more -
depended on where netperf/netserver were running relative to the interrupt CPU:
ftp://ftp.netperf.org/netperf/misc/dl380g6_X5560_sles11sp1_ad386a_cxgb3_1.1.3-ko_b2b_to_same_1500mtu_20100602.csv
ftp://ftp.netperf.org/netperf/misc/dl380g6_X5560_sles11sp1_nc550_be2net_2.102.147s_b2b_to_same_1500mtu_20100520.csv
Getting rid of connection lookup and some locking will no doubt be necessary,
but I suspect there will be a lot more to it as well. Quite a few sacred
path-length cows may have to be slaughtered along the way to get the service
demand << 5 microseconds to allow the < 5 usec RTT.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: Very low latency TCP for clusters
From: Eric Dumazet @ 2010-07-19 17:41 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev
In-Reply-To: <AANLkTilNmNZbFWS8LF-UHU65QYIC32HZlgVZ7lXJHxPh@mail.gmail.com>
Le lundi 19 juillet 2010 à 10:05 -0700, Tom Herbert a écrit :
> We have been looking at best case TCP latencies that might be achieved
> within a cluster (low loss fabric). The goal is to have latency
> numbers roughly comparable to that which can be produced using RDMA/IB
> in a low latency configuration (<5 usecs round trip on netperf TCP_RR
> test with one byte data for directly connected hosts as a starting
> point). This would be without changing sockets API, fabric, and
> preferably not using TCP offload or a user space stack.
>
> I think there are at least two techniques that will drive down TCP
> latency: per connection queues and polling queues. Per connection
> queues (supported by device) should eliminate costs of connection
> look-up, hopefully some locking. Polling becomes viable as core
> counts on systems increase, and burning a few CPUs for networking
> polling on behalf of very low-latency threads would be reasonable.
>
> Are there any efforts in progress to integrate per connection queues
> in the stack or integrate polling of queues?
aka "net channel" ;)
What a nightmare...
Anyway, 5 us roundtrip TCP_RR (including user thread work), seems a bit
utopic right now.
Even on loopback
^ permalink raw reply
* Re: [PATCHv2] tcp: fix crash in tcp_xmit_retransmit_queue
From: Eric Dumazet @ 2010-07-19 17:39 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Lennart Schulte, David Miller, Tejun Heo, lkml,
netdev@vger.kernel.org, Fehrmann, Henning, Carsten Aulbert
In-Reply-To: <alpine.DEB.2.00.1007192013010.30181@melkinpaasi.cs.helsinki.fi>
Le lundi 19 juillet 2010 à 20:25 +0300, Ilpo Järvinen a écrit :
> This difference is well thought and intentional, I didn't use different
> one by accident. We want to make sure we won't use NULL from
> tcp_write_queue_head() while the pre 08ebd1721ab8fd3 kernels was
> interested mainly whether the first loop should run or not (and of course
> ends up avoid the null deref too but it's more optimization like
> thing in there, ie., if there's no lost packets no work to-do). The deref
> could have been fixed by moving TCP_SKB_CB(skb)->sacked a bit later but
> that would again make us depend on the side-effect of the send_head check
> (in the case of packets_out being zero and wq empty) which is something I
> don't like too much.
>
Thanks Ilpo.
Do you know in what exact circumstance the bug triggers ?
It's hard to believe thousand of machines on the Internet never hit
it :(
Maybe another problem in congestion control ?
^ permalink raw reply
* Re: Very low latency TCP for clusters
From: David Miller @ 2010-07-19 17:35 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <AANLkTilNmNZbFWS8LF-UHU65QYIC32HZlgVZ7lXJHxPh@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 19 Jul 2010 10:05:19 -0700
> Per connection queues (supported by device) should eliminate costs
> of connection look-up, hopefully some locking.
What are these per-connection queues exactly?
Is it like GRO and just accumulates in-order packets for a flow?
Or it is something more like Jacobson's net channels?
If it's the former, we have it already. If it's the
latter we've found it to be utterly impractical due to all
of the facilities we have which live between the device
and the socket layer (netfilter, packet scheduler, IPSEC,
etc.)
^ permalink raw reply
* Re: [PATCHv2] tcp: fix crash in tcp_xmit_retransmit_queue
From: Ilpo Järvinen @ 2010-07-19 17:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: Lennart Schulte, David Miller, Tejun Heo, lkml,
netdev@vger.kernel.org, Fehrmann, Henning, Carsten Aulbert
In-Reply-To: <1279548555.2553.51.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2153 bytes --]
On Mon, 19 Jul 2010, Eric Dumazet wrote:
> Le lundi 19 juillet 2010 à 14:16 +0300, Ilpo Järvinen a écrit :
>
> > Thanks for testing.
> >
> > DaveM, I think this oops was introduced for 2.6.28 (in
> > 08ebd1721ab8fd362e90ae17b461c07b23fa2824 it seems, to be exact) so to
> > stables it should go too please. I've only tweaked the message (so no need
> > for Lennart to retest v2 :-)).
> >
> > --
> > [PATCHv2] tcp: fix crash in tcp_xmit_retransmit_queue
> >
> > It can happen that there are no packets in queue while calling
> > tcp_xmit_retransmit_queue(). tcp_write_queue_head() then returns
> > NULL and that gets deref'ed to get sacked into a local var.
> >
> > There is no work to do if no packets are outstanding so we just
> > exit early.
> >
> > This oops was introduced by 08ebd1721ab8fd (tcp: remove tp->lost_out
> > guard to make joining diff nicer).
> >
>
> But prior to commit 08ebd1721ab8fd3, we were not testing
> tp->packets_out, but tp->lost_out
That's right, but back then we were not testing it for the same purpose.
> if it was 0, we were not doing the tcp_for_write_queue_from() loop.
This invariant _should_ be true all the time:
lost_out <= packets_out
...and if it's not we would get Leak printouts every now and then. Thus is
packets_out is zero no NULL defer with the if lost_out either. The other
loop too (in pre 08eb kernels) will work because of earlier mentioned
send_head check side-effects.
> Not sure it makes a difference ?
This difference is well thought and intentional, I didn't use different
one by accident. We want to make sure we won't use NULL from
tcp_write_queue_head() while the pre 08ebd1721ab8fd3 kernels was
interested mainly whether the first loop should run or not (and of course
ends up avoid the null deref too but it's more optimization like
thing in there, ie., if there's no lost packets no work to-do). The deref
could have been fixed by moving TCP_SKB_CB(skb)->sacked a bit later but
that would again make us depend on the side-effect of the send_head check
(in the case of packets_out being zero and wq empty) which is something I
don't like too much.
--
i.
^ permalink raw reply
* Re: Raise initial congestion window size / speedup slow start?
From: Rick Jones @ 2010-07-19 17:08 UTC (permalink / raw)
To: H.K. Jerry Chu
Cc: Patrick McManus, David Miller, davidsen, lists, linux-kernel,
netdev
In-Reply-To: <AANLkTil_c-TH6k2BDW2r5c0HYXFxiu85aMda1bT0nJt3@mail.gmail.com>
H.K. Jerry Chu wrote:
> On Fri, Jul 16, 2010 at 10:01 AM, Patrick McManus <mcmanus@ducksong.com> wrote:
>>can you tell us more about the impl concerns of initcwnd stored on the
>>route?
>
>
> We have found two issues when altering initcwnd through the ip route cmd:
> 1. initcwnd is actually capped by sndbuf (i.e., tcp_wmem[1], which is
> defaulted to a small value of 16KB). This problem has been made obscured
> by the TSO code, which fudges the flow control limit (and could be a bug by
> itself).
I'll ask my Emily Litella question of the day and inquire as to why that would
be unique to altering initcwnd via the route?
The slightly less Emily Litella-esque question is why an appliction with a
desire to know it could send more than 16K at one time wouldn't have either
asked via its install docs to have the minimum tweaked (certainly if one is
already tweaking routes...), or "gone all the way" and made an explicit
setsockopt(SO_SNDBUF) call? We are in a realm of applications for which there
was a proposal to allow them to pick their own initcwnd right? Having them pick
an SO_SNDBUF size would seem to be no more to ask.
rick jones
sendbuf_init = max(tcp_mem,initcwnd)?
^ permalink raw reply
* Very low latency TCP for clusters
From: Tom Herbert @ 2010-07-19 17:05 UTC (permalink / raw)
To: netdev
We have been looking at best case TCP latencies that might be achieved
within a cluster (low loss fabric). The goal is to have latency
numbers roughly comparable to that which can be produced using RDMA/IB
in a low latency configuration (<5 usecs round trip on netperf TCP_RR
test with one byte data for directly connected hosts as a starting
point). This would be without changing sockets API, fabric, and
preferably not using TCP offload or a user space stack.
I think there are at least two techniques that will drive down TCP
latency: per connection queues and polling queues. Per connection
queues (supported by device) should eliminate costs of connection
look-up, hopefully some locking. Polling becomes viable as core
counts on systems increase, and burning a few CPUs for networking
polling on behalf of very low-latency threads would be reasonable.
Are there any efforts in progress to integrate per connection queues
in the stack or integrate polling of queues?
Thanks,
Tom
^ permalink raw reply
* Re: [PATCH 2.6.35-rc1] net-next: vmxnet3 fixes [4/5] Do not reset when the device is not opened
From: Shreyas Bhatewara @ 2010-07-19 17:02 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
pv-drivers@vmware.com, Ronghua Zhang, Matthieu Bucchianeri
In-Reply-To: <20100717.163538.137865264.davem@davemloft.net>
On Sat, 17 Jul 2010, David Miller wrote:
> From: Shreyas Bhatewara <sbhatewara@vmware.com>
> Date: Fri, 16 Jul 2010 01:17:29 -0700 (PDT)
>
> >
> >
> > On Thu, 15 Jul 2010, David Miller wrote:
> >
> >> From: Shreyas Bhatewara <sbhatewara@vmware.com>
> >> Date: Thu, 15 Jul 2010 18:20:52 -0700 (PDT)
> >>
> >> > Is this what you suggest :
> >> >
> >> > ---
> >> >
> >> > Hold rtnl_lock to get the right link state.
> >>
> >> It ought to work, but make sure that it is legal to take the
> >> RTNL semaphore in all contexts in which this code block
> >> might be called.
> >>
> >
> > This code block is called only from the workqueue handler, which runs in
> > process context, so it is legal to take rtnl semaphore.
> > Tested this code by simulating event interrupts (which schedule this
> > code) at considerable frequency while the interface was brought up and
> > down in a loop. Similar stress testing had revealed the bug originally.
>
> Awesome, please submit this formally. The copy you sent lacked a commit
> message and signoff.
>
Reposting the patch formally.
David,
Thanks for your coperation.
->Shreyas
---
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Hold rtnl_lock to get the right link state.
While asynchronously resetting the device, hold rtnl_lock to get the
right value from netif_running. If a reset is scheduled, and the device
goes thru close and open, it may happen that reset and open may run in
parallel. Holding rtnl_lock will avoid this.
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 1b0ce8c..c4d7e42 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2420,6 +2420,7 @@ vmxnet3_reset_work(struct work_struct *data)
return;
/* if the device is closed, we must leave it alone */
+ rtnl_lock();
if (netif_running(adapter->netdev)) {
printk(KERN_INFO "%s: resetting\n", adapter->netdev->name);
vmxnet3_quiesce_dev(adapter);
@@ -2428,6 +2429,7 @@ vmxnet3_reset_work(struct work_struct *data)
} else {
printk(KERN_INFO "%s: already closed\n", adapter->netdev->name);
}
+ rtnl_unlock();
clear_bit(VMXNET3_STATE_BIT_RESETTING, &adapter->state);
}
^ permalink raw reply related
* RE: [PATCH] Export SMBIOS provided firmware instance and label to sysfs
From: Narendra_K @ 2010-07-19 16:54 UTC (permalink / raw)
To: Narendra_K, greg
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <20100714121345.GA20411@auslistsprd01.us.dell.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Narendra K
> Sent: Wednesday, July 14, 2010 5:44 PM
> To: greg@kroah.com
> Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; linux-
> pci@vger.kernel.org; Domsch, Matt; Rose, Charles; Hargrave, Jordan;
> Nijhawan, Vijay
> Subject: Re: [PATCH] Export SMBIOS provided firmware instance and
label
> to sysfs
>
>
> V1 -> V2:
>
> 1. The 'smbios_attr' buffer is not being used as mentioned above
>
> 2. The function 'smbios_instance_string_exist' is split into two
> functions,
> the other being 'find_smbios_instance_string' which would print the
> result
> into the sysfs provided 'buf' of associated device. The function
> 'smbios_instance_string_exist' would let us know if the label exists
or
> not.
>
> Please find the patch with above changes here -
>
> From: Narendra K <narendra_k@dell.com>
> Subject: [PATCH] Export SMBIOS provided firmware instance and label to
> sysfs
>
Greg,
Thanks for the review comments.
This version of the patch has all the suggestions incorporated. Please
let us know if there are any concerns. If the approach is acceptable,
please consider this patch for inclusion.
With regards,
Narendra K
^ permalink raw reply
* Re: [0/8] netpoll/bridge fixes
From: Eric Dumazet @ 2010-07-19 16:52 UTC (permalink / raw)
To: David Miller; +Cc: herbert, mst, shemminger, frzhang, netdev, amwang, mpm
In-Reply-To: <20100719.090503.73693858.davem@davemloft.net>
Le lundi 19 juillet 2010 à 09:05 -0700, David Miller a écrit :
> I thought we did that already.... oh I see, we did it for bonding:
>
> commit c22d7ac844f1cb9c6a5fd20f89ebadc2feef891b
> Author: Andy Gospodarek <andy@greyhouse.net>
> Date: Fri Jun 25 09:50:44 2010 +0000
>
BTW, this added following warning :
[PATCH] bonding: avoid a warning
drivers/net/bonding/bond_main.c:179:12: warning: ‘disable_netpoll’
defined but not used
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 8228088..20f45cb 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -176,7 +176,9 @@ static int arp_ip_count;
static int bond_mode = BOND_MODE_ROUNDROBIN;
static int xmit_hashtype = BOND_XMIT_POLICY_LAYER2;
static int lacp_fast;
+#ifdef CONFIG_NET_POLL_CONTROLLER
static int disable_netpoll = 1;
+#endif
const struct bond_parm_tbl bond_lacp_tbl[] = {
{ "slow", AD_LACP_SLOW},
^ 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