[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1342022043.3265.8179.camel@edumazet-glaptop>
Date: Wed, 11 Jul 2012 17:54:03 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Ben Greear <greearb@...delatech.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, Rick Jones <rick.jones2@...com>
Subject: Re: [RFC PATCH v2] tcp: TCP Small Queues
On Wed, 2012-07-11 at 08:43 -0700, Ben Greear wrote:
> On 07/11/2012 08:25 AM, Eric Dumazet wrote:
> > On Wed, 2012-07-11 at 08:16 -0700, Ben Greear wrote:
> >
> >> I haven't read your patch in detail, but I was wondering if this feature
> >> would cause trouble for applications that are servicing many sockets at once
> >> and so might take several ms between handling each individual socket.
> >>
> >
> > Well, this patch has no impact for such applications. In fact their
> > send()/write() will return to userland faster than before (for very
> > large send())
>
> Maybe I'm just confused. Is your patch just mucking with
> the queues below the tcp xmit queues? From the patch description
> I was thinking you were somehow directly limiting the TCP xmit
> queues...
>
I dont limit tcp xmit queues. I might avoid excessive autotuning.
> If you are just draining the tcp xmit queues on a new/faster
> trigger, then I see no problem with that, and no need for
> a per-socket control.
Thats the plan : limiting numer of bytes in Qdisc, not number of bytes
in socket write queue.
--
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