* Re: [PATCH net-next-2.6] net: net/core/dev.c cleanups
From: David Miller @ 2009-09-03 12:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: jpirko, netdev
In-Reply-To: <4A9FB07D.5000509@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Sep 2009 14:03:09 +0200
> [PATCH net-next-2.6] net: Remove debugging code
>
> Remove a debugging aid I accidently left in previous 'cleanup' patch
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Sadly I went over the original patch with a fine-toothed comb
and I completely missed this :-(
Applied, thanks.
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Mel Gorman @ 2009-09-03 12:49 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bartlomiej Zolnierkiewicz, Tso Ted, Aneesh Kumar K.V, Zhu Yi,
Andrew Morton, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev@vger.kernel.org, linux-mm@kvack.org, James Ketrenos,
Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <43e72e890909021102g7f844c79xefccf305f5f5c5b6@mail.gmail.com>
On Wed, Sep 02, 2009 at 11:02:14AM -0700, Luis R. Rodriguez wrote:
> On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
> Zolnierkiewicz<bzolnier@gmail.com> wrote:
> > On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> >> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> >> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> >> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> >>
> >> s/2.6.30/2.6.31-rc6/
> >>
> >> The issue has always been there but it was some recent change that
> >> explicitly triggered the allocation failures (after 2.6.31-rc1).
> >
> > ipw2200 fix works fine but yesterday I got the following error while mounting
> > ext4 filesystem (mb_history is optional so the mount succeeded):
>
> OK so the mount succeeded.
>
> > EXT4-fs (dm-2): barriers enabled
> > kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> > EXT4-fs (dm-2): internal journal on dm-2:8
> > EXT4-fs (dm-2): delayed allocation enabled
> > EXT4-fs: file extents enabled
> > mount: page allocation failure. order:5, mode:0xc0d0
> > Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> > Call Trace:
> > [<c0394de3>] ? printk+0xf/0x14
> > [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> > [<c016a71b>] __get_free_pages+0xf/0x32
> > [<c01865cf>] __kmalloc+0x28/0xfa
> > [<c023d96f>] ? __spin_lock_init+0x28/0x4d
> > [<c01f529d>] ext4_mb_init+0x392/0x460
> > [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
> > [<c0239bc8>] ? snprintf+0x15/0x17
> > [<c01c0b26>] ? disk_name+0x24/0x69
> > [<c018ba63>] get_sb_bdev+0xda/0x117
> > [<c01e6711>] ext4_get_sb+0x13/0x15
> > [<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
> > [<c018ad2d>] vfs_kern_mount+0x3b/0x76
> > [<c018adad>] do_kern_mount+0x33/0xbd
> > [<c019d0af>] do_mount+0x660/0x6b8
> > [<c016a71b>] ? __get_free_pages+0xf/0x32
> > [<c019d168>] sys_mount+0x61/0x99
> > [<c0102908>] sysenter_do_call+0x12/0x36
> > Mem-Info:
> > DMA per-cpu:
> > CPU 0: hi: 0, btch: 1 usd: 0
> > Normal per-cpu:
> > CPU 0: hi: 186, btch: 31 usd: 0
> > Active_anon:25471 active_file:22802 inactive_anon:25812
> > inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
> > free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
> > DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> > lowmem_reserve[]: 0 489 489
> > Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> > lowmem_reserve[]: 0 0 0
> > DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
> > Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
> > 57947 total pagecache pages
> > 878 pages in swap cache
> > Swap cache stats: add 920, delete 42, find 11/11
> > Free swap = 1016436kB
> > Total swap = 1020116kB
> > 131056 pages RAM
> > 4233 pages reserved
> > 90573 pages shared
> > 77286 pages non-shared
> > EXT4-fs: mballoc enabled
> > EXT4-fs (dm-2): mounted filesystem with ordered data mode
> >
> > Thus it seems like the original bug is still there and any ideas how to
> > debug the problem further are appreciated..
> >
> > The complete dmesg and kernel config are here:
> >
> > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
> > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
>
> This looks very similar to the kmemleak ext4 reports upon a mount. If
> it is the same issue, which from the trace it seems it is, then this
> is due to an extra kmalloc() allocation and this apparently will not
> get fixed on 2.6.31 due to the closeness of the merge window and the
> non-criticalness this issue has been deemed.
>
I suspect the more pressing concern is why is this kmalloc() resulting in
an order-5 allocation request? What size is the buffer being requested?
Was that expected? What is the contents of /proc/slabinfo in case a buffer
that should have required order-1 or order-2 is using a higher order for
some reason.
> A patch fix is part of the ext4-patchqueue
> http://repo.or.cz/w/ext4-patch-queue.git
>
p.s. I'm will be offline until Tuesday so will not be initially very
responsive.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
From: Zdenek Kabelac @ 2009-09-03 13:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: Patrick McHardy, Christoph Lameter, Robin Holt,
Linux Kernel Mailing List, Pekka Enberg, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <4A9F1620.2080105@gmail.com>
2009/9/3 Eric Dumazet <eric.dumazet@gmail.com>:
> Zdenek Kabelac a écrit :
>>
>> Well I'm not noticing any ill behavior - also note - rcu_barrier() is
>> there before the cache is destroyed.
>> But as I said - it's just my shot into the dark - which seems to work for me...
>>
>
> Reading again your traces, I do believe there are two bugs in slub
>
> Maybe not explaining your problem, but worth to fix !
>
> Thank you
>
> [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
>
Ok - I can confirm that this patch fixes my reboot problem.
Thanks
Zdenek
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
From: Paul E. McKenney @ 2009-09-03 13:42 UTC (permalink / raw)
To: Pekka Enberg
Cc: Eric Dumazet, Zdenek Kabelac, Patrick McHardy, Christoph Lameter,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <84144f020909022331x2b275aa5n428f88670e0ae8bc@mail.gmail.com>
On Thu, Sep 03, 2009 at 09:31:01AM +0300, Pekka Enberg wrote:
> On Thu, Sep 3, 2009 at 4:04 AM, Eric Dumazet<eric.dumazet@gmail.com> wrote:
> > Zdenek Kabelac a écrit :
> >>
> >> Well I'm not noticing any ill behavior - also note - rcu_barrier() is
> >> there before the cache is destroyed.
> >> But as I said - it's just my shot into the dark - which seems to work for me...
> >>
> >
> > Reading again your traces, I do believe there are two bugs in slub
> >
> > Maybe not explaining your problem, but worth to fix !
> >
> > Thank you
> >
> > [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
> >
> > When SLAB_POISON is used and slab_pad_check() finds an overwrite of the
> > slab padding, we call restore_bytes() on the whole slab, not only
> > on the padding.
> >
> > kmem_cache_destroy() should call rcu_barrier() *after* kmem_cache_close()
> > and *before* sysfs_slab_remove() or risk rcu_free_slab()
> > being called after kmem_cache is deleted (kfreed).
> >
> > rmmod nf_conntrack can crash the machine because it has to
> > kmem_cache_destroy() a SLAB_DESTROY_BY_RCU enabled cache.
> >
> > Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> > diff --git a/mm/slub.c b/mm/slub.c
> > index b9f1491..0ac839f 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -646,7 +646,7 @@ static int slab_pad_check(struct kmem_cache *s, struct page *page)
> > slab_err(s, page, "Padding overwritten. 0x%p-0x%p", fault, end - 1);
> > print_section("Padding", end - remainder, remainder);
> >
> > - restore_bytes(s, "slab padding", POISON_INUSE, start, end);
> > + restore_bytes(s, "slab padding", POISON_INUSE, end - remainder, end);
>
> OK, makes sense.
>
> > return 0;
> > }
> >
> > @@ -2594,8 +2594,6 @@ static inline int kmem_cache_close(struct kmem_cache *s)
> > */
> > void kmem_cache_destroy(struct kmem_cache *s)
> > {
> > - if (s->flags & SLAB_DESTROY_BY_RCU)
> > - rcu_barrier();
> > down_write(&slub_lock);
> > s->refcount--;
> > if (!s->refcount) {
> > @@ -2606,6 +2604,8 @@ void kmem_cache_destroy(struct kmem_cache *s)
> > "still has objects.\n", s->name, __func__);
> > dump_stack();
> > }
> > + if (s->flags & SLAB_DESTROY_BY_RCU)
> > + rcu_barrier();
> > sysfs_slab_remove(s);
> > } else
> > up_write(&slub_lock);
>
> The rcu_barrier() call was added by this commit:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7ed9f7e5db58c6e8c2b4b738a75d5dcd8e17aad5
>
> I guess we should CC Paul as well.
I agree that moving the rcu_barrier() as you have done is the right
thing to do -- no point in doing the rcu_barrier() unless you actually
are destroying the kmem_cache!
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
--
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: [PATCH] atm/br2684: netif_stop_queue() when atm device busy and netif_wake_queue() when we can send packets again.
From: Chas Williams (CONTRACTOR) @ 2009-09-03 13:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, karl
In-Reply-To: <20090902.232707.93089975.davem@davemloft.net>
In message <20090902.232707.93089975.davem@davemloft.net>,David Miller writes:
>Applied to net-next-2.6, but Chas your email client corrupted
>the patch by breaking up long lines:
grr.... i will fix it (again). thanks.
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
From: Eric Dumazet @ 2009-09-03 13:46 UTC (permalink / raw)
To: Zdenek Kabelac
Cc: Patrick McHardy, Christoph Lameter, Robin Holt,
Linux Kernel Mailing List, Pekka Enberg, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <c4e36d110909030628j53cc0abfq6c1eef7e5e97565b@mail.gmail.com>
Zdenek Kabelac a écrit :
> 2009/9/3 Eric Dumazet <eric.dumazet@gmail.com>:
>> Zdenek Kabelac a écrit :
>>> Well I'm not noticing any ill behavior - also note - rcu_barrier() is
>>> there before the cache is destroyed.
>>> But as I said - it's just my shot into the dark - which seems to work for me...
>>>
>> Reading again your traces, I do believe there are two bugs in slub
>>
>> Maybe not explaining your problem, but worth to fix !
>>
>> Thank you
>>
>> [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
>>
>
>
> Ok - I can confirm that this patch fixes my reboot problem.
>
> Thanks
>
> Zdenek
Good news !
Hmm... but you had a problem with a 2.6.29.something kernel if I remember well ?
At that time, conntrack did not use SLAB_DESTROY_BY_RCU yet.
--
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: [PATCH net-next-2.6] ip: Report qdisc packet drops
From: Christoph Lameter @ 2009-09-03 17:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, sri, dlstevens, netdev, niv, mtk.manpages
In-Reply-To: <4A9EF113.9030102@gmail.com>
On Thu, 3 Sep 2009, Eric Dumazet wrote:
> index 29ebb0d..ebaaa7f 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -561,12 +561,18 @@ static int udp_push_pending_frames(struct sock *sk)
>
> send:
> err = ip_push_pending_frames(sk);
> + if (err) {
> + if (err == -ENOBUFS && !inet->recverr) {
> + UDP_INC_STATS_USER(sock_net(sk),
> + UDP_MIB_SNDBUFERRORS, is_udplite);
This means that we now do not increment SNDBUFERRORS if IP_RECVERR is set.
I think it would be better to move UDP_INC_STATS_USER before the if
statement. That will also simplify the code further.
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
From: Pekka Enberg @ 2009-09-03 14:05 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Zdenek Kabelac, Patrick McHardy, Robin Holt,
Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers, paulmck
In-Reply-To: <alpine.DEB.1.10.0909031246010.27903@V090114053VZO-1>
Hi Christoph,
On Thu, 3 Sep 2009, Pekka Enberg wrote:
>> Oh, sure, the fix looks sane to me. It's just that I am a complete
>> coward when it comes to merging RCU related patches so I always try to
>> fish an Acked-by from Paul or Christoph ;).
On Thu, Sep 3, 2009 at 8:50 PM, Christoph
Lameter<cl@linux-foundation.org> wrote:
> I am fine with acking the poison piece.
Ok.
On Thu, Sep 3, 2009 at 8:50 PM, Christoph
Lameter<cl@linux-foundation.org> wrote:
> I did not ack the patch that added rcu to kmem_cache_destroy() and I
> likely wont ack that piece either.
Right. I didn't remember that I merged that over your NAK but I don't
share your view that kmem_cache_destroy() callers should do
rcu_barrier() or whatever is necessary if we can do it from
kmem_cache_destroy(). So I am happy to take both changes but I would
appreciate them being split into two separate patches.
Pekka
^ permalink raw reply
* Re: [NET] Add proc file to display the state of all qdiscs.
From: Christoph Lameter @ 2009-09-03 18:03 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: eric.dumazet, netdev, David Miller, Patrick McHardy
In-Reply-To: <20090902212708.GC3018@ami.dom.local>
On Wed, 2 Sep 2009, Jarek Poplawski wrote:
> Btw, Patrick's comments reminded me this is probably not what you want
> in case of non-default qdiscs: the root qdisc like prio will be
> repeated for each tx queue with the same stats. I guess you need to do
> here an additional query e.g. by comparing dev_queue->qdisc_sleeping
> with that of i = 0.
Hmmm.. Maybe I better leave it to the experts then.
^ permalink raw reply
* [PATCH] slub: fix slab_pad_check()
From: Eric Dumazet @ 2009-09-03 14:08 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Zdenek Kabelac, Patrick McHardy, Robin Holt,
Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers, paulmck
In-Reply-To: <alpine.DEB.1.10.0909031244230.27903@V090114053VZO-1>
Christoph Lameter a écrit :
> On Thu, 3 Sep 2009, Eric Dumazet wrote:
>
>> on a SLAB_DESTROY_BY_RCU cache, there is no need to try to optimize this
>> rcu_barrier() call, unless we want superfast reboot/halt sequences...
>
> I stilll think that the action to quiesce rcu is something that the caller
> of kmem_cache_destroy must take care of.
Do you mean :
if (kmem_cache_shrink(s) == 0) {
rcu_barrier();
kmem_cache_destroy_no_rcu_barrier(s);
} else {
kmem_cache_destroy_with_rcu_barrier_because_SLAB_DESTROY_BY_RCU_cache(s);
}
What would be the point ?
>
> Could you split this into two patches: One that addresses the poison and
> another that deals with rcu?
>
Sure, here is the poison thing
[PATCH] slub: fix slab_pad_check()
When SLAB_POISON is used and slab_pad_check() finds an overwrite of the
slab padding, we call restore_bytes() on the whole slab, not only
on the padding.
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/mm/slub.c b/mm/slub.c
index b9f1491..0ac839f 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -646,7 +646,7 @@ static int slab_pad_check(struct kmem_cache *s, struct page *page)
slab_err(s, page, "Padding overwritten. 0x%p-0x%p", fault, end - 1);
print_section("Padding", end - remainder, remainder);
- restore_bytes(s, "slab padding", POISON_INUSE, start, end);
+ restore_bytes(s, "slab padding", POISON_INUSE, end - remainder, end);
return 0;
}
^ permalink raw reply related
* Re: [PATCH net-next-2.6] ip: Report qdisc packet drops
From: Eric Dumazet @ 2009-09-03 14:12 UTC (permalink / raw)
To: Christoph Lameter; +Cc: David Miller, sri, dlstevens, netdev, niv, mtk.manpages
In-Reply-To: <alpine.DEB.1.10.0909031255490.27903@V090114053VZO-1>
Christoph Lameter a écrit :
> On Thu, 3 Sep 2009, Eric Dumazet wrote:
>> index 29ebb0d..ebaaa7f 100644
>> --- a/net/ipv4/udp.c
>> +++ b/net/ipv4/udp.c
>> @@ -561,12 +561,18 @@ static int udp_push_pending_frames(struct sock *sk)
>>
>> send:
>> err = ip_push_pending_frames(sk);
>> + if (err) {
>> + if (err == -ENOBUFS && !inet->recverr) {
>> + UDP_INC_STATS_USER(sock_net(sk),
>> + UDP_MIB_SNDBUFERRORS, is_udplite);
>
> This means that we now do not increment SNDBUFERRORS if IP_RECVERR is set.
>
> I think it would be better to move UDP_INC_STATS_USER before the if
> statement. That will also simplify the code further.
>
>
I believe you already said this once Christoph on a previous patch, and I
replied that in case of IP_RECVERR set, udp_push_pending_frames()
returns -ENOBUFS to its caller : udp_sendmsg()
And the caller takes care of :
out:
ip_rt_put(rt);
if (free)
kfree(ipc.opt);
if (!err)
return len;
/*
* ENOBUFS = no kernel mem, SOCK_NOSPACE = no sndbuf space. Reporting
* ENOBUFS might not be good (it's not tunable per se), but otherwise
* we don't have a good statistic (IpOutDiscards but it can be too many
* things). We could add another new stat but at least for now that
* seems like overkill.
*/
if (err == -ENOBUFS || test_bit(SOCK_NOSPACE, &sk->sk_socket->flags)) {
UDP_INC_STATS_USER(sock_net(sk),
UDP_MIB_SNDBUFERRORS, is_udplite);
}
return err;
^ permalink raw reply
* [PATCH] slub: Fix kmem_cache_destroy() with SLAB_DESTROY_BY_RCU
From: Eric Dumazet @ 2009-09-03 14:18 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Zdenek Kabelac, Patrick McHardy, Robin Holt,
Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers, paulmck,
stable@kernel.org
In-Reply-To: <84144f020909030705x7909cf07w7ea0d3662a66c5cc@mail.gmail.com>
Pekka Enberg a écrit :
> Hi Christoph,
>
> On Thu, 3 Sep 2009, Pekka Enberg wrote:
>>> Oh, sure, the fix looks sane to me. It's just that I am a complete
>>> coward when it comes to merging RCU related patches so I always try to
>>> fish an Acked-by from Paul or Christoph ;).
>
> On Thu, Sep 3, 2009 at 8:50 PM, Christoph
> Lameter<cl@linux-foundation.org> wrote:
>> I am fine with acking the poison piece.
>
> Ok.
>
> On Thu, Sep 3, 2009 at 8:50 PM, Christoph
> Lameter<cl@linux-foundation.org> wrote:
>> I did not ack the patch that added rcu to kmem_cache_destroy() and I
>> likely wont ack that piece either.
>
> Right. I didn't remember that I merged that over your NAK but I don't
> share your view that kmem_cache_destroy() callers should do
> rcu_barrier() or whatever is necessary if we can do it from
> kmem_cache_destroy(). So I am happy to take both changes but I would
> appreciate them being split into two separate patches.
>
Here is the second patch (RCU thing). Stable candidate
[PATCH] slub: Fix kmem_cache_destroy() with SLAB_DESTROY_BY_RCU
kmem_cache_destroy() should call rcu_barrier() *after* kmem_cache_close()
and *before* sysfs_slab_remove() or risk rcu_free_slab()
being called after kmem_cache is deleted (kfreed).
rmmod nf_conntrack can crash the machine because it has to
kmem_cache_destroy() a SLAB_DESTROY_BY_RCU enabled cache.
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
diff --git a/mm/slub.c b/mm/slub.c
index b9f1491..b627675 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2594,8 +2594,6 @@ static inline int kmem_cache_close(struct kmem_cache *s)
*/
void kmem_cache_destroy(struct kmem_cache *s)
{
- if (s->flags & SLAB_DESTROY_BY_RCU)
- rcu_barrier();
down_write(&slub_lock);
s->refcount--;
if (!s->refcount) {
@@ -2606,6 +2604,8 @@ void kmem_cache_destroy(struct kmem_cache *s)
"still has objects.\n", s->name, __func__);
dump_stack();
}
+ if (s->flags & SLAB_DESTROY_BY_RCU)
+ rcu_barrier();
sysfs_slab_remove(s);
} else
up_write(&slub_lock);
^ permalink raw reply related
* Re: [NET] Add proc file to display the state of all qdiscs.
From: Jesper Dangaard Brouer @ 2009-09-03 14:19 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Jarek Poplawski, David Miller, Patrick McHardy,
netdev
In-Reply-To: <alpine.DEB.1.10.0909021313160.27987@V090114053VZO-1>
On Wed, 2 Sep 2009, Christoph Lameter wrote:
> On Wed, 2 Sep 2009, Eric Dumazet wrote:
>
>> Same name "eth0" is displayed, that might confuse parsers...
>>
>> What naming convention should we choose for multiqueue devices ?
>
> eth0/tx<number> ?
Remember that we already have a naming convention in /proc/interrupts
eth0-tx-<number>
Lets not introduce too many new once ;-)
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: [NET] Add proc file to display the state of all qdiscs.
From: Patrick McHardy @ 2009-09-03 14:29 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Christoph Lameter, Eric Dumazet, Jarek Poplawski, David Miller,
netdev
In-Reply-To: <Pine.LNX.4.64.0909031617060.28935@ask.diku.dk>
Jesper Dangaard Brouer wrote:
>
> On Wed, 2 Sep 2009, Christoph Lameter wrote:
>> On Wed, 2 Sep 2009, Eric Dumazet wrote:
>>
>>> Same name "eth0" is displayed, that might confuse parsers...
>>>
>>> What naming convention should we choose for multiqueue devices ?
>>
>> eth0/tx<number> ?
>
> Remember that we already have a naming convention in /proc/interrupts
>
> eth0-tx-<number>
>
> Lets not introduce too many new once ;-)
The approach I'm currently working on will present multiqueue root
qdiscs as children of a dummy classful qdisc. This avoids handle
clashes and the need for new identifiers and allows to address each
qdisc seperately, similar to how it works with other classful qdiscs:
qdisc mq 1: root refcnt 2
Sent 126 bytes 3 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
class mq 1:1 root leaf 8001:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq 1:2 root leaf 8002:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq 1:3 root leaf 8003:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq 1:4 root leaf 8004:
Sent 126 bytes 3 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Its a bit tricky though so I'm likely going to need a few more hours.
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
From: Zdenek Kabelac @ 2009-09-03 14:35 UTC (permalink / raw)
To: Eric Dumazet
Cc: Patrick McHardy, Christoph Lameter, Robin Holt,
Linux Kernel Mailing List, Pekka Enberg, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <4A9FC8B1.904@gmail.com>
2009/9/3 Eric Dumazet <eric.dumazet@gmail.com>:
> Zdenek Kabelac a écrit :
>> 2009/9/3 Eric Dumazet <eric.dumazet@gmail.com>:
>>> Zdenek Kabelac a écrit :
>>>> Well I'm not noticing any ill behavior - also note - rcu_barrier() is
>>>> there before the cache is destroyed.
>>>> But as I said - it's just my shot into the dark - which seems to work for me...
>>>>
>>> Reading again your traces, I do believe there are two bugs in slub
>>>
>>> Maybe not explaining your problem, but worth to fix !
>>>
>>> Thank you
>>>
>>> [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
>>>
>>
>>
>> Ok - I can confirm that this patch fixes my reboot problem.
>>
>> Thanks
>>
>> Zdenek
>
> Good news !
>
> Hmm... but you had a problem with a 2.6.29.something kernel if I remember well ?
>
> At that time, conntrack did not use SLAB_DESTROY_BY_RCU yet.
Yes - but it was also giving different error message - which even not
loaded ftp conntrack module. Basically it has been fine until
conntrack started to use rcu. From that moment various errors started
to appear with slub and some kernel debugging options - slab was fine.
With your recent patch it's the first time I do not see oops with nf
after 2.6.29 kernel.
Zdenek
--
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: [PATCH net-next-2.6] ip: Report qdisc packet drops
From: Christoph Lameter @ 2009-09-03 18:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, sri, dlstevens, netdev, niv, mtk.manpages
In-Reply-To: <4A9FCEC5.80409@gmail.com>
On Thu, 3 Sep 2009, Eric Dumazet wrote:
> >> --- a/net/ipv4/udp.c
> >> +++ b/net/ipv4/udp.c
> >> @@ -561,12 +561,18 @@ static int udp_push_pending_frames(struct sock *sk)
> >>
> >> send:
> >> err = ip_push_pending_frames(sk);
> >> + if (err) {
> >> + if (err == -ENOBUFS && !inet->recverr) {
> >> + UDP_INC_STATS_USER(sock_net(sk),
> >> + UDP_MIB_SNDBUFERRORS, is_udplite);
> >
> > This means that we now do not increment SNDBUFERRORS if IP_RECVERR is set.
> >
> > I think it would be better to move UDP_INC_STATS_USER before the if
> > statement. That will also simplify the code further.
> >
> >
>
> I believe you already said this once Christoph on a previous patch, and I
> replied that in case of IP_RECVERR set, udp_push_pending_frames()
> returns -ENOBUFS to its caller : udp_sendmsg()
Ahhh. I see. Would it not be better to have a single location where the
SNDBUFERRORS are accounted for? Check for -ENOBUFS before the code in
udp_sendmsg()? Hmmm.. The control flow is a bit complicated there...
^ permalink raw reply
* Re: [NET] Add proc file to display the state of all qdiscs.
From: Eric Dumazet @ 2009-09-03 14:43 UTC (permalink / raw)
To: Patrick McHardy
Cc: Jesper Dangaard Brouer, Christoph Lameter, Jarek Poplawski,
David Miller, netdev
In-Reply-To: <4A9FD2DC.7070807@trash.net>
Patrick McHardy a écrit :
> Jesper Dangaard Brouer wrote:
>> On Wed, 2 Sep 2009, Christoph Lameter wrote:
>>> On Wed, 2 Sep 2009, Eric Dumazet wrote:
>>>
>>>> Same name "eth0" is displayed, that might confuse parsers...
>>>>
>>>> What naming convention should we choose for multiqueue devices ?
>>> eth0/tx<number> ?
>> Remember that we already have a naming convention in /proc/interrupts
>>
>> eth0-tx-<number>
>>
>> Lets not introduce too many new once ;-)
>
> The approach I'm currently working on will present multiqueue root
> qdiscs as children of a dummy classful qdisc. This avoids handle
> clashes and the need for new identifiers and allows to address each
> qdisc seperately, similar to how it works with other classful qdiscs:
>
> qdisc mq 1: root refcnt 2
> Sent 126 bytes 3 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
>
> class mq 1:1 root leaf 8001:
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> class mq 1:2 root leaf 8002:
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> class mq 1:3 root leaf 8003:
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> class mq 1:4 root leaf 8004:
> Sent 126 bytes 3 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>
> Its a bit tricky though so I'm likely going to need a few more hours.
Seems pretty cool, thanks Patrick.
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check() and SLAB_DESTROY_BY_RCU
From: Paul E. McKenney @ 2009-09-03 15:00 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
In-Reply-To: <alpine.DEB.1.10.0909031244230.27903@V090114053VZO-1>
On Thu, Sep 03, 2009 at 12:45:43PM -0500, Christoph Lameter wrote:
> On Thu, 3 Sep 2009, Eric Dumazet wrote:
>
> > on a SLAB_DESTROY_BY_RCU cache, there is no need to try to optimize this
> > rcu_barrier() call, unless we want superfast reboot/halt sequences...
>
> I stilll think that the action to quiesce rcu is something that the caller
> of kmem_cache_destroy must take care of.
Why?
Thanx, Paul
> Could you split this into two patches: One that addresses the poison and
> another that deals with rcu?
>
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check()
From: Paul E. McKenney @ 2009-09-03 15:01 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
In-Reply-To: <alpine.DEB.1.10.0909031335430.29881@V090114053VZO-1>
On Thu, Sep 03, 2009 at 01:38:50PM -0500, Christoph Lameter wrote:
> On Thu, 3 Sep 2009, Eric Dumazet wrote:
>
> > Christoph Lameter a ?crit :
> > > On Thu, 3 Sep 2009, Eric Dumazet wrote:
> > >
> > >> on a SLAB_DESTROY_BY_RCU cache, there is no need to try to optimize this
> > >> rcu_barrier() call, unless we want superfast reboot/halt sequences...
> > >
> > > I stilll think that the action to quiesce rcu is something that the caller
> > > of kmem_cache_destroy must take care of.
> >
> > Do you mean :
> >
> > if (kmem_cache_shrink(s) == 0) {
> > rcu_barrier();
> > kmem_cache_destroy_no_rcu_barrier(s);
> > } else {
> > kmem_cache_destroy_with_rcu_barrier_because_SLAB_DESTROY_BY_RCU_cache(s);
> > }
> >
> > What would be the point ?
>
> The above is port of slub?
>
> I mean that (in this case) the net subsystem would have to deal with RCU quietness
> before disposing of the slab cache. There may be multiple ways of dealing
> with RCU. The RCU barrier may be unnecessary for future uses. Typically
> one would expect that all deferred handling of structures must be complete
> for correctness before disposing of the whole cache.
Which is precisely the point of the rcu_barrier(), right?
Thanx, Paul
> > [PATCH] slub: fix slab_pad_check()
>
> Acked-by: Christoph Lameter <cl@linux-foundation.org>
> --
> 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: [PATCH] slub: fix slab_pad_check()
From: Eric Dumazet @ 2009-09-03 15:02 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Zdenek Kabelac, Patrick McHardy, Robin Holt,
Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers, paulmck
In-Reply-To: <alpine.DEB.1.10.0909031335430.29881@V090114053VZO-1>
Christoph Lameter a écrit :
> On Thu, 3 Sep 2009, Eric Dumazet wrote:
>
>> Christoph Lameter a ?crit :
>>> On Thu, 3 Sep 2009, Eric Dumazet wrote:
>>>
>>>> on a SLAB_DESTROY_BY_RCU cache, there is no need to try to optimize this
>>>> rcu_barrier() call, unless we want superfast reboot/halt sequences...
>>> I stilll think that the action to quiesce rcu is something that the caller
>>> of kmem_cache_destroy must take care of.
>> Do you mean :
>>
>> if (kmem_cache_shrink(s) == 0) {
>> rcu_barrier();
>> kmem_cache_destroy_no_rcu_barrier(s);
>> } else {
>> kmem_cache_destroy_with_rcu_barrier_because_SLAB_DESTROY_BY_RCU_cache(s);
>> }
>>
>> What would be the point ?
>
> The above is port of slub?
No, I am trying to code what you suggest, and I could not find a clean way with
current API (SLAB/SLUB/SLOB)
>
> I mean that (in this case) the net subsystem would have to deal with RCU quietness
> before disposing of the slab cache. There may be multiple ways of dealing
> with RCU. The RCU barrier may be unnecessary for future uses. Typically
> one would expect that all deferred handling of structures must be complete
> for correctness before disposing of the whole cache.
Point is we cannot deal with RCU quietness before disposing the slab cache,
(if SLAB_DESTROY_BY_RCU was set on the cache) since this disposing *will*
make call_rcu() calls when a full slab is freed/purged.
And when RCU grace period is elapsed, the callback *will* need access to
the cache we want to dismantle. Better to not have kfreed()/poisoned it...
I believe you mix two RCU uses here.
1) The one we all know, is use normal caches (!SLAB_DESTROY_BY_RCU)
(or kmalloc()), and use call_rcu(... kfree_something)
In this case, you are 100% right that the subsystem itself has
to call rcu_barrier() (or respect whatever self-synchro) itself,
before calling kmem_cache_destroy()
2) The SLAB_DESTROY_BY_RCU one.
Part of cache dismantle needs to call rcu_barrier() itself.
Caller doesnt have to use rcu_barrier(). It would be a waste of time,
as kmem_cache_destroy() will refill rcu wait queues with its own stuff.
^ permalink raw reply
* RE: 2.6.31 ARP related problems
From: Duyck, Alexander H @ 2009-09-03 16:07 UTC (permalink / raw)
To: Or Gerlitz, Alexander Duyck
Cc: Eric W. Biederman, netdev@vger.kernel.org, Eric Dumazet,
Kirsher, Jeffrey T, David Miller
In-Reply-To: <4A9F7885.8080402@Voltaire.com>
Or Gerlitz wrote:
> Alexander Duyck wrote:
>> I don't suspect this has much of an effect on the Virtualization use
>> case for SR-IOV since the VFs are meant to be direct assigned as PCI
>> devices to the individual VMs
>
> I understand that eventually there will be scheme when VFs will be
> directly assigned to the VM, but there are/will be many occasions
> where a VF will serve as a virtual NIC in a Linux system e.g one
> serving as a host but also other purposes (think on macvlan as
> "software SR-IOV" where with your HW its the real thing).
>
>> You can probably also reproduce the issue by placing multiple
>> physical network interfaces on the same network segment if you saw
>> the same effect on SR-IOV since that is essentially the effect the
>> VFs create due to the switching logic built into the 82576
> Yes, as I managed to produce it with thee schemes: macvlan,
> veth+bridge and SR-IOV, I believe something is just broken wrt to ARP
> replies in
> 2.6.31 which is now in its rc8! I will try to look on that, and
> hopefully we can fix it at least for -stable.
>
> Or.
>
> I wasn't sure to understand your "the effect the VFs create due to the
> switching logic built into the 82576" comment, can you elaborate more
> on that?
The way the VFs work is that there is an L2 switch in the 82576 that is routing traffic between the PF, VFs, and the physical port. It behaves very much like if you had multiple NICs connected to an external L2 switch with a gigabit uplink. As such if you were to connect multiple physical ports to the same switch and configure them with addresses as you did with the VFs you should also see the same behavior.
Thanks,
Alex
^ permalink raw reply
* [PATCH] sky2: only enable Vaux if capable of wakeup
From: Stephen Hemminger @ 2009-09-03 16:16 UTC (permalink / raw)
To: Rene Mayrhofer, David Miller; +Cc: Mike McCormack, netdev, Richard Leitner
In-Reply-To: <200908311158.57972.rene.mayrhofer@gibraltar.at>
While perusing vendor driver, I saw that it did not enable the Vaux
power unless device was able to wake from lan for D3cold.
This might help for Rene's power issue.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sky2.c 2009-09-03 09:01:24.668473584 -0700
+++ b/drivers/net/sky2.c 2009-09-03 09:10:18.949088574 -0700
@@ -272,8 +272,9 @@ static void sky2_power_aux(struct sky2_h
Y2_CLK_GAT_LNK1_DIS | Y2_PCI_CLK_LNK2_DIS |
Y2_COR_CLK_LNK2_DIS | Y2_CLK_GAT_LNK2_DIS);
- /* switch power to VAUX */
- if (sky2_read32(hw, B0_CTST) & Y2_VAUX_AVAIL)
+ /* switch power to VAUX if supported and PME from D3cold */
+ if ( (sky2_read32(hw, B0_CTST) & Y2_VAUX_AVAIL) &&
+ pci_pme_capable(hw->pdev, PCI_D3cold))
sky2_write8(hw, B0_POWER_CTRL,
(PC_VAUX_ENA | PC_VCC_ENA |
PC_VAUX_ON | PC_VCC_OFF));
^ permalink raw reply
* [PATCH] ipv6: Fix tcp_v6_send_response(): it didn't set skb transport header
From: Cosmin Ratiu @ 2009-09-03 16:25 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
Hello,
Here is a patch which fixes an issue observed when using TCP over IPv6 and AH
from IPsec.
When a connection gets closed the 4-way method and the last ACK from the
server gets dropped, the subsequent FINs from the client do not get ACKed
because tcp_v6_send_response does not set the transport header pointer. This
causes ah6_output to try to allocate a lot of memory, which typically fails,
so the ACKs never make it out of the stack.
I have reproduced the problem on kernel 2.6.7, but after looking at the latest
kernel it seems the problem is still there.
Cosmin.
Signed-off-by: Cosmin Ratiu <cratiu@ixiacom.com>
---
net/ipv6/tcp_ipv6.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
[-- Attachment #2: 0001-ipv6-Fix-tcp_v6_send_response-it-didn-t-set-skb-trans.mbox --]
[-- Type: text/x-patch, Size: 466 bytes --]
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index d849dd5..776e911 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1003,6 +1003,7 @@ static void tcp_v6_send_response(struct sk_buff *skb, u32 seq, u32 ack, u32 win,
skb_reserve(buff, MAX_HEADER + sizeof(struct ipv6hdr) + tot_len);
t1 = (struct tcphdr *) skb_push(buff, tot_len);
+ skb_reset_transport_header(skb);
/* Swap the send and the receive. */
memset(t1, 0, sizeof(*t1));
^ permalink raw reply related
* Re: [RFC] net/fs_enet: send a reset request to the PHY on init
From: Grant Likely @ 2009-09-03 16:48 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: linuxppc-dev, netdev, Vitaly Bordug
In-Reply-To: <20090902110410.GC15401@www.tglx.de>
On Wed, Sep 2, 2009 at 5:04 AM, Sebastian Andrzej
Siewior<bigeasy@linutronix.de> wrote:
> Usually u-boot sends a phy request in its network init routine. An uboot
> without network support doesn't do it and I endup without working
> network. I still can switch between 10/100Mbit (according to the LED on
> the hub and phy registers) but I can't send or receive any data.
>
> At this point I'm not sure if the PowerON Reset takes the PHY a few
> nsecs too early out of reset or if this reset is required and everyone
> relies on U-boot performing this reset.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> This is done on a custom mpc512x board. Unfortunately I don't have other
> boards to check. The PHY is a AMD Am79C874, phylib uses the generic one.
>
> drivers/net/fs_enet/fs_enet-main.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
> index ee15402..a3c962b 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -823,7 +823,8 @@ static int fs_init_phy(struct net_device *dev)
> }
>
> fep->phydev = phydev;
> -
> + phy_write(phydev, MII_BMCR, BMCR_RESET);
> + udelay(1);
What version of the kernel are you using? The line numbers don't
match up with kernel mainline, so I wonder if this is before or after
the OF MDIO rework changes.
Regardless, this doesn't look right. It certainly isn't right for the
driver to do an unconditional PHY reset when it doesn't actually know
what phy is attached. For most boards I'm sure this is not desirable
because it will cause a delay while the PHY auto negotiates.
Depending on when the first network traffic begins, can cause several
seconds of boot delay.
Best would be to do this in U-Boot. Otherwise, I think I would rather
see it at phy_device probe time. At least then it would be on a
per-phy basis, or could be controlled by a property in the device tree
so that all boards don't get the same impact.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [NET] Add proc file to display the state of all qdiscs.
From: Jesper Dangaard Brouer @ 2009-09-03 17:30 UTC (permalink / raw)
To: Patrick McHardy
Cc: Christoph Lameter, Eric Dumazet, Jarek Poplawski, David Miller,
netdev
In-Reply-To: <4A9FD2DC.7070807@trash.net>
On Thu, 3 Sep 2009, Patrick McHardy wrote:
> Jesper Dangaard Brouer wrote:
>>
>> On Wed, 2 Sep 2009, Christoph Lameter wrote:
>>> On Wed, 2 Sep 2009, Eric Dumazet wrote:
>>>
>>>> Same name "eth0" is displayed, that might confuse parsers...
>>>>
>>>> What naming convention should we choose for multiqueue devices ?
>>>
>>> eth0/tx<number> ?
>>
>> Remember that we already have a naming convention in /proc/interrupts
>>
>> eth0-tx-<number>
>>
>> Lets not introduce too many new once ;-)
>
> The approach I'm currently working on will present multiqueue root
> qdiscs as children of a dummy classful qdisc. This avoids handle
> clashes and the need for new identifiers and allows to address each
> qdisc seperately, similar to how it works with other classful qdiscs:
I like your approach. Its well suited for the qdiscs :-)
I especially like the possibility to access each qdisc seperately. Does
it then support having seperate qdisc per TX queue? (I'm toying with the
idea of transmitting our multicast traffic into/via a seperate TX hardware
queue, and making a special qdisc for IPTV MPEG2-TS shaping)
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ 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