netdev - Re: [RFC PATCH net-next-2.6] gro: drivers should feed GRO only with TCP packets

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] [day] [month] [year] [list]

Message-Id: <20100901.131018.62350311.davem@davemloft.net>
Date:	Wed, 01 Sep 2010 13:10:18 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC PATCH net-next-2.6] gro: drivers should feed GRO only
 with TCP packets

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Wed, 01 Sep 2010 19:04:46 +0200

> Many network devices can tell if an incoming frame is a TCP one for a
> small cost.
> 
> Instead of feeding GRO with all packets, we could filter packets on this
> information ?
> 
> This should help machines handling a mixed UDP/TCP workload, keeping gro
> overhead as small as possible.
> 
> patch against tg3 as an example...
> 
> Alternative would be to set a bit "is_tcp" on napi_struct to let this
> choice being done in network stack, not by each driver. 
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>

I would rather have each and every driver unconditionally go through
the GRO receive routines, than do things like this.  Especially since
if we apply a patch like your's, the flood gates open and if IP
fragmentation support is added to GRO we have to undo all of this
stuff.

So what I actually want to see is that we remove the distinction of
GRO, and just have things like "net_receive_skb()".  It will have the
same call signature as napi_gro_receive().

Yes we'll still have things like the skge driver which currently need
to have a-priori knowledge of how to complete a NAPI sequence for the
sake of GRO, but we can at least rename the function it calls to
remove the GRO'ness of it.

Even non-NAPI drivers could use this, passing NULL for 'napi' and a GRO
usable NAPI context can be placed somewhere else and used purely for
the sake of GRO.  NULL would also mean "in hardware interrupt", and
we can make this check cost absolutely nothing by doing something inline
in net_receive_skb() like:

	if (__builtin_constant_p(napi) && napi == NULL)
		net_receive_skb_in_irq(skb, dev);

or similar.

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