[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF1ivSZPqzjV_O7kXUskhy9BtKhbhdWixn8OS7sTpYgM8Z4afw@mail.gmail.com>
Date: Tue, 10 Jul 2012 21:28:21 +0800
From: Lin Ming <mlin@...pku.edu.cn>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: David Miller <davem@...emloft.net>, ycheng@...gle.com,
dave.taht@...il.com, netdev@...r.kernel.org,
codel@...ts.bufferbloat.net, therbert@...gle.com,
mattmathis@...gle.com, nanditad@...gle.com, ncardwell@...gle.com,
andrewmcgr@...il.com
Subject: Re: [RFC PATCH] tcp: limit data skbs in qdisc layer
On Mon, Jul 9, 2012 at 10:55 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Mon, 2012-07-09 at 00:08 -0700, David Miller wrote:
>
>> I'm suspicious and anticipate that 10G will need more queueing than
>> you are able to get away with tg3 at 1G speeds. But it is an exciting
>> idea nonetheless :-)
>
> There is a fundamental problem calling any xmit function from skb
> destructor.
>
> skb destructor can be called while qdisc lock is taken, so we can
> deadlock trying to reacquire it.
>
> One such path is the dev_deactivate_queue() -> qdisc_reset() ->
> qdisc_reset_queue(), but also any dropped skbs in qdisc.
>
> So I should only do this stuff from a separate context, for example a
> tasklet or timer.
>
> Alternative would be to use dev_kfree_skb_irq() for all dropped skbs in
> qdisc layer.
Hi Eric,
Maybe a bit off topic ...
Could you share how to test qdisc related change?
Assume I'm testing qdisc performance, for example, codel qdisc,
then how to setup the test environment?
Do you use some network simulator, for example, using the special netem qdisc to
simulate slow network/packet loss/network delay, etc?
Thanks,
Lin Ming
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists