* Re: [PATCH] sch_qfq: fix overflow in qfq_update_start()
From: Stephen Hemminger @ 2012-01-03 16:25 UTC (permalink / raw)
To: Eric Dumazet, Luigi Rizzo; +Cc: David Miller, netdev, Dave Taht
In-Reply-To: <1325519277.2375.24.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, 02 Jan 2012 16:47:57 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> grp->slot_shift is between 22 and 41, so using 32bit wide variables is
> probably a typo.
>
> This could explain QFQ hangs Dave reported to me, after 2^23 packets ?
>
> (23 = 64 - 41)
>
> Reported-by: Dave Taht <dave.taht@gmail.com>
> CC: Stephen Hemminger <shemminger@vyatta.com>
> CC: Dave Taht <dave.taht@gmail.com>
> ---
> net/sched/sch_qfq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
> index 1033434..7b03254 100644
> --- a/net/sched/sch_qfq.c
> +++ b/net/sched/sch_qfq.c
> @@ -817,11 +817,11 @@ skip_unblock:
> static void qfq_update_start(struct qfq_sched *q, struct qfq_class *cl)
> {
> unsigned long mask;
> - uint32_t limit, roundedF;
> + u64 limit, roundedF;
> int slot_shift = cl->grp->slot_shift;
>
> roundedF = qfq_round_down(cl->F, slot_shift);
> - limit = qfq_round_down(q->V, slot_shift) + (1UL << slot_shift);
> + limit = qfq_round_down(q->V, slot_shift) + (1ULL << slot_shift);
>
> if (!qfq_gt(cl->F, q->V) || qfq_gt(roundedF, limit)) {
> /* timestamp was stale */
>
>
You need to copy the BSD developers on these patches since
most of the code came from them and FreeBSD probably still has same bug!
^ permalink raw reply
* [PATCH] x86: fix atomic64_xxx_cx8() functions
From: Eric Dumazet @ 2012-01-03 16:35 UTC (permalink / raw)
To: Jan Beulich; +Cc: mingo, tglx, Christoph Lameter, linux-kernel, netdev, hpa
In-Reply-To: <1325607218.2320.89.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
It appears about all functions in arch/x86/lib/atomic64_cx8_32.S are
wrong in case cmpxchg8b must be restarted, because LOCK_PREFIX macro
defines a label "1" clashing with other local labels :
1:
some_instructions
LOCK_PREFIX
cmpxchg8b (%ebp)
jne 1b / jumps to beginning of LOCK_PREFIX !
A possible fix is to use a magic label "672" in LOCK_PREFIX asm
definition, similar to the "671" one we defined in LOCK_PREFIX_HERE.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
CC: Christoph Lameter <cl@linux.com>
CC: Ingo Molnar <mingo@elte.hu>
CC: H. Peter Anvin <hpa@zytor.com>
Cc: stable@vger.kernel.org [2.6.35+]
---
arch/x86/include/asm/alternative-asm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/alternative-asm.h b/arch/x86/include/asm/alternative-asm.h
index 091508b..952bd01 100644
--- a/arch/x86/include/asm/alternative-asm.h
+++ b/arch/x86/include/asm/alternative-asm.h
@@ -4,10 +4,10 @@
#ifdef CONFIG_SMP
.macro LOCK_PREFIX
-1: lock
+672: lock
.section .smp_locks,"a"
.balign 4
- .long 1b - .
+ .long 672b - .
.previous
.endm
#else
^ permalink raw reply related
* Re: [PATCH] sch_qfq: fix overflow in qfq_update_start()
From: Luigi Rizzo @ 2012-01-03 16:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, David Miller, netdev, Dave Taht
In-Reply-To: <20120103082557.5c5cb962@nehalam.linuxnetplumber.net>
thanks, appreciated.
cheers
luigi
On Tue, Jan 03, 2012 at 08:25:57AM -0800, Stephen Hemminger wrote:
> On Mon, 02 Jan 2012 16:47:57 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > grp->slot_shift is between 22 and 41, so using 32bit wide variables is
> > probably a typo.
> >
> > This could explain QFQ hangs Dave reported to me, after 2^23 packets ?
> >
> > (23 = 64 - 41)
> >
> > Reported-by: Dave Taht <dave.taht@gmail.com>
> > CC: Stephen Hemminger <shemminger@vyatta.com>
> > CC: Dave Taht <dave.taht@gmail.com>
> > ---
> > net/sched/sch_qfq.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
> > index 1033434..7b03254 100644
> > --- a/net/sched/sch_qfq.c
> > +++ b/net/sched/sch_qfq.c
> > @@ -817,11 +817,11 @@ skip_unblock:
> > static void qfq_update_start(struct qfq_sched *q, struct qfq_class *cl)
> > {
> > unsigned long mask;
> > - uint32_t limit, roundedF;
> > + u64 limit, roundedF;
> > int slot_shift = cl->grp->slot_shift;
> >
> > roundedF = qfq_round_down(cl->F, slot_shift);
> > - limit = qfq_round_down(q->V, slot_shift) + (1UL << slot_shift);
> > + limit = qfq_round_down(q->V, slot_shift) + (1ULL << slot_shift);
> >
> > if (!qfq_gt(cl->F, q->V) || qfq_gt(roundedF, limit)) {
> > /* timestamp was stale */
> >
> >
>
>
> You need to copy the BSD developers on these patches since
> most of the code came from them and FreeBSD probably still has same bug!
^ permalink raw reply
* RE: [PATCH 06/19] netfilter: nf_conntrack: use atomic64 for accounting counters
From: Eric Dumazet @ 2012-01-03 17:05 UTC (permalink / raw)
To: David Laight; +Cc: pablo, netfilter-devel, davem, netdev
In-Reply-To: <1325597877.2320.47.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le mardi 03 janvier 2012 à 14:37 +0100, Eric Dumazet a écrit :
> Le mardi 03 janvier 2012 à 14:31 +0100, Eric Dumazet a écrit :
> > Le mardi 03 janvier 2012 à 12:01 +0000, David Laight a écrit :
> > > > if (acct) {
> > > > - spin_lock_bh(&ct->lock);
> > > > - acct[CTINFO2DIR(ctinfo)].packets++;
> > > > - acct[CTINFO2DIR(ctinfo)].bytes += skb->len;
> > > > - spin_unlock_bh(&ct->lock);
> > > > + atomic64_inc(&acct[CTINFO2DIR(ctinfo)].packets);
> > > > + atomic64_add(skb->len,
> > > &acct[CTINFO2DIR(ctinfo)].bytes);
> > > > }
> > >
> > > On a 32bit arch the two atomic64 operations require a locked
> > > bus cycle each. The spin_unlock_bh() may not need one - so
> > > the code may now be slower (modulo lock contention etc).
> > >
> > > Probably worth caching &acct[CTINFO2DIR(ctinfo)] in a local,
> > > the compiler probably can't do it itself.
> >
> > You're mistaken.
> >
> > Compile a UP kernel and check yourself before doing such claims.
> >
> >
>
> Oops sorry, I misread your mail, I thought you were speaking of UP
> kernel.
>
I got confused because your argument applies to 64bit platform as well
(two atomic ops instead of one in spin_lock_bh())
As a matter of fact, atomic64_[inc|add]() use two locked operations on
32bit.
Plus this code (atomic64_xxx_cx8()) seems very buggy since 2.6.35
kernels ... Oh well...
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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: [net-next 0/7][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-01-03 17:23 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1325555451-4697-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 2 Jan 2012 17:50:44 -0800
> The following series contains updates to igb, ixgbe and ixgbevf. Most of
> the changes are adding support of some kind. There are 3 fixes, one fix
> for ixgbevf to fix register defines. The other two fixes are for ixgbe,
> one being a minor comment spelling fix and the other is to fix register
> reads.
>
> Here is a list of the new support added:
> - 2 new device id's in ixgbe
> - igb flow control advertising to ethtool
>
> v2: Dropped the 2 patches to 'add thermal data sensor' to ixgbe while Don/PJ
> review and potentially fix-up the patches based on community feedback.
>
> The following are changes since commit 455ffa607f0efa90c9fec99604553b7cdd5274b2:
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: skge warning
From: Daniel Halperin @ 2012-01-03 17:27 UTC (permalink / raw)
To: Stephen Hemminger, netdev; +Cc: shemminger
In-Reply-To: <20120103081012.648953c7@nehalam.linuxnetplumber.net>
>> ---------- Forwarded message ----------
>> From: Daniel Halperin <dhalperi@cs.washington.edu>
>> Date: Mon, Jan 2, 2012 at 4:01 PM
>> Subject: skge warning
>> To: netdev@vger.kernel.org
>>
>>
>> I'm using Linus' current branch.
>>
>> drivers/net/ethernet/marvell/skge.c:4046: warning: ‘skge_suspend’
>> defined but not used
>> drivers/net/ethernet/marvell/skge.c:4071: warning: ‘skge_resume’
>> defined but not used
>>
>> It appears to be the use of the wrong CONFIG option. (The code
>> curently uses CONFIG_PM to see whether these functions are used).
>> Here's the relevant section of my .config:
>>
>> #
>> # Power management and ACPI options
>> #
>> # CONFIG_SUSPEND is not set
>> # CONFIG_HIBERNATION is not set
>> CONFIG_PM_RUNTIME=y
>> CONFIG_PM=y
>> CONFIG_PM_DEBUG=y
>> # CONFIG_PM_ADVANCED_DEBUG is not set
>>
>> Thanks,
>> Dan
>
> This usage pattern is common across all network drivers, therefore either
> all should change to use CONFIG_PM_SLEEP, or just ignore the extra code.
Thanks, Stephen!
Interestingly, I checked out how the other Ethernet drivers define
their suspend/resume functions via:
% grep SIMPLE_DEV_PM_OPS **/*c
atheros/atl1c/atl1c_main.c:static SIMPLE_DEV_PM_OPS(atl1c_pm_ops,
atl1c_suspend, atl1c_resume);
atheros/atlx/atl1.c:static SIMPLE_DEV_PM_OPS(atl1_pm_ops,
atl1_suspend, atl1_resume);
broadcom/tg3.c:static SIMPLE_DEV_PM_OPS(tg3_pm_ops, tg3_suspend, tg3_resume);
jme.c:static SIMPLE_DEV_PM_OPS(jme_pm_ops, jme_suspend, jme_resume);
marvell/skge.c:static SIMPLE_DEV_PM_OPS(skge_pm_ops, skge_suspend, skge_resume);
marvell/sky2.c:static SIMPLE_DEV_PM_OPS(sky2_pm_ops, sky2_suspend, sky2_resume);
nvidia/forcedeth.c:static SIMPLE_DEV_PM_OPS(nv_pm_ops, nv_suspend, nv_resume);
and all of them but skge.c use CONFIG_PM_SLEEP instead of CONFIG_PM.
It looks like you hit the nail on the head, but skge.c is the
exception here.
I can submit a patch if you like.
Thanks!
Dan
^ permalink raw reply
* Re: [PATCH] x86: fix and improve cmpxchg_double{,_local}()
From: Eric Dumazet @ 2012-01-03 17:31 UTC (permalink / raw)
To: Jan Beulich; +Cc: mingo, tglx, Christoph Lameter, linux-kernel, netdev, hpa
In-Reply-To: <4F032E5E020000780006A36C@nat28.tlf.novell.com>
Le mardi 03 janvier 2012 à 15:35 +0000, Jan Beulich a écrit :
> And in atomic64_set_cx8 it's the other way around: The comment
> explains why supposedly no LOCK prefix is needed, but that's again
> in conflict with above quoted paragraph from the manual.
BTW atomic64_set() asm() contraints are wrong :
static inline void atomic64_set(atomic64_t *v, long long i)
{
unsigned high = (unsigned)(i >> 32);
unsigned low = (unsigned)i;
asm volatile(ATOMIC64_ALTERNATIVE(set)
: "+b" (low), "+c" (high)
: "S" (v)
: "eax", "edx", "memory"
);
}
ebx/ecx registers are not modified by cmpxchg8b (or the atomic64_set_386
emulation). Only eax/edx can be modified.
^ permalink raw reply
* [PATCH] skge: fix warning when CONFIG_PM is defined but not CONFIG_PM_SLEEP
From: Daniel Halperin @ 2012-01-03 17:34 UTC (permalink / raw)
To: netdev; +Cc: shemminger
drivers/net/ethernet/marvell/skge.c:4046: warning: ‘skge_suspend’ defined but not used
drivers/net/ethernet/marvell/skge.c:4071: warning: ‘skge_resume’ defined but not used
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
---
drivers/net/ethernet/marvell/skge.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index dea0cb4..e6a007a 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -4042,7 +4042,7 @@ static void __devexit skge_remove(struct pci_dev *pdev)
pci_set_drvdata(pdev, NULL);
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int skge_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
@@ -4104,7 +4104,7 @@ static SIMPLE_DEV_PM_OPS(skge_pm_ops, skge_suspend, skge_resume);
#else
#define SKGE_PM_OPS NULL
-#endif
+#endif /* CONFIG_PM_SLEEP */
static void skge_shutdown(struct pci_dev *pdev)
{
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] netfilter: Fix br_nf_pre_routing() in conjunction with bridge-nf-call-ip(6)tables=0
From: Richard Weinberger @ 2012-01-03 17:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, bridge, netdev, linux-kernel, netfilter-devel
In-Reply-To: <20120103081521.2fec3a29@nehalam.linuxnetplumber.net>
[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]
Am 03.01.2012 17:15, schrieb Stephen Hemminger:
> On Tue, 3 Jan 2012 14:26:04 +0100
> Richard Weinberger <richard@nod.at> wrote:
>
>> If net.bridge.bridge-nf-call-iptables or net.bridge.bridge-nf-call-ip6tables
>> are set to zero xt_physdev has no effect because skb->nf_bridge has not been set up.
>>
>> Signed-off-by: Richard Weinberger <richard@nod.at>
>
> I am not sure if this is a valid configuration. The setting of sysctl is saying
> "don't do iptables on bridge (since I won't be using it)" and then you are later
> doing iptables and expecting the settings as if the iptables setup was being
> done.
I don't think so.
Also rules like this one are broken:
iptables -A INPUT -i bridge0 -m physdev --physdev-in eth0 -j ...
No firewalling is done on the bridge, xt_physdev is only using some meta
information.
At least a big fat warning would be nice that xt_physdev does not work
if bridge-nf-call-iptables=0.
It took me some time to figure out why my firewall rule set gone nuts on
RHEL6...
> Instead, you should just enable the net.bridge.bridge-nf-call-iptables sysctl.
> If a distro chooses to disable it then you may have to do it explicitly.
Fedora and RHEL have net.bridge.bridge-nf-call-iptables=0 per default
due to KVM network performance issues.
I'm sure I'm not the only user of xt_physdev on RHEL and friends.
Thanks,
//richard
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] bonding: fix error handling if slave is busy (v2)
From: David Miller @ 2012-01-03 17:49 UTC (permalink / raw)
To: nicolas.2p.debian; +Cc: shemminger, fubar, andy, netdev
In-Reply-To: <4EFFA44E.10507@gmail.com>
From: Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>
Date: Sun, 01 Jan 2012 01:09:50 +0100
> Le 01/01/2012 00:26, Stephen Hemminger a écrit :
>> If slave device already has a receive handler registered, then the
>> error unwind of bonding device enslave function is broken.
>>
>> The following will leave a pointer to freed memory in the slave
>> device list, causing a later kernel panic.
>> # modprobe dummy
>> # ip li add dummy0-1 link dummy0 type macvlan
>> # modprobe bonding
>> # echo +dummy0>/sys/class/net/bond0/bonding/slaves
>>
>> The fix is to detach the slave (which removes it from the list)
>> in the unwind path.
>>
>> Signed-off-by: Stephen Hemminger<shemminger@vyatta.com>
>
> Thanks Stephen.
>
> Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Applied, thanks.
^ permalink raw reply
* Re: BQL + Basic Latency under load results - 100Mbit, GSO/TSO off, pfifo_fast vs SFQ vs QFQ
From: David Miller @ 2012-01-03 17:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: dave.taht, jg, shemminger, jch, nichols, netdev
In-Reply-To: <1325478811.2526.10.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 02 Jan 2012 05:33:31 +0100
> [PATCH net-next] sch_sfq: dont put new flow at the end of flows
>
> SFQ enqueue algo puts a new flow _behind_ all pre-existing flows in the
> circular list. In fact this is probably an old SFQ implementation bug.
>
> 100 Mbits = ~8333 full frames per second, or ~8 frames per ms.
>
> With 50 flows, it means your "new flow" will have to wait 50 packets
> being sent before its own packet. Thats the ~6ms.
>
> We certainly can change SFQ to give a priority advantage to new flows,
> so that next dequeued packet is taken from a new flow, not an old one.
>
> Reported-by: Dave Taht <dave.taht@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] xfrm: Call IP receive handler directly for inbound tunnel-mode packets
From: David Miller @ 2012-01-03 17:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: herbert, david.ward, netdev
In-Reply-To: <1325492282.2526.32.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 02 Jan 2012 09:18:02 +0100
> if (skb->data - skb->head < DEPTH_THRESHOLD)
> netif_receive_skb(skb);
Fundamentally I think such things are doomed to failure.
I encourage you to instead look into the idea proposed the other year
(but unfortunately I found no time to implement) wherein we have a
top-level looping structure.
The scheme was originally proposed for TX but we can do it just as easily
for RX too. Essentially the entity that begins the traversal into the
packet send or receive path makes a mark in some per-cpu data structure.
When we return to the mark setting spot, we check if any "continued
processing" work got queued there, and run it if so, keeping the mark
set. Once the queued work is rechecked and found to be all clear, we
clear the mark and finish.
This has performance benefits too because on both the TX and RX side
we'll stop this whole dance where we schedule a SW interrupt and incr
all the overhead necessary to do that.
It's going to be faster than your threshold test scheme because we'll
be using a smaller stack frame and thus get better cache hits there.
^ permalink raw reply
* Re: tc filter mask for ACK packets off?
From: John A. Sullivan III @ 2012-01-03 17:57 UTC (permalink / raw)
To: Dave Taht; +Cc: Eric Dumazet, Michal Kubeček, netdev
In-Reply-To: <CAA93jw66gierUSN+gcZYY6L0UVqBdOhRKQwdA8NkhNqJL__uUA@mail.gmail.com>
On Tue, 2012-01-03 at 14:00 +0100, Dave Taht wrote:
<snip>
> SFQ as presently implemented (and by presently, I mean, as of yesterday,
> by tomorrow it could be different at the rate eric is going!) is VERY
> suitable for
> sub 100Mbit desktops, wireless stations/laptops other devices,
> home gateways with sub 100Mbit uplinks, and the like. That's a few
> hundred million devices that aren't using it today and defaulting to
> pfifo_fast and suffering for it.
>
> QFQ is it's big brother and I have hopes it can scale up to 10GigE,
> once suitable techniques are found for managing the sub-queue depth.
>
> The enhancements to SFQ eric proposed in the other thread might get it
> to where it outperforms (by a lot) pfifo_fast in it's default configuration
> (eg txqueuelen 1000) with few side effects. Scaling further up than that...
>
> ... I don't have a good picture of gigE performance at the moment with
> any of these advanced qdiscs and have no recomendation.
Hmm . . . that's interesting in light of our thoughts about using SFQ
for iSCSI. In that case, the links are GbE or 10GbE. Is there a problem
using SFQ on those size links rather than pfifo_fast?
>
<snip>
> >> - "Round-robin" -> It introduces larger delays than virtual clock
> >> based schemes, and should not be used for isolating interactive
> >> traffic from non-interactive. It means, that this scheduler
> >> should be used as leaf of CBQ or P3, which put interactive traffic
> >> to higher priority band.
>
> These delays are NOTHING compared to what pfifo_fast can induce.
>
> Very little traffic nowadays is marked as interactive to any statistically
> significant extent, so any FQ method effectively makes more traffic
> interactive than prioritization can.
That may be changing quickly. I am doing a lot of work with Destkop
Virtualization. This is all interactive traffic and, unlike terminal
screens over telnet or ssh in the past, these can be fairly large chunks
of data using full sized packets. They are also bursty rather than
periodic. I would think we very much need prioritization here combined
with FQ (hence our interest in HFSC + SFQ).
>
<snip>
> > Hmm . . . although I still wonder about iSCSI SANs . . . Thanks
>
> I wonder too. Most of the people running iSCSI seem to have an
> aversion to packet loss, yet are running over TCP. I *think*
> FQ methods will improve latency dramatically for iSCSI
> when iSCSI has multiple initiators....
<snip>
I haven't had a chance to play with this yet but I'll do a little
thinking out loud. Since these can be very large data transmissions, I
would think it quite possible that a new connection's SYN packet is
stuck behind a pile of full sized iSCSI packets. On the other hand, I'm
not sure where the bottleneck is in iSCSI and if these queues ever
backlog. I just ran a quick, simple test on a non-optimized SAN doing a
cat /dev/zero > filename, hit 3.6Gbps throughput with four e1000 NICs
doing multipath multibus and saw no backlog in the pfifo_fast qdiscs.
If we do ever backlog, I would think SFQ would provide for a more
immediate response to new streams whereas users of the bulk downloads
already in process would not even notice the blip when the new stream is
inserted.
I would be a little concerned about iSCSI packets being delivered out of
order when multipath multibus is used, i.e., the iSCSI commands are
round robined around several NICs and thus several queues. If those
queues are in varying states of backlog, a later packet in one queue
might be delivered before an earlier packet in another queue. Then
again, I would think pfifo_fast could produce a greater delay than SFQ -
John
^ permalink raw reply
* Re: [PATCH] sch_qfq: fix overflow in qfq_update_start()
From: David Miller @ 2012-01-03 17:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, shemminger, dave.taht
In-Reply-To: <1325519277.2375.24.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 02 Jan 2012 16:47:57 +0100
> grp->slot_shift is between 22 and 41, so using 32bit wide variables is
> probably a typo.
>
> This could explain QFQ hangs Dave reported to me, after 2^23 packets ?
>
> (23 = 64 - 41)
>
> Reported-by: Dave Taht <dave.taht@gmail.com>
> CC: Stephen Hemminger <shemminger@vyatta.com>
> CC: Dave Taht <dave.taht@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 1/2] mlx4_core: fix mtt range deallocation
From: David Miller @ 2012-01-03 18:01 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev, marcela
In-Reply-To: <4F01BA2B.1060605@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Mon, 2 Jan 2012 16:07:39 +0200
> From: Marcel Apfelbaum <marcela@mellanox.co.il>
>
> The mtt range was allocated in mtt units but deallocated
> in segments. Among the rest, this caused crash during hotplug removal
>
> Reported-by: Yinghai Lu <yinghai@kernel.org>
> Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
> Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] mlx4_core: Elaborating limitation on VF port options
From: David Miller @ 2012-01-03 18:01 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <4F01BA2F.8020305@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Mon, 2 Jan 2012 16:07:43 +0200
> From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
>
> Showing which capabilities are not passed to VF
> when executing QUERY_PORT
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sch_qfq: accurate wsum handling
From: David Miller @ 2012-01-03 18:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, shemminger
In-Reply-To: <1325540870.2874.6.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 02 Jan 2012 22:47:50 +0100
> We can underestimate q->wsum in case of "tc class replace ... qfq"
> and/or qdisc_create_dflt() error.
>
> wsum is not really used in fast path, only at qfq qdisc/class setup,
> to catch user error.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] net_sched: qdisc_alloc_handle() can be too slow
From: David Miller @ 2012-01-03 18:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, dave.taht
In-Reply-To: <1325584811.2320.11.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 03 Jan 2012 11:00:11 +0100
> When trying to allocate ~32768 qdiscs using autohandle mechanism, we can
> fill the space managed by kernel (handles in [8000-FFFF]:0000 range)
>
> But O(N^2) qdisc_alloc_handle() loops 0x10000 times instead of 0x8000
>
> time tc add qdisc add dev eth0 parent 10:7fff pfifo limit 10
> RTNETLINK answers: Cannot allocate memory
> real 1m54.826s
> user 0m0.000s
> sys 0m0.004s
>
> INFO: rcu_sched_state detected stall on CPU 0 (t=60000 jiffies)
>
> Half number of loops, and add a cond_resched() call.
> We hold rtnl at this point.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Dave Taht <dave.taht@gmail.com>
Applied, thanks Eric. I always cringed when I looked at this function :)
^ permalink raw reply
* [PATCH] CAN MAINTAINERS update
From: Oliver Hartkopp @ 2012-01-03 18:40 UTC (permalink / raw)
To: Linux Netdev List
Cc: linux-can@vger.kernel.org, Oliver Hartkopp, Urs Thuermann,
Wolfgang Grandegger, Marc Kleine-Budde
Update the CAN MAINTAINERS section:
- point out active maintainers
- pull the CAN driver discussion away from netdev ML
- point to the new CAN web site on gitorious.org
- add CAN development git repository URL to submit patches
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
CC: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
CC: Urs Thuermann <urs.thuermann@volkswagen.de>
CC: Wolfgang Grandegger <wg@grandegger.com>
CC: Marc Kleine-Budde <mkl@pengutronix.de>
CC: linux-can@vger.kernel.org
---
Hello Dave,
this is the updated MAINTAINERS section for the CAN subsystem.
As Marc Kleine-Budde will send upcoming git pull requests we discussed, if we
would need an additional section like this ...
NETWORKING [CAN]
M: Marc Kleine-Budde <mkl@pengutronix.de>
L: linux-can@vger.kernel.org
W: http://gitorious.org/linux-can
T: git://gitorious.org/linux-can/linux-can-next.git
S: Maintained
F: net/can/
F: drivers/net/can/
F: include/linux/can*
to make sure for you, who's sending the pull requests ...
Is this really needed or is it ok for you like it is below?
Regards,
Oliver
diff --git a/MAINTAINERS b/MAINTAINERS
index dbf3d94..59ce369 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1698,11 +1698,9 @@ F: arch/x86/include/asm/tce.h
CAN NETWORK LAYER
M: Oliver Hartkopp <socketcan@hartkopp.net>
-M: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
-M: Urs Thuermann <urs.thuermann@volkswagen.de>
L: linux-can@vger.kernel.org
-L: netdev@vger.kernel.org
-W: http://developer.berlios.de/projects/socketcan/
+W: http://gitorious.org/linux-can
+T: git://gitorious.org/linux-can/linux-can-next.git
S: Maintained
F: net/can/
F: include/linux/can.h
@@ -1713,9 +1711,10 @@ F: include/linux/can/gw.h
CAN NETWORK DRIVERS
M: Wolfgang Grandegger <wg@grandegger.com>
+M: Marc Kleine-Budde <mkl@pengutronix.de>
L: linux-can@vger.kernel.org
-L: netdev@vger.kernel.org
-W: http://developer.berlios.de/projects/socketcan/
+W: http://gitorious.org/linux-can
+T: git://gitorious.org/linux-can/linux-can-next.git
S: Maintained
F: drivers/net/can/
F: include/linux/can/dev.h
^ permalink raw reply related
* Re: [PATCH 1/2] net: phy: smsc: Move SMSC PHY constants to <linux/smscphy.h>
From: David Miller @ 2012-01-03 18:45 UTC (permalink / raw)
To: martinez.javier; +Cc: steve.glendinning, ben, eballetbo, netdev
In-Reply-To: <1325524131-14585-1-git-send-email-martinez.javier@gmail.com>
From: Javier Martinez Canillas <martinez.javier@gmail.com>
Date: Mon, 2 Jan 2012 18:08:50 +0100
> +/***************************************************************************
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + *
> + ***************************************************************************/
Come on, I normally don't get into how people do copyrights in files,
but this is a file with 13 trivial defines, and the whole kernel
source tree is explicitly GPL V2'd by the top-level COPYING file.
So this thing is over the top.
^ permalink raw reply
* Re: [PATCH 2/2] net/smsc911x: Check if PHY is in operational mode before software reset
From: David Miller @ 2012-01-03 18:46 UTC (permalink / raw)
To: martinez.javier; +Cc: steve.glendinning, ben, eballetbo, netdev
In-Reply-To: <1325524131-14585-2-git-send-email-martinez.javier@gmail.com>
From: Javier Martinez Canillas <martinez.javier@gmail.com>
Date: Mon, 2 Jan 2012 18:08:51 +0100
> + /* If energy is detected the PHY is already awake so is not necessary
> + * to disable the energy detect power-down mode. */
...
> + /* LAN9210/LAN9211/LAN9220/LAN9221 chips have an internal PHY that
> + * are initialized in a Energy Detect Power-Down mode that prevents
> + * the MAC chip to be software reseted. So we have to wakeup the PHY
> + * before */
Format these comments correctly:
/* Like this.
* See?
*/
/* Not like this.
* Ok? */
^ permalink raw reply
* Re: [PATCH] net: fsl: fec: fix build for mx23-only kernel
From: David Miller @ 2012-01-03 18:48 UTC (permalink / raw)
To: festevam
Cc: fabio.estevam, netdev, w.sang, u.kleine-koenig, shawn.guo,
linux-arm-kernel
In-Reply-To: <CAOMZO5BmKJP-3y_FxczuGwGfBR_3e2J9z3+gqzs-JDxOtR_PdQ@mail.gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Tue, 3 Jan 2012 13:37:47 -0200
> On Tue, Jan 3, 2012 at 11:46 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>> If one only selects mx23-based boards, compile fails:
>>
>> drivers/net/ethernet/freescale/fec.c:410:2: error: 'FEC_HASH_TABLE_HIGH' undeclared (first use in this function)
>> drivers/net/ethernet/freescale/fec.c:411:2: error: 'FEC_HASH_TABLE_LOW' undeclared (first use in this function)
>>
>> This is because fec.h uses CONFIG_SOC_IMX28 to determine the register
>> layout of the core which makes sense since the MX23 does not have a fec.
>> However, Kconfig uses the broader ARCH_MXS symbol and this way even
>> makes the fec-driver default for MX23. Adapt Kconfig to use the more
>> precise SOC_IMX28 as well.
>>
>> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
>> Cc: Fabio Estevam <fabio.estevam@freescale.com>
>> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> Cc: Shawn Guo <shawn.guo@linaro.org>
>> Cc: David S. Miller <davem@davemloft.net>
>
> Acked-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/davinci: do not use all descriptors for tx packets
From: David Miller @ 2012-01-03 18:51 UTC (permalink / raw)
To: s.hauer; +Cc: netdev, anantgole, srk
In-Reply-To: <1325604467-15122-1-git-send-email-s.hauer@pengutronix.de>
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Tue, 3 Jan 2012 16:27:47 +0100
> The driver uses a shared pool for both rx and tx descriptors.
> During open it queues fixed number of 128 descriptors for receive
> packets. For each received packet it tries to queue another
> descriptor. If this fails the descriptor is lost for rx.
> The driver has no limitation on tx descriptors to use, so it
> can happen during a nmap / ping -f attack that the driver
> allocates all descriptors for tx and looses all rx descriptors.
> The driver stops working then.
> To fix this limit the number of tx descriptors used to half of
> the descriptors available, the rx path uses the other half.
>
> Tested on a custom board using nmap / ping -f to the board from
> two different hosts.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Applied to net-next, thanks.
Well, at this point there is not logical reason to have a shared
descriptor pool unless the hardware requires it. Does it?
^ permalink raw reply
* Re: [PATCH] skge: fix warning when CONFIG_PM is defined but not CONFIG_PM_SLEEP
From: David Miller @ 2012-01-03 18:53 UTC (permalink / raw)
To: dhalperi; +Cc: netdev, shemminger
In-Reply-To: <A0790551-53D4-4D01-AB38-615607BCF9CC@cs.washington.edu>
From: Daniel Halperin <dhalperi@cs.washington.edu>
Date: Tue, 3 Jan 2012 09:34:48 -0800
> drivers/net/ethernet/marvell/skge.c:4046: warning: ‘skge_suspend’ defined but not used
> drivers/net/ethernet/marvell/skge.c:4071: warning: ‘skge_resume’ defined but not used
>
> Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
> Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] tcp: detect loss above high_seq in recovery
From: Yuchung Cheng @ 2012-01-03 18:54 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Miller, ncardwell, nanditad, Netdev
In-Reply-To: <alpine.DEB.2.00.1112301256060.15137@wel-95.cs.helsinki.fi>
On Fri, Dec 30, 2011 at 3:19 AM, Ilpo Järvinen
<ilpo.jarvinen@helsinki.fi> wrote:
> On Thu, 29 Dec 2011, Yuchung Cheng wrote:
>
>> To summarize:
>> 1) this change does NOT forbid TCP performing further CWR on new losses
>> 2) this change (merely) marks some forward-retransmitted packets LOST.
>> 3) the commit message is to be explicit that CWR may not always be performed,
>> in both my change and current kernel.
>
> I agree with these points. I wonder if you intend to look to fixing the
> lacking CWR problem or should I look to that once I get some spare time?
>
>> HTH. I will update commit message if people can make sense of it :)
>
> Please do.
Great, I'll update the commit message first, and work on another
feature patch that does CWR if
a) new sequence is lost
b) a retransmission is lost
^ 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