netdev - Re: using software TSO on non-TSO capable netdevices

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <20080731014506.GA23402@xi.wantstofly.org>
Date:	Thu, 31 Jul 2008 03:45:06 +0200
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	David Miller <davem@...emloft.net>
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

On Wed, Jul 30, 2008 at 06:10:47PM -0700, David Miller wrote:

> > 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.

OK, how about:



From: Lennert Buytenhek <buytenh@...tstofly.org>
Subject: [NET] use software GSO for SG+CSUM capable netdevices

If a netdevice does not support hardware GSO, allowing the stack to
use GSO anyway and then splitting the GSO skb into MSS-sized pieces
as it is handed to the netdevice for transmitting is likely still
a win at least as far as CPU usage is concerned, since it reduces
the number of trips through the output path.

This patch enables the use of GSO on any netdevice that supports SG
and hardware checksumming.  If a GSO skb is then sent to a netdevice
that supports SG and checksumming but does not support hardware GSO,
net/core/dev.c:dev_hard_start_xmit() will take care of doing the
necessary GSO segmentation in software.

Signed-off-by: Lennert Buytenhek <buytenh@...vell.com>

Index: linux-2.6.27-rc1/include/net/sock.h
===================================================================
--- linux-2.6.27-rc1.orig/include/net/sock.h
+++ linux-2.6.27-rc1/include/net/sock.h
@@ -1085,7 +1085,13 @@ extern struct dst_entry *sk_dst_check(st
 
 static inline int sk_can_gso(const struct sock *sk)
 {
-	return net_gso_ok(sk->sk_route_caps, sk->sk_gso_type);
+	int caps = sk->sk_route_caps;
+	int type = sk->sk_gso_type;
+
+	return (caps & NETIF_F_SG) &&
+		 (((type == SKB_GSO_TCPV4 || type == SKB_GSO_UDP) &&
+			(caps & NETIF_F_V4_CSUM)) ||
+		  (type == SKB_GSO_TCPV6 && (caps & NETIF_F_V6_CSUM)));
 }
 
 extern void sk_setup_caps(struct sock *sk, struct dst_entry *dst);
--
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