netdev - [0/8] net: Generic Receive Offload

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

Date:	Fri, 12 Dec 2008 16:31:16 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: [0/8] net: Generic Receive Offload

Hi:

This patch series introduces the Generic Receive Offload system.  Just
as GSO generalised TSO, GRO does the same thing for LRO.  Most of the
technical details are pulled straight out of LRO, although there is no
code shared between them.

For the moment, GRO is actually more stringent than LRO, meaning that
the set of packets that it merges is strictless less than LRO.  However,
I don't anticipate this to be a huge issue as testing shows that most
packets that are worth merging will still qualify under GRO.

The reason GRO strengthened the conditions for merging is to allow the
packets to be refragmented on output.  This is what stopped us from
allowing LRO to be used on routers and bridges.  This is also essential
for LRO to be deployed on a virtual host using bridging.

In future we may extend GRO to be less strict.  In order to do so it
would be necessary for the network to be able to handle super-packets
that are different from our existing GSO packets.  Such super-packets
would retain their individual headers which would be examined and/or
modified where necessary.

As it stands GRO should be a complete no-op unless the user enables
GRO using ethtool (and someone modifies the driver involved to call
napi_gro_receive).  Once we're comfortable with GRO we could enable
it automatically whenever RX checksum offload is available.

If this series is accepted, the next step would be to convert all
the relevant drivers to call napi_gro_receive (note that ironically
drivers using netif_rx won't need to be modified to use GRO, though
they won't actually merge anything unless they support RX checksum
offload).  I've converted e1000e as an example (also because that's
the only piece of hardware I've got access to right now :)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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