2013-06-07 09:11:46 +04:00
/*
* IPV4 GSO / GRO offload support
* Linux INET implementation
*
* This program is free software ; you can redistribute it and / or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation ; either version
* 2 of the License , or ( at your option ) any later version .
*
* TCPv4 GSO / GRO support
*/
# include <linux/skbuff.h>
# include <net/tcp.h>
# include <net/protocol.h>
2013-10-18 21:36:17 +04:00
struct sk_buff * tcp_gso_segment ( struct sk_buff * skb ,
2013-06-07 09:11:46 +04:00
netdev_features_t features )
{
struct sk_buff * segs = ERR_PTR ( - EINVAL ) ;
2013-10-26 04:26:17 +04:00
unsigned int sum_truesize = 0 ;
2013-06-07 09:11:46 +04:00
struct tcphdr * th ;
unsigned int thlen ;
unsigned int seq ;
__be32 delta ;
unsigned int oldlen ;
unsigned int mss ;
struct sk_buff * gso_skb = skb ;
__sum16 newcheck ;
bool ooo_okay , copy_destructor ;
if ( ! pskb_may_pull ( skb , sizeof ( * th ) ) )
goto out ;
th = tcp_hdr ( skb ) ;
thlen = th - > doff * 4 ;
if ( thlen < sizeof ( * th ) )
goto out ;
if ( ! pskb_may_pull ( skb , thlen ) )
goto out ;
oldlen = ( u16 ) ~ skb - > len ;
__skb_pull ( skb , thlen ) ;
mss = tcp_skb_mss ( skb ) ;
if ( unlikely ( skb - > len < = mss ) )
goto out ;
if ( skb_gso_ok ( skb , features | NETIF_F_GSO_ROBUST ) ) {
/* Packet is from an untrusted source, reset gso_segs. */
int type = skb_shinfo ( skb ) - > gso_type ;
if ( unlikely ( type &
~ ( SKB_GSO_TCPV4 |
SKB_GSO_DODGY |
SKB_GSO_TCP_ECN |
SKB_GSO_TCPV6 |
SKB_GSO_GRE |
2013-10-19 22:42:57 +04:00
SKB_GSO_IPIP |
2013-10-21 07:47:30 +04:00
SKB_GSO_SIT |
2013-06-07 09:11:46 +04:00
SKB_GSO_MPLS |
SKB_GSO_UDP_TUNNEL |
0 ) | |
! ( type & ( SKB_GSO_TCPV4 | SKB_GSO_TCPV6 ) ) ) )
goto out ;
skb_shinfo ( skb ) - > gso_segs = DIV_ROUND_UP ( skb - > len , mss ) ;
segs = NULL ;
goto out ;
}
copy_destructor = gso_skb - > destructor = = tcp_wfree ;
ooo_okay = gso_skb - > ooo_okay ;
/* All segments but the first should have ooo_okay cleared */
skb - > ooo_okay = 0 ;
segs = skb_segment ( skb , features ) ;
if ( IS_ERR ( segs ) )
goto out ;
/* Only first segment might have ooo_okay set */
segs - > ooo_okay = ooo_okay ;
delta = htonl ( oldlen + ( thlen + mss ) ) ;
skb = segs ;
th = tcp_hdr ( skb ) ;
seq = ntohl ( th - > seq ) ;
newcheck = ~ csum_fold ( ( __force __wsum ) ( ( __force u32 ) th - > check +
( __force u32 ) delta ) ) ;
do {
th - > fin = th - > psh = 0 ;
th - > check = newcheck ;
if ( skb - > ip_summed ! = CHECKSUM_PARTIAL )
th - > check =
csum_fold ( csum_partial ( skb_transport_header ( skb ) ,
thlen , skb - > csum ) ) ;
seq + = mss ;
if ( copy_destructor ) {
skb - > destructor = gso_skb - > destructor ;
skb - > sk = gso_skb - > sk ;
2013-10-26 04:26:17 +04:00
sum_truesize + = skb - > truesize ;
2013-06-07 09:11:46 +04:00
}
skb = skb - > next ;
th = tcp_hdr ( skb ) ;
th - > seq = htonl ( seq ) ;
th - > cwr = 0 ;
} while ( skb - > next ) ;
/* Following permits TCP Small Queues to work well with GSO :
* The callback to TCP stack will be called at the time last frag
* is freed at TX completion , and not right now when gso_skb
* is freed by GSO engine
*/
if ( copy_destructor ) {
swap ( gso_skb - > sk , skb - > sk ) ;
swap ( gso_skb - > destructor , skb - > destructor ) ;
2013-10-26 04:26:17 +04:00
sum_truesize + = skb - > truesize ;
atomic_add ( sum_truesize - gso_skb - > truesize ,
& skb - > sk - > sk_wmem_alloc ) ;
2013-06-07 09:11:46 +04:00
}
delta = htonl ( oldlen + ( skb_tail_pointer ( skb ) -
skb_transport_header ( skb ) ) +
skb - > data_len ) ;
th - > check = ~ csum_fold ( ( __force __wsum ) ( ( __force u32 ) th - > check +
( __force u32 ) delta ) ) ;
if ( skb - > ip_summed ! = CHECKSUM_PARTIAL )
th - > check = csum_fold ( csum_partial ( skb_transport_header ( skb ) ,
thlen , skb - > csum ) ) ;
out :
return segs ;
}
struct sk_buff * * tcp_gro_receive ( struct sk_buff * * head , struct sk_buff * skb )
{
struct sk_buff * * pp = NULL ;
struct sk_buff * p ;
struct tcphdr * th ;
struct tcphdr * th2 ;
unsigned int len ;
unsigned int thlen ;
__be32 flags ;
unsigned int mss = 1 ;
unsigned int hlen ;
unsigned int off ;
int flush = 1 ;
int i ;
off = skb_gro_offset ( skb ) ;
hlen = off + sizeof ( * th ) ;
th = skb_gro_header_fast ( skb , off ) ;
if ( skb_gro_header_hard ( skb , hlen ) ) {
th = skb_gro_header_slow ( skb , hlen , off ) ;
if ( unlikely ( ! th ) )
goto out ;
}
thlen = th - > doff * 4 ;
if ( thlen < sizeof ( * th ) )
goto out ;
hlen = off + thlen ;
if ( skb_gro_header_hard ( skb , hlen ) ) {
th = skb_gro_header_slow ( skb , hlen , off ) ;
if ( unlikely ( ! th ) )
goto out ;
}
skb_gro_pull ( skb , thlen ) ;
len = skb_gro_len ( skb ) ;
flags = tcp_flag_word ( th ) ;
for ( ; ( p = * head ) ; head = & p - > next ) {
if ( ! NAPI_GRO_CB ( p ) - > same_flow )
continue ;
th2 = tcp_hdr ( p ) ;
if ( * ( u32 * ) & th - > source ^ * ( u32 * ) & th2 - > source ) {
NAPI_GRO_CB ( p ) - > same_flow = 0 ;
continue ;
}
goto found ;
}
goto out_check_final ;
found :
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>
2014-01-07 22:23:19 +04:00
/* Include the IP ID check below from the inner most IP hdr */
flush = NAPI_GRO_CB ( p ) - > flush | NAPI_GRO_CB ( p ) - > flush_id ;
2013-06-07 09:11:46 +04:00
flush | = ( __force int ) ( flags & TCP_FLAG_CWR ) ;
flush | = ( __force int ) ( ( flags ^ tcp_flag_word ( th2 ) ) &
~ ( TCP_FLAG_CWR | TCP_FLAG_FIN | TCP_FLAG_PSH ) ) ;
flush | = ( __force int ) ( th - > ack_seq ^ th2 - > ack_seq ) ;
for ( i = sizeof ( * th ) ; i < thlen ; i + = 4 )
flush | = * ( u32 * ) ( ( u8 * ) th + i ) ^
* ( u32 * ) ( ( u8 * ) th2 + i ) ;
mss = tcp_skb_mss ( p ) ;
flush | = ( len - 1 ) > = mss ;
flush | = ( ntohl ( th2 - > seq ) + skb_gro_len ( p ) ) ^ ntohl ( th - > seq ) ;
if ( flush | | skb_gro_receive ( head , skb ) ) {
mss = 1 ;
goto out_check_final ;
}
p = * head ;
th2 = tcp_hdr ( p ) ;
tcp_flag_word ( th2 ) | = flags & ( TCP_FLAG_FIN | TCP_FLAG_PSH ) ;
out_check_final :
flush = len < mss ;
flush | = ( __force int ) ( flags & ( TCP_FLAG_URG | TCP_FLAG_PSH |
TCP_FLAG_RST | TCP_FLAG_SYN |
TCP_FLAG_FIN ) ) ;
if ( p & & ( ! NAPI_GRO_CB ( skb ) - > same_flow | | flush ) )
pp = head ;
out :
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>
2014-01-07 22:23:19 +04:00
NAPI_GRO_CB ( skb ) - > flush | = ( flush ! = 0 ) ;
2013-06-07 09:11:46 +04:00
return pp ;
}
int tcp_gro_complete ( struct sk_buff * skb )
{
struct tcphdr * th = tcp_hdr ( skb ) ;
net-gro: Prepare GRO stack for the upcoming tunneling support
This patch modifies the GRO stack to avoid the use of "network_header"
and associated macros like ip_hdr() and ipv6_hdr() in order to allow
an arbitary number of IP hdrs (v4 or v6) to be used in the
encapsulation chain. This lays the foundation for various IP
tunneling support (IP-in-IP, GRE, VXLAN, SIT,...) to be added later.
With this patch, the GRO stack traversing now is mostly based on
skb_gro_offset rather than special hdr offsets saved in skb (e.g.,
skb->network_header). As a result all but the top layer (i.e., the
the transport layer) must have hdrs of the same length in order for
a pkt to be considered for aggregation. Therefore when adding a new
encap layer (e.g., for tunneling), one must check and skip flows
(e.g., by setting NAPI_GRO_CB(p)->same_flow to 0) that have a
different hdr length.
Note that unlike the network header, the transport header can and
will continue to be set by the GRO code since there will be at
most one "transport layer" in the encap chain.
Signed-off-by: H.K. Jerry Chu <hkchu@google.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-12 08:53:45 +04:00
skb - > csum_start = ( unsigned char * ) th - skb - > head ;
2013-06-07 09:11:46 +04:00
skb - > csum_offset = offsetof ( struct tcphdr , check ) ;
skb - > ip_summed = CHECKSUM_PARTIAL ;
skb_shinfo ( skb ) - > gso_segs = NAPI_GRO_CB ( skb ) - > count ;
if ( th - > cwr )
skb_shinfo ( skb ) - > gso_type | = SKB_GSO_TCP_ECN ;
return 0 ;
}
EXPORT_SYMBOL ( tcp_gro_complete ) ;
static int tcp_v4_gso_send_check ( struct sk_buff * skb )
{
const struct iphdr * iph ;
struct tcphdr * th ;
if ( ! pskb_may_pull ( skb , sizeof ( * th ) ) )
return - EINVAL ;
iph = ip_hdr ( skb ) ;
th = tcp_hdr ( skb ) ;
th - > check = 0 ;
skb - > ip_summed = CHECKSUM_PARTIAL ;
__tcp_v4_send_check ( skb , iph - > saddr , iph - > daddr ) ;
return 0 ;
}
static struct sk_buff * * tcp4_gro_receive ( struct sk_buff * * head , struct sk_buff * skb )
{
net-gro: Prepare GRO stack for the upcoming tunneling support
This patch modifies the GRO stack to avoid the use of "network_header"
and associated macros like ip_hdr() and ipv6_hdr() in order to allow
an arbitary number of IP hdrs (v4 or v6) to be used in the
encapsulation chain. This lays the foundation for various IP
tunneling support (IP-in-IP, GRE, VXLAN, SIT,...) to be added later.
With this patch, the GRO stack traversing now is mostly based on
skb_gro_offset rather than special hdr offsets saved in skb (e.g.,
skb->network_header). As a result all but the top layer (i.e., the
the transport layer) must have hdrs of the same length in order for
a pkt to be considered for aggregation. Therefore when adding a new
encap layer (e.g., for tunneling), one must check and skip flows
(e.g., by setting NAPI_GRO_CB(p)->same_flow to 0) that have a
different hdr length.
Note that unlike the network header, the transport header can and
will continue to be set by the GRO code since there will be at
most one "transport layer" in the encap chain.
Signed-off-by: H.K. Jerry Chu <hkchu@google.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-12 08:53:45 +04:00
/* Use the IP hdr immediately proceeding for this transport */
2013-06-07 09:11:46 +04:00
const struct iphdr * iph = skb_gro_network_header ( skb ) ;
__wsum wsum ;
2013-11-22 06:31:29 +04:00
/* Don't bother verifying checksum if we're going to flush anyway. */
if ( NAPI_GRO_CB ( skb ) - > flush )
goto skip_csum ;
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>
2014-01-07 22:23:19 +04:00
wsum = NAPI_GRO_CB ( skb ) - > csum ;
2013-11-22 06:32:11 +04:00
2013-06-07 09:11:46 +04:00
switch ( skb - > ip_summed ) {
2013-11-22 06:32:11 +04:00
case CHECKSUM_NONE :
wsum = skb_checksum ( skb , skb_gro_offset ( skb ) , skb_gro_len ( skb ) ,
0 ) ;
/* fall through */
2013-06-07 09:11:46 +04:00
case CHECKSUM_COMPLETE :
if ( ! tcp_v4_check ( skb_gro_len ( skb ) , iph - > saddr , iph - > daddr ,
2013-11-22 06:32:11 +04:00
wsum ) ) {
2013-06-07 09:11:46 +04:00
skb - > ip_summed = CHECKSUM_UNNECESSARY ;
break ;
}
2013-11-22 06:32:11 +04:00
2013-06-07 09:11:46 +04:00
NAPI_GRO_CB ( skb ) - > flush = 1 ;
return NULL ;
}
2013-11-22 06:31:29 +04:00
skip_csum :
2013-06-07 09:11:46 +04:00
return tcp_gro_receive ( head , skb ) ;
}
net-gro: Prepare GRO stack for the upcoming tunneling support
This patch modifies the GRO stack to avoid the use of "network_header"
and associated macros like ip_hdr() and ipv6_hdr() in order to allow
an arbitary number of IP hdrs (v4 or v6) to be used in the
encapsulation chain. This lays the foundation for various IP
tunneling support (IP-in-IP, GRE, VXLAN, SIT,...) to be added later.
With this patch, the GRO stack traversing now is mostly based on
skb_gro_offset rather than special hdr offsets saved in skb (e.g.,
skb->network_header). As a result all but the top layer (i.e., the
the transport layer) must have hdrs of the same length in order for
a pkt to be considered for aggregation. Therefore when adding a new
encap layer (e.g., for tunneling), one must check and skip flows
(e.g., by setting NAPI_GRO_CB(p)->same_flow to 0) that have a
different hdr length.
Note that unlike the network header, the transport header can and
will continue to be set by the GRO code since there will be at
most one "transport layer" in the encap chain.
Signed-off-by: H.K. Jerry Chu <hkchu@google.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-12 08:53:45 +04:00
static int tcp4_gro_complete ( struct sk_buff * skb , int thoff )
2013-06-07 09:11:46 +04:00
{
const struct iphdr * iph = ip_hdr ( skb ) ;
struct tcphdr * th = tcp_hdr ( skb ) ;
net-gro: Prepare GRO stack for the upcoming tunneling support
This patch modifies the GRO stack to avoid the use of "network_header"
and associated macros like ip_hdr() and ipv6_hdr() in order to allow
an arbitary number of IP hdrs (v4 or v6) to be used in the
encapsulation chain. This lays the foundation for various IP
tunneling support (IP-in-IP, GRE, VXLAN, SIT,...) to be added later.
With this patch, the GRO stack traversing now is mostly based on
skb_gro_offset rather than special hdr offsets saved in skb (e.g.,
skb->network_header). As a result all but the top layer (i.e., the
the transport layer) must have hdrs of the same length in order for
a pkt to be considered for aggregation. Therefore when adding a new
encap layer (e.g., for tunneling), one must check and skip flows
(e.g., by setting NAPI_GRO_CB(p)->same_flow to 0) that have a
different hdr length.
Note that unlike the network header, the transport header can and
will continue to be set by the GRO code since there will be at
most one "transport layer" in the encap chain.
Signed-off-by: H.K. Jerry Chu <hkchu@google.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-12 08:53:45 +04:00
th - > check = ~ tcp_v4_check ( skb - > len - thoff , iph - > saddr ,
iph - > daddr , 0 ) ;
2013-06-07 09:11:46 +04:00
skb_shinfo ( skb ) - > gso_type = SKB_GSO_TCPV4 ;
return tcp_gro_complete ( skb ) ;
}
static const struct net_offload tcpv4_offload = {
. callbacks = {
. gso_send_check = tcp_v4_gso_send_check ,
2013-10-18 21:36:17 +04:00
. gso_segment = tcp_gso_segment ,
2013-06-07 09:11:46 +04:00
. gro_receive = tcp4_gro_receive ,
. gro_complete = tcp4_gro_complete ,
} ,
} ;
int __init tcpv4_offload_init ( void )
{
return inet_add_offload ( & tcpv4_offload , IPPROTO_TCP ) ;
}