[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1342051233.3265.8206.camel@edumazet-glaptop>
Date: Thu, 12 Jul 2012 02:00:33 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Nandita Dukkipati <nanditad@...gle.com>
Cc: David Miller <davem@...emloft.net>, ycheng@...gle.com,
dave.taht@...il.com, codel@...ts.bufferbloat.net,
netdev@...r.kernel.org, ncardwell@...gle.com,
mattmathis@...gle.com, andrewmcgr@...il.com, therbert@...gle.com
Subject: Re: [PATCH v3 net-next] tcp: TCP Small Queues
Note : netdev mailing list doesnt accept HTML ;)
On Wed, 2012-07-11 at 12:29 -0700, Nandita Dukkipati wrote:
> I have a couple of high level questions on the two solutions for
> maintain small queues at qdisc: 1) using codel's feedback versus 2)
> the approach in TSQ to explicitly limit bytes per-flow
> to tcp_limit_output_bytes.
>
>
> 1. multiple flows case: codel feedback (be it drop/ECN or direct
> feedback like in your patch with fq_codel: report congestion
> notification at enqueue time) seems to work in maintaining small
> queues regardless of the number of connections. TSQ probably won't
> achieve this goal when number of flows is large. Is this correct?
Problem with codel/fq_codel is that the congestion is delayed.
And my patch (signaling congestion to local tcp senders) raised several
issues.
I had then TSQ idea to have a more general mechanism (not depending on a
particular qdisc setup)
TCP Small Queue is effective even with a large number of flows because
with standard pfifo_fast, we can without TCP Small Queue store 1000
packets in Qdisc, each being 64KB. Thats 64 MBytes...
With TCP Small Queue, you can reach this level of occupancy using 500
flows (2 packets per flow)
Without TCP Small Queue, you can reach this level using 16 flows.
(This of course assumes TSO is on, but modern NIC are TSO enabled)
> 2. cwnd adjustment: codel feedback directly and explicitly controls
> snd_cwnd which in turn will also adjust the send buffer size to
> appropriate value. That's a nice property, which TSQ probably won't
> have because it doesn't explicitly adjust snd_cwnd.
>
> Considering these two points, why TSQ over the Codel feedback
> approach?
I dont think they compete. They are in fact complementary.
If you use codel/fq_codel + TSQ, you have both per flow limitation in
qdisc (TSQ) + sojourn time aware and multi flow aware feedback.
--
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