* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: Tom Herbert @ 2011-11-29 18:31 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20111129.124715.163094087536706067.davem@davemloft.net>
On Tue, Nov 29, 2011 at 9:47 AM, David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 29 Nov 2011 17:46:24 +0100
>
>> I did sucessful tests with tg3 (I'll provide the patch for bnx2 shortly)
>>
>> Some details probably can be polished, but I believe your v4 is ready
>> for inclusion.
>>
>> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Agreed, all applied to net-next, thanks!
>
> Tom, please keep an eye out for regression or suggestion reports.
>
Will do. I am well aware of how invasive this is in the data path ;-)
I'll add a doc describing BQL also.
By the way, the way to disable BQL at runtime is the 'echo max >
/sys/class/net/eth<n>/queues/tx-<m>/byte_queue_limits/limit_min
> Thanks again.
>
Thanks Dave, Eric, Dave Taht, and everyone for reviewing this.
Tom
^ permalink raw reply
* Re: [PATCH net-next] sch_choke: use skb_flow_dissect()
From: David Miller @ 2011-11-29 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322576535.2465.8.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 15:22:15 +0100
> Instead of using a custom flow dissector, use skb_flow_dissect() and
> benefit from tunnelling support.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sch_sfq: use skb_flow_dissect()
From: David Miller @ 2011-11-29 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322574045.2465.5.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 14:40:45 +0100
> Instead of using a custom flow dissector, use skb_flow_dissect() and
> benefit from tunnelling support.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp: avoid frag allocation for small frames
From: David Miller @ 2011-11-29 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, subramanian.vijay
In-Reply-To: <1322556107.2970.82.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 09:41:47 +0100
> tcp_sendmsg() uses select_size() helper to choose skb head size when a
> new skb must be allocated.
>
> If GSO is enabled for the socket, current strategy is to force all
> payload data to be outside of headroom, in PAGE fragments.
>
> This strategy is not welcome for small packets, wasting memory.
>
> Experiments show that best results are obtained when using 2048 bytes
> for skb head (This includes the skb overhead and various headers)
>
> This patch provides better len/truesize ratios for packets sent to
> loopback device, and reduce memory needs for in-flight loopback packets,
> particularly on arches with big pages.
>
> If a sender sends many 1-byte packets to an unresponsive application,
> receiver rmem_alloc will grow faster and will stop queuing these packets
> sooner, or will collapse its receive queue to free excess memory.
>
> netperf -t TCP_RR results are improved by ~4 %, and many workloads are
> improved as well (tbench, mysql...)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] flow_dissector: use a 64bit load/store
From: David Miller @ 2011-11-29 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322548235.2970.57.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 07:30:35 +0100
> [PATCH net-next] flow_dissector: use a 64bit load/store
>
> gcc compiler is smart enough to use a single load/store if we
> memcpy(dptr, sptr, 8) on x86_64, regardless of
> CONFIG_CC_OPTIMIZE_FOR_SIZE
>
> In IP header, daddr immediately follows saddr, this wont change in the
> future. We only need to make sure our flow_keys (src,dst) fields wont
> break the rule.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* RCU'ed dst_get_neighbour()
From: Marc Aurele La France @ 2011-11-29 17:44 UTC (permalink / raw)
To: netdev, eric.dumazet
Hi.
Commit (1) seems to imply that all dst_get_neighbour() references now need
to be wrapped with rcu_read_lock()/rcu_read_unlock() sequences. See (2)
for one such proposed change.
In the case I have here (ipoib), this commit results in ...
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/net/dst.h:91 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
4 locks held by kworker/3:1/630:
#0: (ib_cm){.+.+.+}, at: [<ffffffff81055735>]
process_one_work+0x1ab/0x4f9
#1: ((&(&work->work)->work)){+.+.+.}, at: [<ffffffff81055735>]
process_one_work+0x1ab/0x4f9
#2: (rcu_read_lock_bh){.+....}, at: [<ffffffff81388216>]
dev_queue_xmit+0x0/0x5ae
#3: (_xmit_INFINIBAND){+.-...}, at: [<ffffffff8139eecc>]
sch_direct_xmit+0x4d/0x22b
stack backtrace:
Pid: 630, comm: kworker/3:1 Not tainted 3.1.3-smp #1
Call Trace:
[<ffffffff8106c385>] lockdep_rcu_dereference+0x9b/0xa4
[<ffffffff81351cda>] ipoib_start_xmit+0xf4/0x36f
[<ffffffff81384215>] dev_hard_start_xmit+0x2a7/0x54f
[<ffffffff8139eeef>] sch_direct_xmit+0x70/0x22b
[<ffffffff8138851f>] dev_queue_xmit+0x309/0x5ae
[<ffffffff81388216>] ? napi_gro_receive+0xb3/0xb3
[<ffffffff813582d3>] ipoib_cm_rep_handler+0x208/0x248
[<ffffffff81433e16>] ? _raw_spin_unlock_irqrestore+0x3d/0x5b
[<ffffffff8135a912>] ipoib_cm_tx_handler+0x95/0x27f
[<ffffffff8106d183>] ? __trace_hardirqs_on_caller+0x41/0x65
[<ffffffff81327b29>] cm_process_work+0x26/0xbc
[<ffffffff81328d74>] cm_rep_handler+0x274/0x2ae
[<ffffffff81329582>] cm_work_handler+0x41/0x91
[<ffffffff8105582c>] process_one_work+0x2a2/0x4f9
[<ffffffff81055735>] ? process_one_work+0x1ab/0x4f9
[<ffffffff810580c6>] ? worker_thread+0x4a/0x1ca
[<ffffffff81329541>] ? cm_req_handler+0x355/0x355
[<ffffffff81058175>] worker_thread+0xf9/0x1ca
[<ffffffff8105807c>] ? gcwq_mayday_timeout+0x77/0x77
[<ffffffff8105bfa3>] kthread+0x86/0x8e
[<ffffffff81436b34>] kernel_thread_helper+0x4/0x10
[<ffffffff8143425d>] ? retint_restore_args+0xe/0xe
[<ffffffff8105bf1d>] ? kthread_stop+0x1cd/0x1cd
[<ffffffff81436b30>] ? gs_change+0xb/0xb
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/net/dst.h:91 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
2 locks held by kworker/u:2/748:
#0: ((name)){.+.+.+}, at: [<ffffffff81055735>]
process_one_work+0x1ab/0x4f9
#1: ((&port_priv->work)){+.+.+.}, at: [<ffffffff81055735>]
process_one_work+0x1ab/0x4f9
stack backtrace:
Pid: 748, comm: kworker/u:2 Not tainted 3.1.3-smp #1
Call Trace:
[<ffffffff8106c385>] lockdep_rcu_dereference+0x9b/0xa4
[<ffffffff81354e68>] ipoib_mcast_join_finish+0x362/0x48a
[<ffffffff81355481>] ipoib_mcast_sendonly_join_complete+0x3b/0x174
[<ffffffff813246b3>] mcast_work_handler+0xba/0x182
[<ffffffff813248aa>] join_handler+0xe6/0xee
[<ffffffff81322af1>] ib_sa_mcmember_rec_callback+0x51/0x5c
[<ffffffff8132289c>] recv_handler+0x44/0x50
[<ffffffff8131efca>] ib_mad_complete_recv+0xc3/0x125
[<ffffffff8131debe>] ? find_mad_agent+0x13a/0x149
[<ffffffff8131f30a>] ib_mad_recv_done_handler+0x2de/0x326
[<ffffffff8131f3b0>] ib_mad_completion_handler+0x5e/0x91
[<ffffffff8105582c>] process_one_work+0x2a2/0x4f9
[<ffffffff81055735>] ? process_one_work+0x1ab/0x4f9
[<ffffffff810580c6>] ? worker_thread+0x4a/0x1ca
[<ffffffff8131f352>] ? ib_mad_recv_done_handler+0x326/0x326
[<ffffffff81058175>] worker_thread+0xf9/0x1ca
[<ffffffff8105807c>] ? gcwq_mayday_timeout+0x77/0x77
[<ffffffff8105bfa3>] kthread+0x86/0x8e
[<ffffffff81436b34>] kernel_thread_helper+0x4/0x10
[<ffffffff8143425d>] ? retint_restore_args+0xe/0xe
[<ffffffff8105bf1d>] ? kthread_stop+0x1cd/0x1cd
[<ffffffff81436b30>] ? gs_change+0xb/0xb
Comments/flames?
Thanks.
Marc.
PS: Please reply-to-all as I am not subscribed to netdev.
(1) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f2c31e32b378a6653f8de606149d963baf11d7d3
(2) http://www.spinics.net/lists/netdev/msg179639.html
+----------------------------------+----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and | fax: 1-780-492-1729 |
| Communications Technologies | email: tsi@ualberta.ca |
| 352 General Services Building +----------------------------------+
| University of Alberta | |
| Edmonton, Alberta | Standard disclaimers apply |
| T6G 2H1 | |
| CANADA | |
+----------------------------------+----------------------------------+
^ permalink raw reply
* RE: [PATCH] staging: hv: move hv_netvsc out of staging area
From: Haiyang Zhang @ 2011-11-29 18:05 UTC (permalink / raw)
To: Greg KH
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, NetDev
In-Reply-To: <20111129151638.GB24688@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Tuesday, November 29, 2011 10:17 AM
> To: Haiyang Zhang
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; NetDev
> Subject: Re: [PATCH] staging: hv: move hv_netvsc out of staging area
> > I have rebased the previous patch on the latest staging-next branch,
> > and re-submitting it now. In another email, the same patch was
> > submitted without using the "-M" flag, in case anyone wants to read
> > the unchanged code in the patch body.
>
> This one was fine, now applied, thanks.
Thank you!
- Haiyang
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Konrad Rzeszutek Wilk @ 2011-11-29 18:04 UTC (permalink / raw)
To: Rafael J. Wysocki, tglx, mingo, hpa, x86, borislav.petkov
Cc: Linux SCSI List, Florian Mickler, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI, Linux ACPI,
Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
In-Reply-To: <20111122135412.GA29905@phenom.dumpdata.com>
On Tue, Nov 22, 2011 at 08:54:12AM -0500, Konrad Rzeszutek Wilk wrote:
> > Subject : Regression in 3.1 causes Xen to use wrong idle routine
> > Submitter : Stefan Bader <stefan.bader@canonical.com>
> > Date : 2011-10-26 10:24
> > Message-ID : 4EA7DFD1.9060608@canonical.com
> > References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2
>
> The patch mentioned in http://mid.gmane.org/20111115144004.GE22675@phenom.dumpdata.com
> should do it. But the patch needs an Ack from ACPI/x86 folks.
This patch (mentioned in the URL above) fixes the issue. Could it be
applied to the x86 tree for 3.2 or get an Ack, please?
>From 4f10ec7a7b9ff24657696aa98f25bcecde247373 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 21 Nov 2011 18:02:02 -0500
Subject: [PATCH] xen/pm_idle: Make pm_idle be default_idle under Xen.
This patch:
commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
Author: Len Brown <len.brown@intel.com>
Date: Fri Apr 1 18:28:35 2011 -0400
cpuidle: replace xen access to x86 pm_idle and default_idle
..scribble on pm_idle and access default_idle,
have it simply disable_cpuidle() so acpi_idle will not load and
architecture default HLT will be used.
idea was to have one call - disable_cpuidle() which would make
pm_idle not be molested by other code. It disallows cpuidle_idle_call
and acpi_idle_call to not set pm_idle (which is excellent). But the
amd_e400_idle and mwait_idle can still setup pm_idle which we really
do not want. In case of mwait_idle we can hit some instances where:
Brought up 2 CPUs
invalid opcode: 0000 [#1] SMP
CPU 1
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
RIP: e030:[<ffffffff81015d1d>] [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
RSP: e02b:ffff8801d28ddf10 EFLAGS: 00010082
RAX: ffff8801d28dc010 RBX: ffff8801d28ddfd8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
RBP: ffff8801d28ddf10 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000001 R11: ffff8801d28ddfd8 R12: ffffffff81b590d0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8801dff81000(0000) knlGS:0000000000000000
CS: e033 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001a05000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000
Process swapper (pid: 0, threadinfo ffff8801d28dc000, task ffff8801d28cae60)
Stack:
ffff8801d28ddf40 ffffffff8100e2ed ffff8801dff8e390 c136dfe72feab515
0000000000000000 0000000000000000 ffff8801d28ddf50 ffffffff8149ee78
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
[<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
[<ffffffff8149ee78>] cpu_bringup_and_idle+0xe/0x10
RIP [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
RSP <ffff8801d28ddf10>
RH BZ #739499 and Ubuntu #881076
In case of amd_e400_idle we don't get so spectacular crashes, but
we do end up making an MSR which is trapped in the hypervisor,
and then follow it up with a yield hypercall. Meaning we end up
going to hypervisor twice instead of just once.
Lets make pm_idle be default_idle to take care of that.
Reported-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
arch/x86/include/asm/system.h | 1 +
arch/x86/kernel/process.c | 8 ++++++++
arch/x86/xen/setup.c | 2 +-
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index c2ff2a1..2d2f01c 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
void default_idle(void);
+bool set_pm_idle_to_default(void);
void stop_this_cpu(void *dummy);
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 1f7f8c8..336b299 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -404,6 +404,14 @@ void default_idle(void)
EXPORT_SYMBOL(default_idle);
#endif
+bool set_pm_idle_to_default()
+{
+ if (!pm_idle) {
+ pm_idle = default_idle;
+ return true;
+ }
+ return false;
+}
void stop_this_cpu(void *dummy)
{
local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..7506181 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
#endif
disable_cpuidle();
boot_option_idle_override = IDLE_HALT;
-
+ WARN_ON(!set_pm_idle_to_default());
fiddle_vdso();
}
--
1.7.7.3
^ permalink raw reply related
* Re: RCU'ed dst_get_neighbour()
From: Eric Dumazet @ 2011-11-29 18:01 UTC (permalink / raw)
To: Marc Aurele La France; +Cc: netdev
In-Reply-To: <alpine.WNT.2.00.1111291027320.1036@TSI>
Le mardi 29 novembre 2011 à 10:44 -0700, Marc Aurele La France a écrit :
> Hi.
>
> Commit (1) seems to imply that all dst_get_neighbour() references now need
> to be wrapped with rcu_read_lock()/rcu_read_unlock() sequences. See (2)
> for one such proposed change.
>
> In the case I have here (ipoib), this commit results in ...
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> include/net/dst.h:91 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 1
> 4 locks held by kworker/3:1/630:
> #0: (ib_cm){.+.+.+}, at: [<ffffffff81055735>]
> process_one_work+0x1ab/0x4f9
> #1: ((&(&work->work)->work)){+.+.+.}, at: [<ffffffff81055735>]
> process_one_work+0x1ab/0x4f9
> #2: (rcu_read_lock_bh){.+....}, at: [<ffffffff81388216>]
> dev_queue_xmit+0x0/0x5ae
> #3: (_xmit_INFINIBAND){+.-...}, at: [<ffffffff8139eecc>]
> sch_direct_xmit+0x4d/0x22b
>
> stack backtrace:
> Pid: 630, comm: kworker/3:1 Not tainted 3.1.3-smp #1
> Call Trace:
> [<ffffffff8106c385>] lockdep_rcu_dereference+0x9b/0xa4
> [<ffffffff81351cda>] ipoib_start_xmit+0xf4/0x36f
> [<ffffffff81384215>] dev_hard_start_xmit+0x2a7/0x54f
> [<ffffffff8139eeef>] sch_direct_xmit+0x70/0x22b
> [<ffffffff8138851f>] dev_queue_xmit+0x309/0x5ae
> [<ffffffff81388216>] ? napi_gro_receive+0xb3/0xb3
> [<ffffffff813582d3>] ipoib_cm_rep_handler+0x208/0x248
> [<ffffffff81433e16>] ? _raw_spin_unlock_irqrestore+0x3d/0x5b
> [<ffffffff8135a912>] ipoib_cm_tx_handler+0x95/0x27f
> [<ffffffff8106d183>] ? __trace_hardirqs_on_caller+0x41/0x65
> [<ffffffff81327b29>] cm_process_work+0x26/0xbc
> [<ffffffff81328d74>] cm_rep_handler+0x274/0x2ae
> [<ffffffff81329582>] cm_work_handler+0x41/0x91
> [<ffffffff8105582c>] process_one_work+0x2a2/0x4f9
> [<ffffffff81055735>] ? process_one_work+0x1ab/0x4f9
> [<ffffffff810580c6>] ? worker_thread+0x4a/0x1ca
> [<ffffffff81329541>] ? cm_req_handler+0x355/0x355
> [<ffffffff81058175>] worker_thread+0xf9/0x1ca
> [<ffffffff8105807c>] ? gcwq_mayday_timeout+0x77/0x77
> [<ffffffff8105bfa3>] kthread+0x86/0x8e
> [<ffffffff81436b34>] kernel_thread_helper+0x4/0x10
> [<ffffffff8143425d>] ? retint_restore_args+0xe/0xe
> [<ffffffff8105bf1d>] ? kthread_stop+0x1cd/0x1cd
> [<ffffffff81436b30>] ? gs_change+0xb/0xb
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> include/net/dst.h:91 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 1
> 2 locks held by kworker/u:2/748:
> #0: ((name)){.+.+.+}, at: [<ffffffff81055735>]
> process_one_work+0x1ab/0x4f9
> #1: ((&port_priv->work)){+.+.+.}, at: [<ffffffff81055735>]
> process_one_work+0x1ab/0x4f9
>
> stack backtrace:
> Pid: 748, comm: kworker/u:2 Not tainted 3.1.3-smp #1
> Call Trace:
> [<ffffffff8106c385>] lockdep_rcu_dereference+0x9b/0xa4
> [<ffffffff81354e68>] ipoib_mcast_join_finish+0x362/0x48a
> [<ffffffff81355481>] ipoib_mcast_sendonly_join_complete+0x3b/0x174
> [<ffffffff813246b3>] mcast_work_handler+0xba/0x182
> [<ffffffff813248aa>] join_handler+0xe6/0xee
> [<ffffffff81322af1>] ib_sa_mcmember_rec_callback+0x51/0x5c
> [<ffffffff8132289c>] recv_handler+0x44/0x50
> [<ffffffff8131efca>] ib_mad_complete_recv+0xc3/0x125
> [<ffffffff8131debe>] ? find_mad_agent+0x13a/0x149
> [<ffffffff8131f30a>] ib_mad_recv_done_handler+0x2de/0x326
> [<ffffffff8131f3b0>] ib_mad_completion_handler+0x5e/0x91
> [<ffffffff8105582c>] process_one_work+0x2a2/0x4f9
> [<ffffffff81055735>] ? process_one_work+0x1ab/0x4f9
> [<ffffffff810580c6>] ? worker_thread+0x4a/0x1ca
> [<ffffffff8131f352>] ? ib_mad_recv_done_handler+0x326/0x326
> [<ffffffff81058175>] worker_thread+0xf9/0x1ca
> [<ffffffff8105807c>] ? gcwq_mayday_timeout+0x77/0x77
> [<ffffffff8105bfa3>] kthread+0x86/0x8e
> [<ffffffff81436b34>] kernel_thread_helper+0x4/0x10
> [<ffffffff8143425d>] ? retint_restore_args+0xe/0xe
> [<ffffffff8105bf1d>] ? kthread_stop+0x1cd/0x1cd
> [<ffffffff81436b30>] ? gs_change+0xb/0xb
>
> Comments/flames?
>
> Thanks.
>
> Marc.
>
> PS: Please reply-to-all as I am not subscribed to netdev.
>
> (1) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f2c31e32b378a6653f8de606149d963baf11d7d3
> (2) http://www.spinics.net/lists/netdev/msg179639.html
>
> +----------------------------------+----------------------------------+
> | Marc Aurele La France | work: 1-780-492-9310 |
> | Academic Information and | fax: 1-780-492-1729 |
> | Communications Technologies | email: tsi@ualberta.ca |
> | 352 General Services Building +----------------------------------+
> | University of Alberta | |
> | Edmonton, Alberta | Standard disclaimers apply |
> | T6G 2H1 | |
> | CANADA | |
> +----------------------------------+----------------------------------+
Thanks for the report Marc, I'll take a look asap.
^ permalink raw reply
* Re: [patch] net/netlabel: copy and paste bug in netlbl_cfg_unlbl_map_add()
From: Paul Moore @ 2011-11-29 17:47 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David S. Miller, netdev, kernel-janitors
In-Reply-To: <20111124071820.GB14122@elgon.mountain>
On Thursday, November 24, 2011 10:18:20 AM Dan Carpenter wrote:
> This was copy and pasted from the IPv4 code. We're calling the
> ip4 version of that function and map4 is NULL.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
> index 8ed67dcc..3735297 100644
> --- a/net/netlabel/netlabel_kapi.c
> +++ b/net/netlabel/netlabel_kapi.c
> @@ -162,8 +162,8 @@ int netlbl_cfg_unlbl_map_add(const char *domain,
> map6->list.addr.s6_addr32[3] &= mask6->s6_addr32[3];
> map6->list.mask = *mask6;
> map6->list.valid = 1;
> - ret_val = netlbl_af4list_add(&map4->list,
> - &addrmap->list4);
> + ret_val = netlbl_af6list_add(&map6->list,
> + &addrmap->list6);
> if (ret_val != 0)
> goto cfg_unlbl_map_add_failure;
> break;
Thanks for fixing this. I actually stumbled across this just last week while
working on the CALIPSO stuff and queued up a patch but didn't get a chance to
verify it before Thanksgiving - you just saved me the effort :)
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [RFC] sky2: add bql support
From: David Miller @ 2011-11-29 17:47 UTC (permalink / raw)
To: shemminger; +Cc: therbert, netdev
In-Reply-To: <20111128201907.6d31d4c3@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 28 Nov 2011 20:19:07 -0800
> Just for testing, here is how to add BQL support to sky2
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Let me know when you have a final version of this, thanks.
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: David Miller @ 2011-11-29 17:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, netdev
In-Reply-To: <1322585184.2465.36.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 29 Nov 2011 17:46:24 +0100
> I did sucessful tests with tg3 (I'll provide the patch for bnx2 shortly)
>
> Some details probably can be polished, but I believe your v4 is ready
> for inclusion.
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Agreed, all applied to net-next, thanks!
Tom, please keep an eye out for regression or suggestion reports.
Thanks again.
^ permalink raw reply
* Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: Peng Tao @ 2011-11-29 17:30 UTC (permalink / raw)
To: Trond Myklebust
Cc: J. Bruce Fields, tao.peng-mb1K0bWo544,
skinsbursky-bzQdu9zFT3WakBO8gow8eQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <1322587165.4174.20.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
On Wed, Nov 30, 2011 at 1:19 AM, Trond Myklebust
<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, 2011-11-29 at 11:42 -0500, J. Bruce Fields wrote:
>> On Tue, Nov 29, 2011 at 11:40:30AM -0500, Trond Myklebust wrote:
>> > I mean that I'm perfectly entitled to do
>> >
>> > 'modprobe -r blocklayoutdriver'
>> >
>> > and when I do that, then I expect blkmapd to close the rpc pipe and wait
>> > for a new one to be created just like rpc.idmapd and rpc.gssd do when I
>> > remove the nfs and sunrpc modules.
>>
>> The rpc pipefs mount doesn't hold a reference on the sunrpc module?
>
> I stand corrected: the mount does hold a reference to the sunrpc
> module.
> However nothing holds a reference to the blocklayoutdriver module, so
> the main point that the "blocklayout" pipe can disappear from underneath
> the blkmapd stands.
Thanks for the explanation and I agree it can cause problem if user
reload blocklayout module. I will look into a fix to blkmapd.
Best,
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v4 0/10] bql: Byte Queue Limits
From: Rick Jones @ 2011-11-29 17:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dave Taht, Tom Herbert, davem, netdev
In-Reply-To: <1322550138.2970.70.camel@edumazet-laptop>
On 11/28/2011 11:02 PM, Eric Dumazet wrote:
> Le mardi 29 novembre 2011 à 05:23 +0100, Dave Taht a écrit :
>>> In this test 100 netperf TCP_STREAMs were started to saturate the link.
>>> A single instance of a netperf TCP_RR was run with high priority set.
>>> Queuing discipline in pfifo_fast, NIC is e1000 with TX ring size set to
>>> 1024. tps for the high priority RR is listed.
>>>
>>> No BQL, tso on: 3000-3200K bytes in queue: 36 tps
>>> BQL, tso on: 156-194K bytes in queue, 535 tps
>>
>>> No BQL, tso off: 453-454K bytes int queue, 234 tps
>>> BQL, tso off: 66K bytes in queue, 914 tps
>>
>>
>> Jeeze. Under what circumstances is tso a win? I've always
>> had great trouble with it, as some e1000 cards do it rather badly.
It is a win when one is sending bulk(ish) data and wish to avoid the
trips up and down the protocol stack to save CPU cycles.
TSO is sometimes called "poor man's Jumbo Frames" as it seeks to
achieve the same goal - fewer trips down the protocol stack per KB of
data transferred.
>> I assume these are while running at GigE speeds?
>>
>> What of 100Mbit? 10GigE? (I will duplicate your tests
>> at 100Mbit, but as for 10gigE...)
>>
>
> TSO on means a low priority 65Kbytes packet can be in TX ring right
> before the high priority packet. If you cant afford the delay, you lose.
>
> There is no mystery here.
>
> If you want low latencies :
> - TSO must be disabled so that packets are at most one ethernet frame.
> - You adjust BQL limit to small value
> - You even can lower MTU to get even more better latencies.
>
> If you want good throughput from your [10]GigE and low cpu cost, TSO
> should be enabled.
Outbound throughput. If you want good inbound throughput you want GRO/LRO.
> If you want to be smart, you could have a dynamic behavior :
>
> Let TSO on as long as no high priority low latency producer is running
> (if low latency packets are locally generated)
I'd probably leave that to the administrator rather than try to clutter
things with additional logic.
*If* I were to add additional logic, I might have an interface
communicate its "maximum TSO size" up the stack in a manner to too
dissimilar from MTU. That way one can control just how much time a
TSO'd segment would consume.
rick jones
^ permalink raw reply
* Re: [PATCH v4 02/10] net: Add queue state xoff flag for stack
From: David Miller @ 2011-11-29 17:27 UTC (permalink / raw)
To: jhs, hadi; +Cc: therbert, netdev
In-Reply-To: <1322572371.2090.1.camel@mojatatu>
From: jamal <hadi@cyberus.ca>
Date: Tue, 29 Nov 2011 08:12:51 -0500
> On Mon, 2011-11-28 at 18:32 -0800, Tom Herbert wrote:
>>
>> enum netdev_queue_state_t {
>> - __QUEUE_STATE_XOFF,
>> + __QUEUE_STATE_DRV_XOFF,
>> + __QUEUE_STATE_STACK_XOFF,
>> __QUEUE_STATE_FROZEN,
>
> QUEUE_STATE_DRV_XOFF seems to be a rename of __QUEUE_STATE_XOFF
> no issues there.
> Is inserting __QUEUE_STATE_STACK_XOFF going to cause any issues?
> Typically, you should insert new things at the end.
I doubt the ordering matters here, and any such dependency is a bug.
:-)
^ permalink raw reply
* Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: J. Bruce Fields @ 2011-11-29 17:27 UTC (permalink / raw)
To: Trond Myklebust
Cc: Peng Tao, tao.peng-mb1K0bWo544,
skinsbursky-bzQdu9zFT3WakBO8gow8eQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <1322587165.4174.20.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
On Tue, Nov 29, 2011 at 12:19:25PM -0500, Trond Myklebust wrote:
> On Tue, 2011-11-29 at 11:42 -0500, J. Bruce Fields wrote:
> > On Tue, Nov 29, 2011 at 11:40:30AM -0500, Trond Myklebust wrote:
> > > I mean that I'm perfectly entitled to do
> > >
> > > 'modprobe -r blocklayoutdriver'
> > >
> > > and when I do that, then I expect blkmapd to close the rpc pipe and wait
> > > for a new one to be created just like rpc.idmapd and rpc.gssd do when I
> > > remove the nfs and sunrpc modules.
> >
> > The rpc pipefs mount doesn't hold a reference on the sunrpc module?
>
> I stand corrected: the mount does hold a reference to the sunrpc
> module.
> However nothing holds a reference to the blocklayoutdriver module, so
> the main point that the "blocklayout" pipe can disappear from underneath
> the blkmapd stands.
OK, that makes sense.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode
From: Ben Hutchings @ 2011-11-29 17:19 UTC (permalink / raw)
To: Greg Rose
Cc: Roopa Prabhu, netdev@vger.kernel.org, davem@davemloft.net,
chrisw@redhat.com, sri@us.ibm.com, dragos.tatulea@gmail.com,
kvm@vger.kernel.org, arnd@arndb.de, mst@redhat.com,
mchan@broadcom.com, dwang2@cisco.com, shemminger@vyatta.com,
eric.dumazet@gmail.com, kaber@trash.net, benve@cisco.com
In-Reply-To: <1322584544.2684.20.camel@bwh-desktop>
On Tue, 2011-11-29 at 16:35 +0000, Ben Hutchings wrote:
> On Mon, 2011-11-21 at 09:41 -0800, Greg Rose wrote:
> > On 11/18/2011 9:40 AM, Ben Hutchings wrote:
> [...]
> > > What concerns me is that this seems to be a workaround rather than a fix
> > > for over-use of promiscuous mode, and it changes the semantics of
> > > filtering modes in ways that haven't been well-specified.
> >
> > I feel the opposite is true. It allows a known set of receive filters
> > so that you don't have to use promiscuous mode, which cuts down on
> > overhead from processing packets the upper layer stack isn't really
> > interested in.
> >
> > >
> > > What if there's a software bridge between two net devices corresponding
> > > to separate physical ports, so that they really need to be promiscuous?
> > > What if the administrator runs tcpdump and really wants the (PF) net
> > > device to be promiscuous?
> >
> > I don't believe there is anything in this patch set that removes
> > promiscuous mode operation as it is commonly used. Perhaps I've missed
> > something.
> [...]
>
> Maybe I missed something!
>
> Let's be clear on what our models are for filtering. At the moment we
> have MAC filters set through ndo_set_rx_mode and VF filters set through
> ndo_set_vf_{mac,vlan}.
>
> Ignoring anti-spoofing for the moment, should the currently defined
> filters look like this (a):
>
> TX ^ | RX
> | v
> +------------------+---+-----------------+
> | | ++------------+ |
> | | |RX MAC filter| |
> | | ++------------+ |
> | | |match |
> | ^ v |
> | | ++------------+ |
> | | |RX VF filters| |
> | | +-------+-----+ |
> | /|\ no /|\ |
> | | | \ match/ | |match 2 |
> | | ^ \ / v | |
> | | | \ /match| |
> | | \ \/ 1/ | |
> | | \ /\ / | |
> | ^ \/ \/ v |
> | | /\ /\ | |
> | | / || \ | |
> | | / || \ | |
> | | / || \ | |
> | || || || |
> +----------------++-----++-----++--------+
> || || ||
> PF VF 1 VF 2
>
> or like this (b):
>
> TX ^ | RX
> | v
> +------------------+---+-----------------+
> | | ++------------+ |
> | | |RX VF filters| |
> | | ++--------+---+ |
> | | no|match /| |
> | ^ v | | |
> | | +-+----+ | | |
> | | |RX MAC| | | |
> | | |filter| | | |
> | | +------+ | | |
> | | |match | | |
> | /|\ | | | |
> | | | \ | match| |match 2 |
> | | ^ \/ 1 v | |
> | | | /\ | | |
> | | \/ \ / | |
> | | /\ \ / | |
> | ^ / \ \/ v |
> | || \ /\ | |
> | || || \ | |
> | || || \ | |
> | || || \ | |
> | || || || |
> +----------------++-----++-----++--------+
> || || ||
> PF VF 1 VF 2
>
> I think the current model is (a); do you agree?
>
> So is the proposed new model something like this (c):
Corrected diagram:
TX ^ | RX
| v
+------------------+---+-----------------+
| | ++------------+ |
| | |RX MAC filter| |
| ^ ++------------+ |
| | |match |
| no match| v |
| +----------------+ ++------------+ |
| |loopback filters| |RX VF filters| |
| +---------+-----++ +-------+-----+ |
| /|\ /|\ match /|\ |
| v | `-+>+-+-.2 / | | |
| \ \ | |m \ \ / | | |
| match 0\ `-+-+.a \ \ / v | |
| \ | | \t \ X / | |
| \ | \ \c X \ / | |
| \| \ \h \ X | |
| \ \/\1 X \ v |
| || /\ |/ \ \ | |
| |v / || \ \| |
| || / ^| \ | |
| ||/ |v || |
| || || || |
+----------------++-----++-----++--------+
|| || ||
PF VF 1 VF 2
> (I've labelled the new filters as loopback filters here, and I'm still
> leaving out anti-spoofing.)
>
> If not, please explain what the new model *is*.
>
> Ben.
>
--
Ben Hutchings, Staff 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: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: Trond Myklebust @ 2011-11-29 17:19 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Peng Tao, tao.peng-mb1K0bWo544,
skinsbursky-bzQdu9zFT3WakBO8gow8eQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <20111129164252.GA19528-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On Tue, 2011-11-29 at 11:42 -0500, J. Bruce Fields wrote:
> On Tue, Nov 29, 2011 at 11:40:30AM -0500, Trond Myklebust wrote:
> > I mean that I'm perfectly entitled to do
> >
> > 'modprobe -r blocklayoutdriver'
> >
> > and when I do that, then I expect blkmapd to close the rpc pipe and wait
> > for a new one to be created just like rpc.idmapd and rpc.gssd do when I
> > remove the nfs and sunrpc modules.
>
> The rpc pipefs mount doesn't hold a reference on the sunrpc module?
I stand corrected: the mount does hold a reference to the sunrpc
module.
However nothing holds a reference to the blocklayoutdriver module, so
the main point that the "blocklayout" pipe can disappear from underneath
the blkmapd stands.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* ipv4: broadcast sometimes leaves wrong interface (since commit e066008b38ca9ace1b6de8dbbac8ed460640791d)
From: Jeroen van Ingen @ 2011-11-29 16:44 UTC (permalink / raw)
To: netdev
Hi,
We're having an issue on our Linux PPTP servers. After the first PPTP
client is connected, locally generated broadcast packets go out the ppp0
interface while the routing rules should select eth0.
Some details were already mentioned on the linux-kernel list, see eg
http://lkml.indiana.edu/hypermail/linux/kernel/1111.2/00290.html for
reference.
Finally we were able to narrow it down to one specific commit:
e066008b38ca9ace1b6de8dbbac8ed460640791d ("ipv4: Fix __ip_dev_find() to
use ifa_local instead of ifa_address."). With all recent kernels (tested
up to 3.2.0rc3) we observe this issue and it's solved by reverting this
single patch.
This is the first time we've had to debug a kernel issue. Any advice on
how to proceed would be very welcome. If it's not possible to have this
patch reverted in the kernel, hopefully someone can explain how to work
around this behavior.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
^ permalink raw reply
* RE: [PATCH v4 0/10] bql: Byte Queue Limits
From: David Laight @ 2011-11-29 17:06 UTC (permalink / raw)
To: Dave Taht, Eric Dumazet; +Cc: John Fastabend, Tom Herbert, davem, netdev
In-Reply-To: <CAA93jw7+KyX=7DC88hKisgaFtzn9vgLsBfUWOGhSHHPadw97Cg@mail.gmail.com>
...
> We spent all that engineering time making TCP go fast and minimized
the
> hardware impact of that - why not spend a little more time - in the
> next generation of hw/sw - making TCP work *better* on the network?
One problem I've seen is that a lot of the 'make TCP go fast'
changes have been focused on bulk transfer over long(ish) latency
links - typical for ftp and http downloads.
Interactive (command+response) works moderately, but async
data requests suffer badly.
Typically these connections will have Nagle disabled (because
you can't stand the repeated timeouts), and may be between
very local systems so the RTT is efectively zero and packet
loss unexpected.
Under these conditions the 'slow start' and 'delayed acks'
conspire against you.
What is more, if you have a high request rate there is little
that can be done to merge tx packets, even the sender is
willing to let some data be queued until (say) the next 1ms
clock tick.
I have seen 30000 packets/sec on a single tcp connection!
(The sender doesn't know there is another message to send.)
The sender was a dual, running 'while :; do :; done'
reduced the packet count considerably!
David
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: Eric Dumazet @ 2011-11-29 16:46 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1111281825200.25622@pokey.mtv.corp.google.com>
Le lundi 28 novembre 2011 à 18:32 -0800, Tom Herbert a écrit :
> Changes from last version:
> - Fixed obj leak in netdev_queue_add_kobject (suggested by shemminger)
> - Change dql to use unsigned int (32 bit) values (suggested by eric)
> - Added adj_limit field to dql structure. This computed as
> limit + num_completed. In dql_avail this is used to determine
> availability with one less arithmetic op.
> - Use UINT_MAX for limit constants.
> - Change netdev_sent_queue to not have a number of packets argument,
> one packet is assumed. (suggested by shemminger)
> - Added more detail about locking requirements for dql
> - Moves netdev->state field to written fields part of netdev structure
> - Fixed function prototypes in dql.h.
>
> ----
>
> This patch series implements byte queue limits (bql) for NIC TX queues.
>
> Byte queue limits are a mechanism to limit the size of the transmit
> hardware queue on a NIC by number of bytes. The goal of these byte
> limits is too reduce latency (HOL blocking) caused by excessive queuing
> in hardware (aka buffer bloat) without sacrificing throughput.
>
> Hardware queuing limits are typically specified in terms of a number
> hardware descriptors, each of which has a variable size. The variability
> of the size of individual queued items can have a very wide range. For
> instance with the e1000 NIC the size could range from 64 bytes to 4K
> (with TSO enabled). This variability makes it next to impossible to
> choose a single queue limit that prevents starvation and provides lowest
> possible latency.
>
> The objective of byte queue limits is to set the limit to be the
> minimum needed to prevent starvation between successive transmissions to
> the hardware. The latency between two transmissions can be variable in a
> system. It is dependent on interrupt frequency, NAPI polling latencies,
> scheduling of the queuing discipline, lock contention, etc. Therefore we
> propose that byte queue limits should be dynamic and change in
> accordance with networking stack latencies a system encounters. BQL
> should not need to take the underlying link speed as input, it should
> automatically adjust to whatever the speed is (even if that in itself is
> dynamic).
>
> Patches to implement this:
> - Dynamic queue limits (dql) library. This provides the general
> queuing algorithm.
> - netdev changes that use dlq to support byte queue limits.
> - Support in drivers for byte queue limits.
>
> The effects of BQL are demonstrated in the benchmark results below.
>
> --- High priority versus low priority traffic:
>
> In this test 100 netperf TCP_STREAMs were started to saturate the link.
> A single instance of a netperf TCP_RR was run with high priority set.
> Queuing discipline in pfifo_fast, NIC is e1000 with TX ring size set to
> 1024. tps for the high priority RR is listed.
>
> No BQL, tso on: 3000-3200K bytes in queue: 36 tps
> BQL, tso on: 156-194K bytes in queue, 535 tps
> No BQL, tso off: 453-454K bytes int queue, 234 tps
> BQL, tso off: 66K bytes in queue, 914 tps
>
> --- Various RR sizes
>
> These tests were done running 200 stream of netperf RR tests. The
> results demonstrate the reduction in queuing and also illustrates
> the overhead due to BQL (in small RR sizes).
>
> 140000 rr size
> BQL: 80-215K bytes in queue, 856 tps, 3.26%
> No BQL: 2700-2930K bytes in queue, 854 tps, 3.71% cpu
>
> 14000 rr size
> BQL: 25-55K bytes in queue, 8500 tps
> No BQL: 1500-1622K bytes in queue, 8523 tps, 4.53% cpu
>
> 1400 rr size
> BQL: 20-38K in queue bytes in queue, 86582 tps, 7.38% cpu
> No BQL: 29-117K 85738 tps, 7.67% cpu
>
> 140 rr size
> BQL: 1-10K bytes in queue, 320540 tps, 34.6% cpu
> No BQL: 1-13K bytes in queue, 323158, 37.16% cpu
>
> 1 rr size
> BQL: 0-3K in queue, 338811 tps, 41.41% cpu
> No BQL: 0-3K in queue, 339947 42.36% cpu
>
> So the amount of queuing in the NIC can be reduced up to 90% or more.
> Accordingly, the latency for high priority packets in the prescence
> of low priority bulk throughput traffic can be reduced by 90% or more.
>
> Since BQL accounting is in the transmit path for every packet, and the
> function to recompute the byte limit is run once per transmit
> completion-- there will be some overhead in using BQL. So far, Ive see
> the overhead to be in the range of 1-3% for CPU utilization and maximum
> pps.
I did sucessful tests with tg3 (I'll provide the patch for bnx2 shortly)
Some details probably can be polished, but I believe your v4 is ready
for inclusion.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks !
^ permalink raw reply
* Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: J. Bruce Fields @ 2011-11-29 16:42 UTC (permalink / raw)
To: Trond Myklebust
Cc: Peng Tao, tao.peng-mb1K0bWo544,
skinsbursky-bzQdu9zFT3WakBO8gow8eQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <1322584830.4174.16.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
On Tue, Nov 29, 2011 at 11:40:30AM -0500, Trond Myklebust wrote:
> I mean that I'm perfectly entitled to do
>
> 'modprobe -r blocklayoutdriver'
>
> and when I do that, then I expect blkmapd to close the rpc pipe and wait
> for a new one to be created just like rpc.idmapd and rpc.gssd do when I
> remove the nfs and sunrpc modules.
The rpc pipefs mount doesn't hold a reference on the sunrpc module?
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v4 0/10] bql: Byte Queue Limits
From: Ben Hutchings @ 2011-11-29 16:41 UTC (permalink / raw)
To: Dave Taht; +Cc: Eric Dumazet, Tom Herbert, davem, netdev
In-Reply-To: <CAA93jw5UG4=QRN3Wnh82wRg8YCSV7vDqGp0HyeVxsihUwLuioQ@mail.gmail.com>
On Tue, 2011-11-29 at 17:06 +0100, Dave Taht wrote:
> On Tue, Nov 29, 2011 at 3:29 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le mardi 29 novembre 2011 à 14:24 +0000, Ben Hutchings a écrit :
> >
> >> Not if you separate hardware queues by priority (and your high priority
> >> packets are non-TCP or PuSHed).
> >
> > I mostly have tg3 , bnx2 cards, mono queues...
> >
> > I presume Dave, working on small Wifi/ADSL routers have same kind of
> > hardware.
>
> Nothing but mono queues here on wired - 4 queues on wireless, however.
>
> and a focus on trying to make sure the
> 10Gig guys don't swamp the 128Kbit to 100Mbit guys, and everything in
> between that bandwidth range is what I care about, mostly against GigE
> servers...
I'm not objecting to that, just the assertion that TSO can be a problem
even on 10G hardware. In fact it makes a big improvement to CPU
efficiency (even if you do it in the driver, it can be better than GSO)
and almost all 10G hardware has multiple queues which can be used to
avoid the latency penalty.
> ( I'm still waiting on some 10Gig hw donations to arrive)
[...]
If you have a proposal to do interesting things with 10G hardware and
drivers then I can forward it for consideration here.
Ben.
--
Ben Hutchings, Staff 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: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: Trond Myklebust @ 2011-11-29 16:40 UTC (permalink / raw)
To: Peng Tao
Cc: tao.peng, skinsbursky, linux-nfs, xemul, neilb, netdev,
linux-kernel, jbottomley, bfields, davem, devel
In-Reply-To: <CA+a=Yy6kJe0NemSiRwM+t8gz5-UF5fOdwdS2so+q=nSYjBx--w@mail.gmail.com>
On Tue, 2011-11-29 at 23:30 +0800, Peng Tao wrote:
> On Tue, Nov 29, 2011 at 11:18 PM, Trond Myklebust
> <Trond.Myklebust@netapp.com> wrote:
> > On Tue, 2011-11-29 at 23:10 +0800, Peng Tao wrote:
> >> On Tue, Nov 29, 2011 at 9:35 PM, Myklebust, Trond
> >> <Trond.Myklebust@netapp.com> wrote:
> >> >> -----Original Message-----
> >> >> From: tao.peng@emc.com [mailto:tao.peng@emc.com]
> >> >> Sent: Tuesday, November 29, 2011 7:40 AM
> >> >> To: skinsbursky@parallels.com
> >> >> Cc: Myklebust, Trond; linux-nfs@vger.kernel.org; xemul@parallels.com;
> >> >> neilb@suse.de; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> >> jbottomley@parallels.com; bfields@fieldses.org; davem@davemloft.net;
> >> >> devel@openvz.org
> >> >> Subject: RE: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference
> >> >> from blocklayout routines
> >> >>
> >> >> > -----Original Message-----
> >> >> > From: Stanislav Kinsbursky [mailto:skinsbursky@parallels.com]
> >> >> > Sent: Tuesday, November 29, 2011 8:19 PM
> >> >> > To: Peng, Tao
> >> >> > Cc: Trond.Myklebust@netapp.com; linux-nfs@vger.kernel.org; Pavel
> >> >> > Emelianov; neilb@suse.de; netdev@vger.kernel.org;
> >> >> > linux-kernel@vger.kernel.org; James Bottomley; bfields@fieldses.org;
> >> >> > davem@davemloft.net; devel@openvz.org
> >> >> > Subject: Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference
> >> >> > from blocklayout routines
> >> >> >
> >> >> > 29.11.2011 16:00, tao.peng@emc.com пишет:
> >> >> > >> -----Original Message-----
> >> >> > >> From: linux-nfs-owner@vger.kernel.org
> >> >> > >> [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of
> >> >> > Stanislav
> >> >> > >> Kinsbursky
> >> >> > >> Sent: Tuesday, November 29, 2011 6:11 PM
> >> >> > >> To: Trond.Myklebust@netapp.com
> >> >> > >> Cc: linux-nfs@vger.kernel.org; xemul@parallels.com; neilb@suse.de;
> >> >> > >> netdev@vger.kernel.org; linux- kernel@vger.kernel.org;
> >> >> > >> jbottomley@parallels.com; bfields@fieldses.org;
> >> >> > >> davem@davemloft.net; devel@openvz.org
> >> >> > >> Subject: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference
> >> >> > >> from blocklayout routines
> >> >> > >>
> >> >> > >> This is a cleanup patch. We don't need this reference anymore,
> >> >> > >> because blocklayout pipes dentries now creates and destroys in
> >> >> > >> per-net operations and on PipeFS mount/umount notification.
> >> >> > >> Note that nfs4blocklayout_register_net() now returns 0 instead of
> >> >> > >> -ENOENT in case of PipeFS superblock absence. This is ok, because
> >> >> > >> blocklayout pipe dentry will be created on PipeFS mount event.
> >> >> > > When is the "pipefs mount event" going to happen? When inserting
> >> >> > > kernel modules or when user issues
> >> >> > mount command?
> >> >> > >
> >> >> >
> >> >> > When user issues mount command.
> >> >> > Kernel mounts of PipeFS has been removed with all these patch sets
> >> >> > I've sent already.
> >> >> Then it is going to break blocklayout user space program blkmapd, which is
> >> >> stared before mounting any file system and it tries to open the pipe file
> >> >> when started.
> >> >
> >> > Why on earth is blkmapd doing this instead of listening for file creation notifications like the other rpc_pipefs daemons do?
> >> Not sure how the original implementer chose this but I think it is
> >> likely because we do not expect the pipe file to be created or deleted
> >> dynamically.
> >
> > Unless blkmapd can pin the sunrpc module (which it shouldn't be able to)
> > then that assumption would be wrong. Please look into fixing blkmapd...
> Sorry, I don't quite get it. Do you mean sunrpc module may be removed
> while nfs/blocklayout modules are still in use? Please explain it a
> bit. Thanks.
I mean that I'm perfectly entitled to do
'modprobe -r blocklayoutdriver'
and when I do that, then I expect blkmapd to close the rpc pipe and wait
for a new one to be created just like rpc.idmapd and rpc.gssd do when I
remove the nfs and sunrpc modules.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode
From: Ben Hutchings @ 2011-11-29 16:35 UTC (permalink / raw)
To: Greg Rose
Cc: Roopa Prabhu, netdev@vger.kernel.org, davem@davemloft.net,
chrisw@redhat.com, sri@us.ibm.com, dragos.tatulea@gmail.com,
kvm@vger.kernel.org, arnd@arndb.de, mst@redhat.com,
mchan@broadcom.com, dwang2@cisco.com, shemminger@vyatta.com,
eric.dumazet@gmail.com, kaber@trash.net, benve@cisco.com
In-Reply-To: <4ECA8D50.9080603@intel.com>
On Mon, 2011-11-21 at 09:41 -0800, Greg Rose wrote:
> On 11/18/2011 9:40 AM, Ben Hutchings wrote:
[...]
> > What concerns me is that this seems to be a workaround rather than a fix
> > for over-use of promiscuous mode, and it changes the semantics of
> > filtering modes in ways that haven't been well-specified.
>
> I feel the opposite is true. It allows a known set of receive filters
> so that you don't have to use promiscuous mode, which cuts down on
> overhead from processing packets the upper layer stack isn't really
> interested in.
>
> >
> > What if there's a software bridge between two net devices corresponding
> > to separate physical ports, so that they really need to be promiscuous?
> > What if the administrator runs tcpdump and really wants the (PF) net
> > device to be promiscuous?
>
> I don't believe there is anything in this patch set that removes
> promiscuous mode operation as it is commonly used. Perhaps I've missed
> something.
[...]
Maybe I missed something!
Let's be clear on what our models are for filtering. At the moment we
have MAC filters set through ndo_set_rx_mode and VF filters set through
ndo_set_vf_{mac,vlan}.
Ignoring anti-spoofing for the moment, should the currently defined
filters look like this (a):
TX ^ | RX
| v
+------------------+---+-----------------+
| | ++------------+ |
| | |RX MAC filter| |
| | ++------------+ |
| | |match |
| ^ v |
| | ++------------+ |
| | |RX VF filters| |
| | +-------+-----+ |
| /|\ no /|\ |
| | | \ match/ | |match 2 |
| | ^ \ / v | |
| | | \ /match| |
| | \ \/ 1/ | |
| | \ /\ / | |
| ^ \/ \/ v |
| | /\ /\ | |
| | / || \ | |
| | / || \ | |
| | / || \ | |
| || || || |
+----------------++-----++-----++--------+
|| || ||
PF VF 1 VF 2
or like this (b):
TX ^ | RX
| v
+------------------+---+-----------------+
| | ++------------+ |
| | |RX VF filters| |
| | ++--------+---+ |
| | no|match /| |
| ^ v | | |
| | +-+----+ | | |
| | |RX MAC| | | |
| | |filter| | | |
| | +------+ | | |
| | |match | | |
| /|\ | | | |
| | | \ | match| |match 2 |
| | ^ \/ 1 v | |
| | | /\ | | |
| | \/ \ / | |
| | /\ \ / | |
| ^ / \ \/ v |
| || \ /\ | |
| || || \ | |
| || || \ | |
| || || \ | |
| || || || |
+----------------++-----++-----++--------+
|| || ||
PF VF 1 VF 2
I think the current model is (a); do you agree?
So is the proposed new model something like this (c):
TX ^ | RX
| v
+------------------+---+-----------------+
| | ++------------+ |
| | |RX MAC filter| |
| ^ ++------------+ |
| | |match |
| no match| v |
| +----------------+ ++------------+ |
| |loopback filters| |RX VF filters| |
| +---------+-----++ +-------+-----+ |
| /|\ /|\ match /|\ |
| v | `-+>+-+-.2 / | | |
| \ \ | |m \ \ / | | |
| match 0\ `-+-+.a \ \ / v | |
| \ | | \t \ X / | |
| \ | \ \c X X / | |
| \|\ \ \h \ X | |
| \ \ \/\1 X \ v |
| || /\ |/ \ \ | |
| |v / || \ \| |
| || / ^| \ | |
| ||/ |v \| |
| || || || |
+----------------++-----++-----++--------+
|| || ||
PF VF 1 VF 2
(I've labelled the new filters as loopback filters here, and I'm still
leaving out anti-spoofing.)
If not, please explain what the new model *is*.
Ben.
--
Ben Hutchings, Staff 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
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