[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080730.181047.39922732.davem@davemloft.net>
Date: Wed, 30 Jul 2008 18:10:47 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: buytenh@...tstofly.org
Cc: netdev@...r.kernel.org, akarkare@...vell.com, nico@....org,
herbert@...dor.apana.org.au
Subject: Re: using software TSO on non-TSO capable netdevices
From: Lennert Buytenhek <buytenh@...tstofly.org>
Date: Thu, 31 Jul 2008 02:41:23 +0200
> The hacky patch below (on top of 2.6.27-rc1 + stubbing out the
> sk_can_gso() check) reduces the 1 GiB 1000 Mb/s sendfile test from:
...
> I.e. dramatic CPU time improvements, and some overall speedup as well.
>
> I wonder if something like this can be done in a less hacky fashion --
> the hard part I guess is deciding when to keep coalescing (to reduce
> CPU overhead) vs. when to push out what has been coalesced so far (in
> order to keep the pipe filled), and I'm not sure I have good ideas
> about how to make that decision.
Interesting, I'll take a closer look at this.
Actually your patch is less of a surprise, because one of the issues I
had to surmount constantly when rewriting the TSO output path was the
implicit conflict between TSO deferral (to accumulate segments) and
the nagle logic.
Anyways, thanks, I'll think about this patch and your data and see
where we can go with that part.
In the mean time could you possibly cook up a cleaned up "use software
GSO for SG+CSUM capable devices" patch? I think I want to apply it,
especially since all of the things Herbert and I have suspected is
completely confirmed by your data and tests.
--
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