aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux
diff options
context:
space:
mode:
authorJerry Chu <hkchu@google.com>2014-01-07 13:23:19 -0500
committerDavid S. Miller <davem@davemloft.net>2014-01-07 16:21:31 -0500
commitbf5a755f5e9186406bbf50f4087100af5bd68e40 (patch)
treec971c1aafbcb999a65b5f088bf2627c48006072a /include/linux
parentcdb3f4a31b64c3a1c6eef40bc01ebc9594c58a8c (diff)
net-gre-gro: Add GRE support to the GRO stack
This patch built on top of Commit 299603e8370a93dd5d8e8d800f0dff1ce2c53d36 ("net-gro: Prepare GRO stack for the upcoming tunneling support") to add the support of the standard GRE (RFC1701/RFC2784/RFC2890) to the GRO stack. It also serves as an example for supporting other encapsulation protocols in the GRO stack in the future. The patch supports version 0 and all the flags (key, csum, seq#) but will flush any pkt with the S (seq#) flag. This is because the S flag is not support by GSO, and a GRO pkt may end up in the forwarding path, thus requiring GSO support to break it up correctly. Currently the "packet_offload" structure only contains L3 (ETH_P_IP/ ETH_P_IPV6) GRO offload support so the encapped pkts are limited to IP pkts (i.e., w/o L2 hdr). But support for other protocol type can be easily added, so is the support for GRE variations like NVGRE. The patch also support csum offload. Specifically if the csum flag is on and the h/w is capable of checksumming the payload (CHECKSUM_COMPLETE), the code will take advantage of the csum computed by the h/w when validating the GRE csum. Note that commit 60769a5dcd8755715c7143b4571d5c44f01796f1 "ipv4: gre: add GRO capability" already introduces GRO capability to IPv4 GRE tunnels, using the gro_cells infrastructure. But GRO is done after GRE hdr has been removed (i.e., decapped). The following patch applies GRO when pkts first come in (before hitting the GRE tunnel code). There is some performance advantage for applying GRO as early as possible. Also this approach is transparent to other subsystem like Open vSwitch where GRE decap is handled outside of the IP stack hence making it harder for the gro_cells stuff to apply. On the other hand, some NICs are still not capable of hashing on the inner hdr of a GRE pkt (RSS). In that case the GRO processing of pkts from the same remote host will all happen on the same CPU and the performance may be suboptimal. I'm including some rough preliminary performance numbers below. Note that the performance will be highly dependent on traffic load, mix as usual. Moreover it also depends on NIC offload features hence the following is by no means a comprehesive study. Local testing and tuning will be needed to decide the best setting. All tests spawned 50 copies of netperf TCP_STREAM and ran for 30 secs. (super_netperf 50 -H 192.168.1.18 -l 30) An IP GRE tunnel with only the key flag on (e.g., ip tunnel add gre1 mode gre local 10.246.17.18 remote 10.246.17.17 ttl 255 key 123) is configured. The GRO support for pkts AFTER decap are controlled through the device feature of the GRE device (e.g., ethtool -K gre1 gro on/off). 1.1 ethtool -K gre1 gro off; ethtool -K eth0 gro off thruput: 9.16Gbps CPU utilization: 19% 1.2 ethtool -K gre1 gro on; ethtool -K eth0 gro off thruput: 5.9Gbps CPU utilization: 15% 1.3 ethtool -K gre1 gro off; ethtool -K eth0 gro on thruput: 9.26Gbps CPU utilization: 12-13% 1.4 ethtool -K gre1 gro on; ethtool -K eth0 gro on thruput: 9.26Gbps CPU utilization: 10% The following tests were performed on a different NIC that is capable of csum offload. I.e., the h/w is capable of computing IP payload csum (CHECKSUM_COMPLETE). 2.1 ethtool -K gre1 gro on (hence will use gro_cells) 2.1.1 ethtool -K eth0 gro off; csum offload disabled thruput: 8.53Gbps CPU utilization: 9% 2.1.2 ethtool -K eth0 gro off; csum offload enabled thruput: 8.97Gbps CPU utilization: 7-8% 2.1.3 ethtool -K eth0 gro on; csum offload disabled thruput: 8.83Gbps CPU utilization: 5-6% 2.1.4 ethtool -K eth0 gro on; csum offload enabled thruput: 8.98Gbps CPU utilization: 5% 2.2 ethtool -K gre1 gro off 2.2.1 ethtool -K eth0 gro off; csum offload disabled thruput: 5.93Gbps CPU utilization: 9% 2.2.2 ethtool -K eth0 gro off; csum offload enabled thruput: 5.62Gbps CPU utilization: 8% 2.2.3 ethtool -K eth0 gro on; csum offload disabled thruput: 7.69Gbps CPU utilization: 8% 2.2.4 ethtool -K eth0 gro on; csum offload enabled thruput: 8.96Gbps CPU utilization: 5-6% Signed-off-by: H.K. Jerry Chu <hkchu@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/linux')
-rw-r--r--include/linux/netdevice.h18
1 files changed, 17 insertions, 1 deletions
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index d9c961aa6a7f..a2a70cc70e7b 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1632,7 +1632,10 @@ struct napi_gro_cb {
1632 int data_offset; 1632 int data_offset;
1633 1633
1634 /* This is non-zero if the packet cannot be merged with the new skb. */ 1634 /* This is non-zero if the packet cannot be merged with the new skb. */
1635 int flush; 1635 u16 flush;
1636
1637 /* Save the IP ID here and check when we get to the transport layer */
1638 u16 flush_id;
1636 1639
1637 /* Number of segments aggregated. */ 1640 /* Number of segments aggregated. */
1638 u16 count; 1641 u16 count;
@@ -1651,6 +1654,9 @@ struct napi_gro_cb {
1651 /* Used in ipv6_gro_receive() */ 1654 /* Used in ipv6_gro_receive() */
1652 int proto; 1655 int proto;
1653 1656
1657 /* used to support CHECKSUM_COMPLETE for tunneling protocols */
1658 __wsum csum;
1659
1654 /* used in skb_gro_receive() slow path */ 1660 /* used in skb_gro_receive() slow path */
1655 struct sk_buff *last; 1661 struct sk_buff *last;
1656}; 1662};
@@ -1900,6 +1906,14 @@ static inline void *skb_gro_network_header(struct sk_buff *skb)
1900 skb_network_offset(skb); 1906 skb_network_offset(skb);
1901} 1907}
1902 1908
1909static inline void skb_gro_postpull_rcsum(struct sk_buff *skb,
1910 const void *start, unsigned int len)
1911{
1912 if (skb->ip_summed == CHECKSUM_COMPLETE)
1913 NAPI_GRO_CB(skb)->csum = csum_sub(NAPI_GRO_CB(skb)->csum,
1914 csum_partial(start, len, 0));
1915}
1916
1903static inline int dev_hard_header(struct sk_buff *skb, struct net_device *dev, 1917static inline int dev_hard_header(struct sk_buff *skb, struct net_device *dev,
1904 unsigned short type, 1918 unsigned short type,
1905 const void *daddr, const void *saddr, 1919 const void *daddr, const void *saddr,
@@ -2440,6 +2454,8 @@ gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb);
2440void napi_gro_flush(struct napi_struct *napi, bool flush_old); 2454void napi_gro_flush(struct napi_struct *napi, bool flush_old);
2441struct sk_buff *napi_get_frags(struct napi_struct *napi); 2455struct sk_buff *napi_get_frags(struct napi_struct *napi);
2442gro_result_t napi_gro_frags(struct napi_struct *napi); 2456gro_result_t napi_gro_frags(struct napi_struct *napi);
2457struct packet_offload *gro_find_receive_by_type(__be16 type);
2458struct packet_offload *gro_find_complete_by_type(__be16 type);
2443 2459
2444static inline void napi_free_frags(struct napi_struct *napi) 2460static inline void napi_free_frags(struct napi_struct *napi)
2445{ 2461{