lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 30 Jul 2008 18:10:47 -0700 (PDT)
From:	David Miller <>
Subject: Re: using software TSO on non-TSO capable netdevices

From: Lennert Buytenhek <>
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
More majordomo info at

Powered by blists - more mailing lists