* Re: [PATCH] slub: fix slab_pad_check()
From: Christoph Lameter @ 2009-09-09 14:04 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Eric Dumazet, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <20090908225937.GO6753@linux.vnet.ibm.com>
On Tue, 8 Sep 2009, Paul E. McKenney wrote:
> > No direct request but I have seen the network developers discover these
> > features and their caching benefits over the last year. It is likely that
> > they will try to push it into more components of the net subsystem.
>
> So if they push it far enough, they might well decide that they need
> a SLAB_DESTROY_BY_RCU_BH, for example. Looks like seven bits left,
> so unless I am missing something, should not be a huge problem should
> this need arise.
I'd rather have the call_rcu in the slabs replaced by a function that
can be set by the user. Then we can remove all rcu barriers from the code
and the slabs could be used with any type of rcu functionality.
^ permalink raw reply
* Re: [PATCH 1/1] netpoll: fix race between skb_queue_len and skb_dequeue
From: DDD @ 2009-09-09 14:27 UTC (permalink / raw)
To: Matt Mackall; +Cc: David Miller, netdev
In-Reply-To: <1252430825.7145.55.camel@calx>
On Tue, 2009-09-08 at 12:27 -0500, Matt Mackall wrote:
> On Tue, 2009-09-08 at 15:49 +0800, DDD wrote:
> > This race will break the messages order.
> >
> > Sequence of events in the problem case:
> >
> > Assume there is one skb "A" in skb_queue and the next action of
> > netpoll_send_skb() is: sending out "B" skb.
> > The right order of messages should be: send A first, then send B.
> >
> > But as following orders, it will send B first, then send A.
>
> I would say no, the order of messages A and B queued on different CPUs
> is undefined. The only issue is that we can queue a message A on CPU0,
> then causally trigger a message on CPU1 B that arrives first. But bear
> in mind that the message A >>may never arrive<< because the message is
> about a lockup that kills processing of delayed work.
>
> Generally speaking, queueing should be a last ditch effort. We should
> instead aim to deliver all messages immediately, even if they might be
> out of order. Because out of order is better than not arriving at all.
Ah, yes, out of order is better than not arriving at all. :-)
Especially it is based on UDP, so I don't think the order of messages is
important. :-)
I take back this patch.
Thank you very much,
Dongdong
^ permalink raw reply
* LOAN AAPLICATION !!!
From: SOLUTION TEAM @ 2009-09-09 14:18 UTC (permalink / raw)
Dear Sir/Madam
We Offer Private loan, Commercial and Personal Loans with very Minimal annual
Interest Rates as Low as 3% within a 1year to 50 years repayment duration
period to any part of the world.
We give out loans within the range of $10,000 to $1,000,000.00 USD.Our loans
are well insured for maximum security is our priority.Interested applicants
should Contact us with the information below via email: jmcloandept@ymail.com
Secretary Name: Mr.Lewis Hogan.
Secretary Email:solutionteam11@ymail.com
BORROWERS INFORMATION:
Names:
Country:
Address:
Age:
Phone Number:
Occupation:
Sex:
Amount Needed:
Loan duration:
Brief description of individual
Warmest Regards,
Secretary, Mr.Lewis Hogan.
Telephone:+4470457 10485
Fax Number:+447 005 963 154
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check()
From: Paul E. McKenney @ 2009-09-09 14:42 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers, dhowells, lethal, kernel,
mpm
In-Reply-To: <alpine.DEB.1.10.0909091002440.28070@V090114053VZO-1>
On Wed, Sep 09, 2009 at 10:04:20AM -0400, Christoph Lameter wrote:
> On Tue, 8 Sep 2009, Paul E. McKenney wrote:
>
> > > No direct request but I have seen the network developers discover these
> > > features and their caching benefits over the last year. It is likely that
> > > they will try to push it into more components of the net subsystem.
> >
> > So if they push it far enough, they might well decide that they need
> > a SLAB_DESTROY_BY_RCU_BH, for example. Looks like seven bits left,
> > so unless I am missing something, should not be a huge problem should
> > this need arise.
>
> I'd rather have the call_rcu in the slabs replaced by a function that
> can be set by the user. Then we can remove all rcu barriers from the code
> and the slabs could be used with any type of rcu functionality.
If the embedded guys are OK with an additional pointer in the slab data
structure, I have no objection to this approach. I am assuming that we
would use the usual ops-style structure full of pointers to functions
in order to avoid a pair of extra pointers.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check()
From: Christoph Lameter @ 2009-09-09 14:53 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Eric Dumazet, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers, dhowells, lethal, kernel,
mpm
In-Reply-To: <20090909144238.GA6749@linux.vnet.ibm.com>
On Wed, 9 Sep 2009, Paul E. McKenney wrote:
> If the embedded guys are OK with an additional pointer in the slab data
> structure, I have no objection to this approach. I am assuming that we
> would use the usual ops-style structure full of pointers to functions
> in order to avoid a pair of extra pointers.
This would also allow us to get rid of the ctor pointer in
kmem_cache_create(). We can put it into the same structure.
^ permalink raw reply
* Re: UDP regression with packets rates < 10k per sec
From: Eric Dumazet @ 2009-09-09 15:09 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev
In-Reply-To: <alpine.DEB.1.10.0909091000200.28070@V090114053VZO-1>
Christoph Lameter a écrit :
> On Wed, 9 Sep 2009, Eric Dumazet wrote:
>
>> In order to reproduce this here, could you tell me if you use
>>
>> Producer linux-2.6.22 -> Receiver 2.6.22
>> Producer linux-2.6.31 -> Receiver 2.6.31
>
> I use the above setup.
Then frames are sent on wire but not received
(they are received via mc loop, internal stack magic)
# ./mcast -L -n1 -r 10000
WARNING: Multiple active ethernet devices. Using local address 192.168.0.1
Receiver: Listening to control channel 239.0.192.1
Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 192.168.0.1
Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
100000 0 0 0 10000 3000.0 7.84 8.89 10.51 0.66
# uname -a
Linux erd 2.6.30.5 #2 SMP Mon Sep 7 17:15:43 CEST 2009 i686 i686 i386 GNU/Linux
I tried an old kernel on same hardware :
# ./mcast -L -n1 -r 10000
WARNING: Multiple active ethernet devices. Using local address 55.225.18.6
Receiver: Listening to control channel 239.0.192.1
Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 55.225.18.6
Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
99999 0 0 0 9998 0.0 9.00 9.95 14.50 1.56
Linux erd 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux
So my numbers seem much better than yours...
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check()
From: Paul E. McKenney @ 2009-09-09 15:09 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers, dhowells, lethal, kernel,
mpm
In-Reply-To: <alpine.DEB.1.10.0909091052380.28070@V090114053VZO-1>
On Wed, Sep 09, 2009 at 10:53:22AM -0400, Christoph Lameter wrote:
> On Wed, 9 Sep 2009, Paul E. McKenney wrote:
>
> > If the embedded guys are OK with an additional pointer in the slab data
> > structure, I have no objection to this approach. I am assuming that we
> > would use the usual ops-style structure full of pointers to functions
> > in order to avoid a pair of extra pointers.
>
> This would also allow us to get rid of the ctor pointer in
> kmem_cache_create(). We can put it into the same structure.
Sounds good -- that would result in no increase in size. Could even
add a dtor if people want it. ;-) (Sorry, couldn't resist...)
Thanx, Paul
^ permalink raw reply
* net_sched: fix estimator lock selection for mq child qdiscs
From: Patrick McHardy @ 2009-09-09 15:59 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 4335 bytes --]
commit d0a936694984bfd8bcd56cdddbbe1f077be7f277
Author: Patrick McHardy <kaber@trash.net>
Date: Wed Sep 9 17:50:10 2009 +0200
net_sched: fix estimator lock selection for mq child qdiscs
When new child qdiscs are attached to the mq qdisc, they are actually
attached as root qdiscs to the device queues. The lock selection for
new estimators incorrectly picks the root lock of the existing and
to be replaced qdisc, which results in a use-after-free once the old
qdisc has been destroyed.
Mark mq qdisc instances with a new flag and treat qdiscs attached to
mq as children similar to regular root qdiscs.
Additionally prevent estimators from being attached to the mq qdisc
itself since it only updates its byte and packet counters during dumps.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 9c69585..88eb9de 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -46,6 +46,7 @@ struct Qdisc
#define TCQ_F_THROTTLED 2
#define TCQ_F_INGRESS 4
#define TCQ_F_CAN_BYPASS 8
+#define TCQ_F_MQROOT 16
#define TCQ_F_WARN_NONWC (1 << 16)
int padded;
struct Qdisc_ops *ops;
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index de1ebc4..692d9a4 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -733,7 +733,8 @@ static struct lock_class_key qdisc_rx_lock;
static struct Qdisc *
qdisc_create(struct net_device *dev, struct netdev_queue *dev_queue,
- u32 parent, u32 handle, struct nlattr **tca, int *errp)
+ struct Qdisc *p, u32 parent, u32 handle,
+ struct nlattr **tca, int *errp)
{
int err;
struct nlattr *kind = tca[TCA_KIND];
@@ -810,24 +811,21 @@ qdisc_create(struct net_device *dev, struct netdev_queue *dev_queue,
if (tca[TCA_RATE]) {
spinlock_t *root_lock;
+ err = -EOPNOTSUPP;
+ if (sch->flags & TCQ_F_MQROOT)
+ goto err_out4;
+
if ((sch->parent != TC_H_ROOT) &&
- !(sch->flags & TCQ_F_INGRESS))
+ !(sch->flags & TCQ_F_INGRESS) &&
+ (!p || !(p->flags & TCQ_F_MQROOT)))
root_lock = qdisc_root_sleeping_lock(sch);
else
root_lock = qdisc_lock(sch);
err = gen_new_estimator(&sch->bstats, &sch->rate_est,
root_lock, tca[TCA_RATE]);
- if (err) {
- /*
- * Any broken qdiscs that would require
- * a ops->reset() here? The qdisc was never
- * in action so it shouldn't be necessary.
- */
- if (ops->destroy)
- ops->destroy(sch);
- goto err_out3;
- }
+ if (err)
+ goto err_out4;
}
qdisc_list_add(sch);
@@ -843,6 +841,15 @@ err_out2:
err_out:
*errp = err;
return NULL;
+
+err_out4:
+ /*
+ * Any broken qdiscs that would require a ops->reset() here?
+ * The qdisc was never in action so it shouldn't be necessary.
+ */
+ if (ops->destroy)
+ ops->destroy(sch);
+ goto err_out3;
}
static int qdisc_change(struct Qdisc *sch, struct nlattr **tca)
@@ -867,13 +874,16 @@ static int qdisc_change(struct Qdisc *sch, struct nlattr **tca)
qdisc_put_stab(sch->stab);
sch->stab = stab;
- if (tca[TCA_RATE])
+ if (tca[TCA_RATE]) {
/* NB: ignores errors from replace_estimator
because change can't be undone. */
+ if (sch->flags & TCQ_F_MQROOT)
+ goto out;
gen_replace_estimator(&sch->bstats, &sch->rate_est,
qdisc_root_sleeping_lock(sch),
tca[TCA_RATE]);
-
+ }
+out:
return 0;
}
@@ -1097,7 +1107,7 @@ create_n_graft:
if (!(n->nlmsg_flags&NLM_F_CREATE))
return -ENOENT;
if (clid == TC_H_INGRESS)
- q = qdisc_create(dev, &dev->rx_queue,
+ q = qdisc_create(dev, &dev->rx_queue, p,
tcm->tcm_parent, tcm->tcm_parent,
tca, &err);
else {
@@ -1106,7 +1116,7 @@ create_n_graft:
if (p && p->ops->cl_ops && p->ops->cl_ops->select_queue)
ntx = p->ops->cl_ops->select_queue(p, tcm);
- q = qdisc_create(dev, netdev_get_tx_queue(dev, ntx),
+ q = qdisc_create(dev, netdev_get_tx_queue(dev, ntx), p,
tcm->tcm_parent, tcm->tcm_handle,
tca, &err);
}
diff --git a/net/sched/sch_mq.c b/net/sched/sch_mq.c
index c84dec9..dd5ee02 100644
--- a/net/sched/sch_mq.c
+++ b/net/sched/sch_mq.c
@@ -64,6 +64,7 @@ static int mq_init(struct Qdisc *sch, struct nlattr *opt)
priv->qdiscs[ntx] = qdisc;
}
+ sch->flags |= TCQ_F_MQROOT;
return 0;
err:
^ permalink raw reply related
* Re: net_sched 07/07: add classful multiqueue dummy scheduler
From: Patrick McHardy @ 2009-09-09 16:01 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20090907192429.GC4451@ami.dom.local>
Jarek Poplawski wrote:
> On Mon, Sep 07, 2009 at 03:27:37PM +0200, Patrick McHardy wrote:
>> Jarek Poplawski wrote:
> ...
>>>> +static int mq_dump(struct Qdisc *sch, struct sk_buff *skb)
>>>> +{
>>>> + struct net_device *dev = qdisc_dev(sch);
>>>> + struct Qdisc *qdisc;
>>>> + unsigned int ntx;
>>>> +
>>>> + sch->q.qlen = 0;
>>>> + memset(&sch->bstats, 0, sizeof(sch->bstats));
>>>> + memset(&sch->qstats, 0, sizeof(sch->qstats));
>>>> +
>>>> + for (ntx = 0; ntx < dev->num_tx_queues; ntx++) {
>>>> + qdisc = netdev_get_tx_queue(dev, ntx)->qdisc_sleeping;
>>>> + spin_lock_bh(qdisc_lock(qdisc));
>>>> + sch->q.qlen += qdisc->q.qlen;
>>>> + sch->bstats.bytes += qdisc->bstats.bytes;
>>>> + sch->bstats.packets += qdisc->bstats.packets;
>>>> + sch->qstats.qlen += qdisc->qstats.qlen;
>>> Like in Christoph's case, we should probably use q.qlen instead.
>> Its done a few lines above. This simply sums up all members of qstats.
>
> AFAICS these members are updated only in tc_fill_qdisc, starting from
> the root, so they might be not up-to-date at the moment, unless I miss
> something.
Right. Its overwritten again in tc_fill_qdisc with the proper
value contained in sch->q.qlen however, so the final value
dumped to userspace is correct. So we can simply remove the
qstats.qlen handling in mq_dump().
^ permalink raw reply
* Re: net_sched 07/07: add classful multiqueue dummy scheduler
From: Patrick McHardy @ 2009-09-09 16:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jarek Poplawski, netdev
In-Reply-To: <4AA563B4.1060003@gmail.com>
Eric Dumazet wrote:
> Jarek Poplawski a écrit :
>> On Mon, Sep 07, 2009 at 03:27:37PM +0200, Patrick McHardy wrote:
>>> Jarek Poplawski wrote:
>> ...
>>>>> +static int mq_dump(struct Qdisc *sch, struct sk_buff *skb)
>>>>> +{
>>>>> + struct net_device *dev = qdisc_dev(sch);
>>>>> + struct Qdisc *qdisc;
>>>>> + unsigned int ntx;
>>>>> +
>>>>> + sch->q.qlen = 0;
>>>>> + memset(&sch->bstats, 0, sizeof(sch->bstats));
>>>>> + memset(&sch->qstats, 0, sizeof(sch->qstats));
>>>>> +
>>>>> + for (ntx = 0; ntx < dev->num_tx_queues; ntx++) {
>>>>> + qdisc = netdev_get_tx_queue(dev, ntx)->qdisc_sleeping;
>>>>> + spin_lock_bh(qdisc_lock(qdisc));
>>>>> + sch->q.qlen += qdisc->q.qlen;
>>>>> + sch->bstats.bytes += qdisc->bstats.bytes;
>>>>> + sch->bstats.packets += qdisc->bstats.packets;
>>>>> + sch->qstats.qlen += qdisc->qstats.qlen;
>>>> Like in Christoph's case, we should probably use q.qlen instead.
>>> Its done a few lines above. This simply sums up all members of qstats.
>> AFAICS these members are updated only in tc_fill_qdisc, starting from
>> the root, so they might be not up-to-date at the moment, unless I miss
>> something.
>
> Yes, we might need an q->ops->update_stats(struct Qdisc *sch) method, and
> to recursively call it from mq_update_stats()
Unless I'm missing something, that shouldn't be necessary since
sch->q.qlen contains the correct sum of all child qdiscs and
this is used by tc_fill_qdisc to update qstats.qlen.
^ permalink raw reply
* Re: [IB] 2.6.31-rc9: SW2HW_EQ failed on Dell R610
From: Roland Dreier @ 2009-09-09 16:36 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev
In-Reply-To: <alpine.DEB.1.10.0909091001450.28070@V090114053VZO-1>
> > The workaround of limiting possible cpus to 16 should be OK for the time
> > between 2.6.31 and 2.6.31.1.
> Why not merge it immediately? Dell R610s are fairly standard.
I think it's too late now post-rc9 ... it's not a regression (I think
the bug has been there since 2.6.29) and I think Linus would prefer to
minimize the # of patches that go in now.
- R.
^ permalink raw reply
* Re: UDP regression with packets rates < 10k per sec
From: Christoph Lameter @ 2009-09-09 16:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4AA7C512.6040100@gmail.com>
On Wed, 9 Sep 2009, Eric Dumazet wrote:
> Christoph Lameter a ?crit :
> > On Wed, 9 Sep 2009, Eric Dumazet wrote:
> >
> >> In order to reproduce this here, could you tell me if you use
> >>
> >> Producer linux-2.6.22 -> Receiver 2.6.22
> >> Producer linux-2.6.31 -> Receiver 2.6.31
> >
> > I use the above setup.
>
> Then frames are sent on wire but not received
>
> (they are received via mc loop, internal stack magic)
We are talking about two machines running 2.6.22 or 2.6.31. There is no
magic mc loop between the two machines. -L was not used.
> # ./mcast -L -n1 -r 10000
> WARNING: Multiple active ethernet devices. Using local address 192.168.0.1
> Receiver: Listening to control channel 239.0.192.1
> Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 192.168.0.1
> Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
>
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 100000 0 0 0 10000 3000.0 7.84 8.89 10.51 0.66
These are loopback latencies... Dont use -L
> # uname -a
> Linux erd 2.6.30.5 #2 SMP Mon Sep 7 17:15:43 CEST 2009 i686 i686 i386 GNU/Linux
>
>
>
> I tried an old kernel on same hardware :
>
> # ./mcast -L -n1 -r 10000
> WARNING: Multiple active ethernet devices. Using local address 55.225.18.6
> Receiver: Listening to control channel 239.0.192.1
> Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 55.225.18.6
> Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
>
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 99999 0 0 0 9998 0.0 9.00 9.95 14.50 1.56
>
> Linux erd 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux
>
> So my numbers seem much better than yours...
These are loopback numbers. Why is 2.6.9 so high? The regression show at
less than 10k.
Could you use real NICs? With multiple TX queues and all the other cool
stuff? And run at lower packet rates?
My loopback numbers also show the same trends.
2.6.22:
mcast -Ln1
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
101 0 0 0 10 3.0 5.47 5.74 7.00 0.43
mcast -Ln1 -r10000
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
100000 0 0 0 10000 3000.0 5.97 6.11 6.40 0.13
2.6.31-rc9
mcast -Ln1
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
100 0 0 0 10 3.0 13.26 13.45 13.56 0.09
mcast -Ln1 -r10000
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
100000 0 0 0 10000 3000.0 5.70 5.82 5.91 0.07
So 2.6.22 is better at 10 msgs per second. 2.6.31 is slightly better at
10k.
^ permalink raw reply
* Re: UDP regression with packets rates < 10k per sec
From: Eric Dumazet @ 2009-09-09 17:06 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev
In-Reply-To: <alpine.DEB.1.10.0909091234360.15538@V090114053VZO-1>
Christoph Lameter a écrit :
> On Wed, 9 Sep 2009, Eric Dumazet wrote:
>
>> Christoph Lameter a ?crit :
>>> On Wed, 9 Sep 2009, Eric Dumazet wrote:
>>>
>>>> In order to reproduce this here, could you tell me if you use
>>>>
>>>> Producer linux-2.6.22 -> Receiver 2.6.22
>>>> Producer linux-2.6.31 -> Receiver 2.6.31
>>> I use the above setup.
>> Then frames are sent on wire but not received
>>
>> (they are received via mc loop, internal stack magic)
>
> We are talking about two machines running 2.6.22 or 2.6.31. There is no
> magic mc loop between the two machines. -L was not used.
>
>> # ./mcast -L -n1 -r 10000
>> WARNING: Multiple active ethernet devices. Using local address 192.168.0.1
>> Receiver: Listening to control channel 239.0.192.1
>> Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 192.168.0.1
>> Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
>>
>> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
>> 100000 0 0 0 10000 3000.0 7.84 8.89 10.51 0.66
>
> These are loopback latencies... Dont use -L
>
>> # uname -a
>> Linux erd 2.6.30.5 #2 SMP Mon Sep 7 17:15:43 CEST 2009 i686 i686 i386 GNU/Linux
>>
>>
>>
>> I tried an old kernel on same hardware :
>>
>> # ./mcast -L -n1 -r 10000
>> WARNING: Multiple active ethernet devices. Using local address 55.225.18.6
>> Receiver: Listening to control channel 239.0.192.1
>> Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 55.225.18.6
>> Sender: Sending 10000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
>>
>> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
>> 99999 0 0 0 9998 0.0 9.00 9.95 14.50 1.56
>>
>> Linux erd 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux
>>
>> So my numbers seem much better than yours...
>
> These are loopback numbers. Why is 2.6.9 so high? The regression show at
> less than 10k.
>
> Could you use real NICs? With multiple TX queues and all the other cool
> stuff? And run at lower packet rates?
well, on your mono-flow test, multiqueue wont help anyway.
>
> My loopback numbers also show the same trends.
>
> 2.6.22:
>
> mcast -Ln1
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 101 0 0 0 10 3.0 5.47 5.74 7.00 0.43
>
> mcast -Ln1 -r10000
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 100000 0 0 0 10000 3000.0 5.97 6.11 6.40 0.13
>
>
> 2.6.31-rc9
>
> mcast -Ln1
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 100 0 0 0 10 3.0 13.26 13.45 13.56 0.09
>
> mcast -Ln1 -r10000
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 100000 0 0 0 10000 3000.0 5.70 5.82 5.91 0.07
>
>
> So 2.6.22 is better at 10 msgs per second. 2.6.31 is slightly better at
> 10k.
Unfortunatly there is too much noise on this test
# uname -a
Linux nag001 2.6.26-2-amd64 #1 SMP Fri Mar 27 04:02:59 UTC 2009 x86_64 GNU/Linux
# ./mcast -Ln1 -C
WARNING: Multiple active ethernet devices. Using local address 55.225.18.110
Receiver: Listening to control channel 239.0.192.1
Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 55.225.18.110
Sender: Sending 10 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
100 0 0 0 10 0.0 8.78 10.56 18.20 2.62
100 0 0 0 10 3.0 8.60 9.33 9.88 0.45
101 0 0 0 10 3.0 8.42 9.47 11.53 0.85
100 0 0 0 10 3.0 8.37 10.19 14.85 1.74
101 0 0 0 10 3.0 8.86 11.23 18.00 3.11
100 0 0 0 10 3.0 8.43 9.72 11.48 0.82
101 0 0 0 10 3.0 9.02 29.78 210.25 60.16
100 0 0 0 10 3.0 8.47 10.27 11.69 0.99
100 0 0 0 10 3.0 9.21 10.16 12.15 0.84
101 0 0 0 10 3.0 8.46 10.65 17.88 2.64
101 0 0 0 10 3.0 8.65 10.00 11.32 0.86
100 0 0 0 10 3.0 8.98 9.71 10.77 0.58
100 0 0 0 10 3.0 8.38 11.73 19.06 3.74
Also I believe you hit scheduler artefact at very low rate,
since there are two tasks that are considered as coupled.
Check commit 6f3d09291b4982991680b61763b2541e53e2a95f
sched, net: socket wakeups are sync
'sync' wakeups are a hint towards the scheduler that (certain)
networking related wakeups likely create coupling between tasks.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
diff --git a/net/core/sock.c b/net/core/sock.c
index 09cb3a7..2654c14 100644 (file)
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1621,7 +1621,7 @@ static void sock_def_readable(struct sock *sk, int len)
{
read_lock(&sk->sk_callback_lock);
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
- wake_up_interruptible(sk->sk_sleep);
+ wake_up_interruptible_sync(sk->sk_sleep);
sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN);
read_unlock(&sk->sk_callback_lock);
}
@@ -1635,7 +1635,7 @@ static void sock_def_write_space(struct sock *sk)
*/
if ((atomic_read(&sk->sk_wmem_alloc) << 1) <= sk->sk_sndbuf) {
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
- wake_up_interruptible(sk->sk_sleep);
+ wake_up_interruptible_sync(sk->sk_sleep);
/* Should agree with poll, otherwise some programs break */
if (sock_writeable(sk))
^ permalink raw reply related
* Re: UDP regression with packets rates < 10k per sec
From: Eric Dumazet @ 2009-09-09 17:08 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev
In-Reply-To: <alpine.DEB.1.10.0909091234360.15538@V090114053VZO-1>
Christoph Lameter a écrit :
> On Wed, 9 Sep 2009, Eric Dumazet wrote:
>
>> Christoph Lameter a ?crit :
>>> On Wed, 9 Sep 2009, Eric Dumazet wrote:
>>>
>>>> In order to reproduce this here, could you tell me if you use
>>>>
>>>> Producer linux-2.6.22 -> Receiver 2.6.22
>>>> Producer linux-2.6.31 -> Receiver 2.6.31
>>> I use the above setup.
>> Then frames are sent on wire but not received
>>
>> (they are received via mc loop, internal stack magic)
>
> We are talking about two machines running 2.6.22 or 2.6.31. There is no
> magic mc loop between the two machines. -L was not used.
>
I have no idea how you run the test then, and how are computed time deltas.
Are you clocks synchronized to less than one us ? How is it done ?
^ permalink raw reply
* Re: UDP regression with packets rates < 10k per sec
From: Christoph Lameter @ 2009-09-09 17:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4AA7E0FA.5070005@gmail.com>
On Wed, 9 Sep 2009, Eric Dumazet wrote:
> I have no idea how you run the test then, and how are computed time deltas.
>
> Are you clocks synchronized to less than one us ? How is it done ?
Packets are sent one way and include a timestamp. Once in a while (probe
interval) a packet is sent back to the sender (with the timestamp the
sender took earlier). The sender takes a second timestamp and
calculates the latency by dividing by two.
Seen this approach in multiple middleware test programs. Clocks are
typically not synchronized enough to actually compare timestamps from two
systems.
^ permalink raw reply
* Re: [PATCH] ath5k: do not free irq after resume when card has been removed
From: Thadeu Lima de Souza Cascardo @ 2009-09-09 17:50 UTC (permalink / raw)
To: Bob Copeland
Cc: ath5k-devel, linux-wireless, netdev, linux-kernel, lrodriguez,
mickflemm, jirislaby, linville, johannes
In-Reply-To: <20090909033237.GC13550@hash.localnet>
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
On Tue, Sep 08, 2009 at 11:32:37PM -0400, Bob Copeland wrote:
> On Tue, Sep 08, 2009 at 09:52:31PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > ath5k will try to request irq when resuming and fails if the device
> > (like a PCMCIA card) has been removed.
>
> That's not true, ath5k no longer requests an irq when resuming.
>
I've just saw there's a commit by you in the next tree that just removes
the irq requesting and releasing in resume/suspend functions.
> > This solves this issue defining a new flag for the status bitmap to
> > indicate when irq has been successfully requested and does not try to
> > release it if not.
>
> I'd rather not fix it with a status bit. What kernel is this against?
>
This is against v2.6.31-rc9, so I get a warning with a version that's
about to get stable. Sorry I am late in the release cycle.
I've used a status bit because the drivers I took a look at did
release/request irq in suspend/resume. I couldn't find a message about
not doing it was the right thing which I thought I saw in the latest
updates to v2.6.31-rcX. I guess it was something just like your commit
which I did see some weeks ago.
Since this is warning, is this worth backporting to rc?
> --
> Bob Copeland %% www.bobcopeland.com
>
Regards,
Cascardo.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: UDP regression with packets rates < 10k per sec
From: Christoph Lameter @ 2009-09-09 17:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4AA7E082.90807@gmail.com>
On Wed, 9 Sep 2009, Eric Dumazet wrote:
> > My loopback numbers also show the same trends.
> >
> > 2.6.22:
> >
> > mcast -Ln1
> > TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> > 101 0 0 0 10 3.0 5.47 5.74 7.00 0.43
> >
> > 2.6.31-rc9
> >
> > mcast -Ln1
> > TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> > 100 0 0 0 10 3.0 13.26 13.45 13.56 0.09
> >
> >
> > So 2.6.22 is better at 10 msgs per second. 2.6.31 is slightly better at
> > 10k.
>
> Linux nag001 2.6.26-2-amd64 #1 SMP Fri Mar 27 04:02:59 UTC 2009 x86_64 GNU/Linux
>
> TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
> 101 0 0 0 10 3.0 8.42 9.47 11.53 0.85
>
> Also I believe you hit scheduler artefact at very low rate,
> since there are two tasks that are considered as coupled.
>
> Check commit 6f3d09291b4982991680b61763b2541e53e2a95f
Reverting that patch yields:
clameter@rd-strategy3-deb64:~$ ./mcast -Ln1
TotalMsg Lost SeqErr TXDrop Msg/Sec KB/Sec Min/us Avg/us Max/us StdDv
101 0 0 0 10 3.0 27.21 31.28 52.68 8.16
Not good.
^ permalink raw reply
* Re: [PATCH] ath5k: do not free irq after resume when card has been removed
From: Bob Copeland @ 2009-09-09 19:31 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: jirislaby-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ, johannes-cdvu00un1VgdHxzADdlk8Q
In-Reply-To: <20090909175006.GA7945-StA3NKSgq9XYLCA8tIpKU1aTQe2KTcn/@public.gmane.org>
On Wed, Sep 09, 2009 at 02:50:06PM -0300, Thadeu Lima de Souza Cascardo wrote:
> This is against v2.6.31-rc9, so I get a warning with a version that's
> about to get stable. Sorry I am late in the release cycle.
Ok yes, that makes sense then.
> Since this is warning, is this worth backporting to rc?
It's too late probably, but we can send it to stable for 2.6.31.1.
Thank you for the patch by the way, just keep in mind that wireless
patches should be against the wireless-testing kernel in the future.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: net_sched 07/07: add classful multiqueue dummy scheduler
From: Jarek Poplawski @ 2009-09-09 19:52 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, netdev
In-Reply-To: <4AA7D1B3.7010708@trash.net>
On Wed, Sep 09, 2009 at 06:02:59PM +0200, Patrick McHardy wrote:
> Eric Dumazet wrote:
> > Jarek Poplawski a écrit :
> >> On Mon, Sep 07, 2009 at 03:27:37PM +0200, Patrick McHardy wrote:
> >>> Jarek Poplawski wrote:
> >> ...
> >>>>> +static int mq_dump(struct Qdisc *sch, struct sk_buff *skb)
> >>>>> +{
> >>>>> + struct net_device *dev = qdisc_dev(sch);
> >>>>> + struct Qdisc *qdisc;
> >>>>> + unsigned int ntx;
> >>>>> +
> >>>>> + sch->q.qlen = 0;
> >>>>> + memset(&sch->bstats, 0, sizeof(sch->bstats));
> >>>>> + memset(&sch->qstats, 0, sizeof(sch->qstats));
> >>>>> +
> >>>>> + for (ntx = 0; ntx < dev->num_tx_queues; ntx++) {
> >>>>> + qdisc = netdev_get_tx_queue(dev, ntx)->qdisc_sleeping;
> >>>>> + spin_lock_bh(qdisc_lock(qdisc));
> >>>>> + sch->q.qlen += qdisc->q.qlen;
> >>>>> + sch->bstats.bytes += qdisc->bstats.bytes;
> >>>>> + sch->bstats.packets += qdisc->bstats.packets;
> >>>>> + sch->qstats.qlen += qdisc->qstats.qlen;
> >>>> Like in Christoph's case, we should probably use q.qlen instead.
> >>> Its done a few lines above. This simply sums up all members of qstats.
> >> AFAICS these members are updated only in tc_fill_qdisc, starting from
> >> the root, so they might be not up-to-date at the moment, unless I miss
> >> something.
> >
> > Yes, we might need an q->ops->update_stats(struct Qdisc *sch) method, and
> > to recursively call it from mq_update_stats()
>
> Unless I'm missing something, that shouldn't be necessary since
> sch->q.qlen contains the correct sum of all child qdiscs and
> this is used by tc_fill_qdisc to update qstats.qlen.
You're perfectly right! (And the code is perfectly misleading.;-)
Thanks,
Jarek P.
^ permalink raw reply
* [PATCH NEXT 1/2] netxen: fix check for ip addr hashing support
From: Dhananjay Phadke @ 2009-09-09 20:09 UTC (permalink / raw)
To: davem; +Cc: netdev, Amit Kumar Salecha
Fix typo in checking dest ip has support before
programming destip addresses.
Signed-off-by: Amit Kumar Salecha <amit@netxen.com>
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 304618a..81c24a7 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -2340,7 +2340,7 @@ netxen_config_indev_addr(struct net_device *dev, unsigned long event)
struct in_device *indev;
struct netxen_adapter *adapter = netdev_priv(dev);
- if (netxen_destip_supported(adapter))
+ if (!netxen_destip_supported(adapter))
return;
indev = in_dev_get(dev);
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 2/2] netxen: fix tx descriptor structure
From: Dhananjay Phadke @ 2009-09-09 20:09 UTC (permalink / raw)
To: davem; +Cc: netdev, Amit Kumar Salecha
In-Reply-To: <1252526963-25621-1-git-send-email-dhananjay@netxen.com>
From: Amit Kumar Salecha <amit@qlogic.com>
Fix the offset of vlan_TCI field in cmd_desc_type0.
Signed-off-by: Amit Kumar Salecha <amit@qlogic.com>
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 2a52479..2371888 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -348,9 +348,9 @@ struct cmd_desc_type0 {
__le64 addr_buffer4;
- __le16 vlan_TCI;
- __le16 reserved;
__le32 reserved2;
+ __le16 reserved;
+ __le16 vlan_TCI;
} __attribute__ ((aligned(64)));
--
1.6.0.2
^ permalink raw reply related
* questions / potential bug: e1000e and tx delay setting in msi-x mode
From: Michal Soltys @ 2009-09-09 20:15 UTC (permalink / raw)
To: Linux Netdev List
While experimenting a bit with intel PRO/1000 CT nic (reported by lspci as Intel
Corporation 82574L Gigabit Network Connection), I noticed following issues (?):
1) under default IntMode (MSI-X), TxAbsIntDelay doesn't seem to limit interrupt
rate (as seen via /proc/interrupts), although it is capped by InterruptThrottleRate
(or not at all, if this one is disabled).
For example: with TxIntDelay 100 and TxAbsIntDelay 1000 - rate (as read from
/proc/interrupts) under simple udp netcat bombarding (1k packet size):
nc -u somehost someport </dev/zero
... will be around 115k int/sec - expected value w/o any interrupt moderation.
When IntMode is set to 0 or 1 (so either regular or MSI) - both TxIntDelay and
TxAbsIntDelay seem to work properly - in the above example, rate would stay below
1500 int/sec. But ...
2) ... at the same time, cpu load (as reported by mpstat -P ALL 1) is barely better
in the latter case. Furthermore, if I disable any delays, e.g. load e1000e module with:
options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=1
.. then netcat test will max cpu core, and it will be unable to reach full 1gbit, while:
options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
.. will easily handle 1gbit with ~50%+ idle core (in my case at least).
Should the difference between MSI and MSI-X modes be so large ?
Earlier tests (pt. #1):
options e1000e TxIntDelay=100 TxAbsIntDelay=1000 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=1
.. handles 1gbit with ~60%+ idle core.
and:
options e1000e TxIntDelay=100 TxAbsIntDelay=1000 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
.. are roughly identical as far as cpu load goes.
Those quick tests were done with nic interrupt(s) and netcat pinned at the same core.
Tested with current 2.6.31-rc9 and stable 2.6.30 tree.
^ permalink raw reply
* Re: [PATCH 0/5] Adds implementation of TFRC-SP on DCCP test tree
From: Gerrit Renker @ 2009-09-09 20:19 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <4AA6A252.5060405@embedded.ufcg.edu.br>
| These patches adds implementation of TFRC-SP at the receiver side, and
| are targeted at the DCCP branch
<snip>
|
| Following this patches, we'll be sending the sender side of TFRC-SP.
| Once this code is integrated on the branch, we can proceed adding the
| CCID4 code that uses this new TFRC-SP.
Thanks for all the work and for resending. I will be going through these
over the weekend. My suggestion is that if they compile and work cleanly,
to replace the existing patches in the CCID-4 subtree, so that testing
of the experimental CCID-4 features can continue.
Thanks a lot
Gerrit
^ permalink raw reply
* [PATCH] [NIU] VLAN does not work with niu driver
From: Joyce Yu @ 2009-09-09 21:10 UTC (permalink / raw)
To: netdev
From: Joyce Yu <joyce.yu@sun.com>
Date: Wed, 9 Sep 2009 08:43:00 -0700
Subject: [PATCH] VLAN does not work with niu driver
Signed-off-by: Joyce Yu <joyce.yu@sun.com>
---
drivers/net/niu.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/niu.h b/drivers/net/niu.h
index 3bd0b59..35678db 100644
--- a/drivers/net/niu.h
+++ b/drivers/net/niu.h
@@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {
#define RCR_PKT_TYPE_UDP 0x2
#define RCR_PKT_TYPE_SCTP 0x3
-#define NIU_RXPULL_MAX ETH_HLEN
+#define NIU_RXPULL_MAX 64
struct rx_pkt_hdr0 {
#if defined(__LITTLE_ENDIAN_BITFIELD)
--
1.6.4
--
^ permalink raw reply related
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: Stephen Hemminger @ 2009-09-09 21:35 UTC (permalink / raw)
To: Joyce.Yu; +Cc: netdev
In-Reply-To: <4AA819D8.1020306@Sun.COM>
On Wed, 09 Sep 2009 14:10:48 -0700
Joyce Yu <Joyce.Yu@sun.com> wrote:
> From: Joyce Yu <joyce.yu@sun.com>
> Date: Wed, 9 Sep 2009 08:43:00 -0700
> Subject: [PATCH] VLAN does not work with niu driver
> Signed-off-by: Joyce Yu <joyce.yu@sun.com>
>
> ---
> drivers/net/niu.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/niu.h b/drivers/net/niu.h
> index 3bd0b59..35678db 100644
> --- a/drivers/net/niu.h
> +++ b/drivers/net/niu.h
> @@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {
> #define RCR_PKT_TYPE_UDP 0x2
> #define RCR_PKT_TYPE_SCTP 0x3
>
> -#define NIU_RXPULL_MAX ETH_HLEN
> +#define NIU_RXPULL_MAX 64
>
> struct rx_pkt_hdr0 {
> #if defined(__LITTLE_ENDIAN_BITFIELD)
> --
> 1.6.4
>
Shouldn't the vlan driver being doing pskb_may_pull()
or pskb_pull() instead?
--
^ 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