* [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
@ 2016-05-06 22:11 Tom Herbert
2016-05-06 22:11 ` [PATCH v3 net-next 01/11] gso: Remove arbitrary checks for unsupported GSO Tom Herbert
` (11 more replies)
0 siblings, 12 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:11 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
This patch set:
- Fixes GRE6 to process translate flags correctly from configuration
- Adds support for GSO and GRO for ip6ip6 and ip4ip6
- Add support for FOU and GUE in IPv6
- Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
- Fixes ip6_input to deal with UDP encapsulations
- Some other minor fixes
v2:
- Removed a check of GSO types in MPLS
- Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
from Alexander)
- Don't define GSO types specifally for IP6IP6 and IP4IP6, above
fix makes that uncessary
- Don't bother clearing encapsulation flag in UDP tunnel segment
(another item suggested by Alexander).
v3:
- Address some minor comments from Alexander
Tested:
Tested a variety of case, but not the full matrix (which is quite
large now). Most of the obivous cases (e.g. GRE) work fine. Still
some issues probably with GSO/GRO being effective in all cases.
- IPv4/GRE/GUE/IPv6 with RCO
1 TCP_STREAM
6616 Mbps
200 TCP_RR
1244043 tps
141/243/446 90/95/99% latencies
86.61% CPU utilization
- IPv6/GRE/GUE/IPv6 with RCO
1 TCP_STREAM
6940 Mbps
200 TCP_RR
1270903 tps
138/236/440 90/95/99% latencies
87.51% CPU utilization
- IP6IP6
1 TCP_STREAM
2576 Mbps
200 TCP_RR
498981 tps
388/498/631 90/95/99% latencies
19.75% CPU utilization (1 CPU saturated)
- IP6IP6/GUE/IPv6 with RCO
1 TCP_STREAM
1854 Mbps
200 TCP_RR
1233818 tps
143/244/451 90/95/99% latencies
87.57 CPU utilization
- IP4IP6
1 TCP_STREAM
200 TCP_RR
763774 tps
250/318/466 90/95/99% latencies
35.25% CPU utilization (1 CPU saturated)
- GRE with keyid
200 TCP_RR
744173 tps
258/332/461 90/95/99% latencies
34.59% CPU utilization (1 CPU saturated)
Tom Herbert (11):
gso: Remove arbitrary checks for unsupported GSO
net: define gso types for IPx over IPv4 and IPv6
gre6: Fix flag translations
fou: Call setup_udp_tunnel_sock
fou: Split out {fou,gue}_build_header
fou: Add encap ops for IPv6 tunnels
ipv6: Fix nexthdr for reinjection
ipv6: Change "final" protocol processing for encapsulation
fou: Support IPv6 in fou
ip6_tun: Add infrastructure for doing encapsulation
ip6_gre: Add support for fou/gue encapsulation
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 5 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +-
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 3 +-
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 3 +-
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 3 +-
include/linux/netdev_features.h | 12 +-
include/linux/netdevice.h | 4 +-
include/linux/skbuff.h | 4 +-
include/net/fou.h | 10 +-
include/net/ip6_tunnel.h | 22 +++-
net/core/ethtool.c | 4 +-
net/ipv4/af_inet.c | 20 +--
net/ipv4/fou.c | 144 +++++++++++++---------
net/ipv4/gre_offload.c | 14 ---
net/ipv4/ipip.c | 2 +-
net/ipv4/tcp_offload.c | 19 ---
net/ipv4/udp_offload.c | 10 --
net/ipv6/Makefile | 4 +-
net/ipv6/fou6.c | 140 +++++++++++++++++++++
net/ipv6/ip6_gre.c | 95 ++++++++++++--
net/ipv6/ip6_input.c | 24 +++-
net/ipv6/ip6_offload.c | 22 +---
net/ipv6/ip6_tunnel.c | 4 +
net/ipv6/ip6_tunnel_core.c | 108 ++++++++++++++++
net/ipv6/sit.c | 4 +-
net/ipv6/udp_offload.c | 13 --
net/mpls/mpls_gso.c | 9 --
net/netfilter/ipvs/ip_vs_xmit.c | 17 ++-
31 files changed, 511 insertions(+), 221 deletions(-)
create mode 100644 net/ipv6/fou6.c
create mode 100644 net/ipv6/ip6_tunnel_core.c
--
2.8.0.rc2
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 01/11] gso: Remove arbitrary checks for unsupported GSO
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
@ 2016-05-06 22:11 ` Tom Herbert
2016-05-06 22:34 ` Alexander Duyck
2016-05-07 2:44 ` Alexander Duyck
2016-05-06 22:11 ` [PATCH v3 net-next 02/11] net: define gso types for IPx over IPv4 and IPv6 Tom Herbert
` (10 subsequent siblings)
11 siblings, 2 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:11 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
In several gso_segment functions there are checks of gso_type against
a seemingly arbitrary list of SKB_GSO_* flags. This seems like an
attempt to identify unsupported GSO types, but since the stack is
the one that set these GSO types in the first place this seems
unnecessary to do. If a combination isn't valid in the first
place that stack should not allow setting it.
This is a code simplication especially for add new GSO types.
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
net/ipv4/af_inet.c | 18 ------------------
net/ipv4/gre_offload.c | 14 --------------
net/ipv4/tcp_offload.c | 19 -------------------
net/ipv4/udp_offload.c | 10 ----------
net/ipv6/ip6_offload.c | 18 ------------------
net/ipv6/udp_offload.c | 13 -------------
net/mpls/mpls_gso.c | 9 ---------
7 files changed, 101 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 2e6e65f..7f08d45 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1205,24 +1205,6 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
int ihl;
int id;
- if (unlikely(skb_shinfo(skb)->gso_type &
- ~(SKB_GSO_TCPV4 |
- SKB_GSO_UDP |
- SKB_GSO_DODGY |
- SKB_GSO_TCP_ECN |
- SKB_GSO_GRE |
- SKB_GSO_GRE_CSUM |
- SKB_GSO_IPIP |
- SKB_GSO_SIT |
- SKB_GSO_TCPV6 |
- SKB_GSO_UDP_TUNNEL |
- SKB_GSO_UDP_TUNNEL_CSUM |
- SKB_GSO_TCP_FIXEDID |
- SKB_GSO_TUNNEL_REMCSUM |
- SKB_GSO_PARTIAL |
- 0)))
- goto out;
-
skb_reset_network_header(skb);
nhoff = skb_network_header(skb) - skb_mac_header(skb);
if (unlikely(!pskb_may_pull(skb, sizeof(*iph))))
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index e88190a..ecd1e09 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -26,20 +26,6 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
int gre_offset, outer_hlen;
bool need_csum, ufo;
- if (unlikely(skb_shinfo(skb)->gso_type &
- ~(SKB_GSO_TCPV4 |
- SKB_GSO_TCPV6 |
- SKB_GSO_UDP |
- SKB_GSO_DODGY |
- SKB_GSO_TCP_ECN |
- SKB_GSO_TCP_FIXEDID |
- SKB_GSO_GRE |
- SKB_GSO_GRE_CSUM |
- SKB_GSO_IPIP |
- SKB_GSO_SIT |
- SKB_GSO_PARTIAL)))
- goto out;
-
if (!skb->encapsulation)
goto out;
diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
index 02737b6..5c59649 100644
--- a/net/ipv4/tcp_offload.c
+++ b/net/ipv4/tcp_offload.c
@@ -83,25 +83,6 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb,
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_TCP_FIXEDID |
- SKB_GSO_TCPV6 |
- SKB_GSO_GRE |
- SKB_GSO_GRE_CSUM |
- SKB_GSO_IPIP |
- SKB_GSO_SIT |
- SKB_GSO_UDP_TUNNEL |
- SKB_GSO_UDP_TUNNEL_CSUM |
- SKB_GSO_TUNNEL_REMCSUM |
- 0) ||
- !(type & (SKB_GSO_TCPV4 |
- SKB_GSO_TCPV6))))
- goto out;
skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 097060de..b556ef6 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -209,16 +209,6 @@ static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
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_UDP | SKB_GSO_DODGY |
- SKB_GSO_UDP_TUNNEL |
- SKB_GSO_UDP_TUNNEL_CSUM |
- SKB_GSO_TUNNEL_REMCSUM |
- SKB_GSO_IPIP |
- SKB_GSO_GRE | SKB_GSO_GRE_CSUM) ||
- !(type & (SKB_GSO_UDP))))
- goto out;
skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index f5eb184..9ad743b 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -69,24 +69,6 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
bool encap, udpfrag;
int nhoff;
- if (unlikely(skb_shinfo(skb)->gso_type &
- ~(SKB_GSO_TCPV4 |
- SKB_GSO_UDP |
- SKB_GSO_DODGY |
- SKB_GSO_TCP_ECN |
- SKB_GSO_TCP_FIXEDID |
- SKB_GSO_TCPV6 |
- SKB_GSO_GRE |
- SKB_GSO_GRE_CSUM |
- SKB_GSO_IPIP |
- SKB_GSO_SIT |
- SKB_GSO_UDP_TUNNEL |
- SKB_GSO_UDP_TUNNEL_CSUM |
- SKB_GSO_TUNNEL_REMCSUM |
- SKB_GSO_PARTIAL |
- 0)))
- goto out;
-
skb_reset_network_header(skb);
nhoff = skb_network_header(skb) - skb_mac_header(skb);
if (unlikely(!pskb_may_pull(skb, sizeof(*ipv6h))))
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index 5429f6b..ac858c4 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -36,19 +36,6 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
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_UDP |
- SKB_GSO_DODGY |
- SKB_GSO_UDP_TUNNEL |
- SKB_GSO_UDP_TUNNEL_CSUM |
- SKB_GSO_TUNNEL_REMCSUM |
- SKB_GSO_GRE |
- SKB_GSO_GRE_CSUM |
- SKB_GSO_IPIP |
- SKB_GSO_SIT) ||
- !(type & (SKB_GSO_UDP))))
- goto out;
skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
diff --git a/net/mpls/mpls_gso.c b/net/mpls/mpls_gso.c
index bbcf604..6de1e13 100644
--- a/net/mpls/mpls_gso.c
+++ b/net/mpls/mpls_gso.c
@@ -26,15 +26,6 @@ static struct sk_buff *mpls_gso_segment(struct sk_buff *skb,
netdev_features_t mpls_features;
__be16 mpls_protocol;
- if (unlikely(skb_shinfo(skb)->gso_type &
- ~(SKB_GSO_TCPV4 |
- SKB_GSO_TCPV6 |
- SKB_GSO_UDP |
- SKB_GSO_DODGY |
- SKB_GSO_TCP_FIXEDID |
- SKB_GSO_TCP_ECN)))
- goto out;
-
/* Setup inner SKB. */
mpls_protocol = skb->protocol;
skb->protocol = skb->inner_protocol;
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 02/11] net: define gso types for IPx over IPv4 and IPv6
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
2016-05-06 22:11 ` [PATCH v3 net-next 01/11] gso: Remove arbitrary checks for unsupported GSO Tom Herbert
@ 2016-05-06 22:11 ` Tom Herbert
2016-05-06 22:48 ` Alexander Duyck
2016-05-06 22:11 ` [PATCH v3 net-next 03/11] gre6: Fix flag translations Tom Herbert
` (9 subsequent siblings)
11 siblings, 1 reply; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:11 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
This patch defines two new GDO definitions SKB_GSO_IPXIP4 and
SKB_GSO_IPXIP6 along with corresponding NETIF_F_GSO_IPXIP4 and
NETIF_F_GSO_IPXIP6. These are used to described IP in IP
tunnel and what the outer protocol is. The inner protocol
can be deduced from other GSO types (e.g. SKB_GSO_TCPV4 and
SKB_GSO_TCPV6). The GSO types of SKB_GSO_IPIP and SKB_GSO_SIT
are removed (these are both instances of SKB_GSO_IPXIP4).
SKB_GSO_IPXIP6 will be used when support for GSO with IP
encapsulation over IPv6 is added.
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 5 ++---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 ++--
drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +--
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 3 +--
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 3 +--
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 3 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +--
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 3 +--
include/linux/netdev_features.h | 12 ++++++------
include/linux/netdevice.h | 4 ++--
include/linux/skbuff.h | 4 ++--
net/core/ethtool.c | 4 ++--
net/ipv4/af_inet.c | 2 +-
net/ipv4/ipip.c | 2 +-
net/ipv6/ip6_offload.c | 4 ++--
net/ipv6/sit.c | 4 ++--
net/netfilter/ipvs/ip_vs_xmit.c | 17 +++++++----------
17 files changed, 35 insertions(+), 45 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index d465bd7..0a5b770 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13259,12 +13259,11 @@ static int bnx2x_init_dev(struct bnx2x *bp, struct pci_dev *pdev,
NETIF_F_RXHASH | NETIF_F_HW_VLAN_CTAG_TX;
if (!chip_is_e1x) {
dev->hw_features |= NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL |
- NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT;
+ NETIF_F_GSO_IPXIP4;
dev->hw_enc_features =
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_SG |
NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 |
- NETIF_F_GSO_IPIP |
- NETIF_F_GSO_SIT |
+ NETIF_F_GSO_IPXIP4 |
NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL;
}
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index fd85b6d..e449228 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -6218,7 +6218,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_SG |
NETIF_F_TSO | NETIF_F_TSO6 |
NETIF_F_GSO_UDP_TUNNEL | NETIF_F_GSO_GRE |
- NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT |
+ NETIF_F_GSO_IPXIP4 |
NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_GSO_GRE_CSUM |
NETIF_F_GSO_PARTIAL | NETIF_F_RXHASH |
NETIF_F_RXCSUM | NETIF_F_LRO | NETIF_F_GRO;
@@ -6228,7 +6228,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
NETIF_F_TSO | NETIF_F_TSO6 |
NETIF_F_GSO_UDP_TUNNEL | NETIF_F_GSO_GRE |
NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_GSO_GRE_CSUM |
- NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT |
+ NETIF_F_GSO_IPXIP4;
NETIF_F_GSO_PARTIAL;
dev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM |
NETIF_F_GSO_GRE_CSUM;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index f6da6b7..c2a4c10 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -9131,8 +9131,7 @@ static int i40e_config_netdev(struct i40e_vsi *vsi)
NETIF_F_TSO6 |
NETIF_F_GSO_GRE |
NETIF_F_GSO_GRE_CSUM |
- NETIF_F_GSO_IPIP |
- NETIF_F_GSO_SIT |
+ NETIF_F_GSO_IPXIP4 |
NETIF_F_GSO_UDP_TUNNEL |
NETIF_F_GSO_UDP_TUNNEL_CSUM |
NETIF_F_GSO_PARTIAL |
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 2765d7e..4a3d60a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2302,8 +2302,7 @@ static int i40e_tso(struct sk_buff *skb, u8 *hdr_len, u64 *cd_type_cmd_tso_mss)
if (skb_shinfo(skb)->gso_type & (SKB_GSO_GRE |
SKB_GSO_GRE_CSUM |
- SKB_GSO_IPIP |
- SKB_GSO_SIT |
+ SKB_GSO_IPXIP4 |
SKB_GSO_UDP_TUNNEL |
SKB_GSO_UDP_TUNNEL_CSUM)) {
if (!(skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL) &&
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
index ede8dfc..aaccb7e 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -1567,8 +1567,7 @@ static int i40e_tso(struct sk_buff *skb, u8 *hdr_len, u64 *cd_type_cmd_tso_mss)
if (skb_shinfo(skb)->gso_type & (SKB_GSO_GRE |
SKB_GSO_GRE_CSUM |
- SKB_GSO_IPIP |
- SKB_GSO_SIT |
+ SKB_GSO_IPXIP4 |
SKB_GSO_UDP_TUNNEL |
SKB_GSO_UDP_TUNNEL_CSUM)) {
if (!(skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL) &&
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 9f0bd7a..bfd0962 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -2241,8 +2241,7 @@ int i40evf_process_config(struct i40evf_adapter *adapter)
NETIF_F_TSO6 |
NETIF_F_GSO_GRE |
NETIF_F_GSO_GRE_CSUM |
- NETIF_F_GSO_IPIP |
- NETIF_F_GSO_SIT |
+ NETIF_F_GSO_IPXIP4 |
NETIF_F_GSO_UDP_TUNNEL |
NETIF_F_GSO_UDP_TUNNEL_CSUM |
NETIF_F_GSO_PARTIAL |
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index d08fbcf..28e3b5a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9482,8 +9482,7 @@ skip_sriov:
#define IXGBE_GSO_PARTIAL_FEATURES (NETIF_F_GSO_GRE | \
NETIF_F_GSO_GRE_CSUM | \
- NETIF_F_GSO_IPIP | \
- NETIF_F_GSO_SIT | \
+ NETIF_F_GSO_IPXIP4 | \
NETIF_F_GSO_UDP_TUNNEL | \
NETIF_F_GSO_UDP_TUNNEL_CSUM)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 5e348b1..d86e511 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -4062,8 +4062,7 @@ static int ixgbevf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
#define IXGBEVF_GSO_PARTIAL_FEATURES (NETIF_F_GSO_GRE | \
NETIF_F_GSO_GRE_CSUM | \
- NETIF_F_GSO_IPIP | \
- NETIF_F_GSO_SIT | \
+ NETIF_F_GSO_IPXIP4 | \
NETIF_F_GSO_UDP_TUNNEL | \
NETIF_F_GSO_UDP_TUNNEL_CSUM)
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index bc87362..aa7b240 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -44,8 +44,8 @@ enum {
NETIF_F_FSO_BIT, /* ... FCoE segmentation */
NETIF_F_GSO_GRE_BIT, /* ... GRE with TSO */
NETIF_F_GSO_GRE_CSUM_BIT, /* ... GRE with csum with TSO */
- NETIF_F_GSO_IPIP_BIT, /* ... IPIP tunnel with TSO */
- NETIF_F_GSO_SIT_BIT, /* ... SIT tunnel with TSO */
+ NETIF_F_GSO_IPXIP4_BIT, /* ... IP4 or IP6 over IP4 with TSO */
+ NETIF_F_GSO_IPXIP6_BIT, /* ... IP4 or IP6 over IP6 with TSO */
NETIF_F_GSO_UDP_TUNNEL_BIT, /* ... UDP TUNNEL with TSO */
NETIF_F_GSO_UDP_TUNNEL_CSUM_BIT,/* ... UDP TUNNEL with TSO & CSUM */
NETIF_F_GSO_PARTIAL_BIT, /* ... Only segment inner-most L4
@@ -121,8 +121,8 @@ enum {
#define NETIF_F_RXALL __NETIF_F(RXALL)
#define NETIF_F_GSO_GRE __NETIF_F(GSO_GRE)
#define NETIF_F_GSO_GRE_CSUM __NETIF_F(GSO_GRE_CSUM)
-#define NETIF_F_GSO_IPIP __NETIF_F(GSO_IPIP)
-#define NETIF_F_GSO_SIT __NETIF_F(GSO_SIT)
+#define NETIF_F_GSO_IPXIP4 __NETIF_F(GSO_IPXIP4)
+#define NETIF_F_GSO_IPXIP6 __NETIF_F(GSO_IPXIP6)
#define NETIF_F_GSO_UDP_TUNNEL __NETIF_F(GSO_UDP_TUNNEL)
#define NETIF_F_GSO_UDP_TUNNEL_CSUM __NETIF_F(GSO_UDP_TUNNEL_CSUM)
#define NETIF_F_TSO_MANGLEID __NETIF_F(TSO_MANGLEID)
@@ -200,8 +200,8 @@ enum {
#define NETIF_F_GSO_ENCAP_ALL (NETIF_F_GSO_GRE | \
NETIF_F_GSO_GRE_CSUM | \
- NETIF_F_GSO_IPIP | \
- NETIF_F_GSO_SIT | \
+ NETIF_F_GSO_IPXIP4 | \
+ NETIF_F_GSO_IPXIP6 | \
NETIF_F_GSO_UDP_TUNNEL | \
NETIF_F_GSO_UDP_TUNNEL_CSUM)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 63580e6..8b1eedc 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -4005,8 +4005,8 @@ static inline bool net_gso_ok(netdev_features_t features, int gso_type)
BUILD_BUG_ON(SKB_GSO_FCOE != (NETIF_F_FSO >> NETIF_F_GSO_SHIFT));
BUILD_BUG_ON(SKB_GSO_GRE != (NETIF_F_GSO_GRE >> NETIF_F_GSO_SHIFT));
BUILD_BUG_ON(SKB_GSO_GRE_CSUM != (NETIF_F_GSO_GRE_CSUM >> NETIF_F_GSO_SHIFT));
- BUILD_BUG_ON(SKB_GSO_IPIP != (NETIF_F_GSO_IPIP >> NETIF_F_GSO_SHIFT));
- BUILD_BUG_ON(SKB_GSO_SIT != (NETIF_F_GSO_SIT >> NETIF_F_GSO_SHIFT));
+ BUILD_BUG_ON(SKB_GSO_IPXIP4 != (NETIF_F_GSO_IPXIP4 >> NETIF_F_GSO_SHIFT));
+ BUILD_BUG_ON(SKB_GSO_IPXIP6 != (NETIF_F_GSO_IPXIP6 >> NETIF_F_GSO_SHIFT));
BUILD_BUG_ON(SKB_GSO_UDP_TUNNEL != (NETIF_F_GSO_UDP_TUNNEL >> NETIF_F_GSO_SHIFT));
BUILD_BUG_ON(SKB_GSO_UDP_TUNNEL_CSUM != (NETIF_F_GSO_UDP_TUNNEL_CSUM >> NETIF_F_GSO_SHIFT));
BUILD_BUG_ON(SKB_GSO_PARTIAL != (NETIF_F_GSO_PARTIAL >> NETIF_F_GSO_SHIFT));
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c413c58..65968a9 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -471,9 +471,9 @@ enum {
SKB_GSO_GRE_CSUM = 1 << 8,
- SKB_GSO_IPIP = 1 << 9,
+ SKB_GSO_IPXIP4 = 1 << 9,
- SKB_GSO_SIT = 1 << 10,
+ SKB_GSO_IPXIP6 = 1 << 10,
SKB_GSO_UDP_TUNNEL = 1 << 11,
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index bdb4013..f403481 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -84,8 +84,8 @@ static const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN]
[NETIF_F_FSO_BIT] = "tx-fcoe-segmentation",
[NETIF_F_GSO_GRE_BIT] = "tx-gre-segmentation",
[NETIF_F_GSO_GRE_CSUM_BIT] = "tx-gre-csum-segmentation",
- [NETIF_F_GSO_IPIP_BIT] = "tx-ipip-segmentation",
- [NETIF_F_GSO_SIT_BIT] = "tx-sit-segmentation",
+ [NETIF_F_GSO_IPXIP4_BIT] = "tx-ipxip4-segmentation",
+ [NETIF_F_GSO_IPXIP6_BIT] = "tx-ipxip6-segmentation",
[NETIF_F_GSO_UDP_TUNNEL_BIT] = "tx-udp_tnl-segmentation",
[NETIF_F_GSO_UDP_TUNNEL_CSUM_BIT] = "tx-udp_tnl-csum-segmentation",
[NETIF_F_GSO_PARTIAL_BIT] = "tx-gso-partial",
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 7f08d45..25040b1 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1483,7 +1483,7 @@ out_unlock:
static int ipip_gro_complete(struct sk_buff *skb, int nhoff)
{
skb->encapsulation = 1;
- skb_shinfo(skb)->gso_type |= SKB_GSO_IPIP;
+ skb_shinfo(skb)->gso_type |= SKB_GSO_IPXIP4;
return inet_gro_complete(skb, nhoff);
}
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 9282748..9783701 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -219,7 +219,7 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
if (unlikely(skb->protocol != htons(ETH_P_IP)))
goto tx_error;
- if (iptunnel_handle_offloads(skb, SKB_GSO_IPIP))
+ if (iptunnel_handle_offloads(skb, SKB_GSO_IPXIP4))
goto tx_error;
skb_set_inner_ipproto(skb, IPPROTO_IPIP);
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 9ad743b..787e55f 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -86,7 +86,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
proto = ipv6_gso_pull_exthdrs(skb, ipv6h->nexthdr);
if (skb->encapsulation &&
- skb_shinfo(skb)->gso_type & (SKB_GSO_SIT|SKB_GSO_IPIP))
+ skb_shinfo(skb)->gso_type & (SKB_GSO_IPXIP4 | SKB_GSO_IPXIP6))
udpfrag = proto == IPPROTO_UDP && encap;
else
udpfrag = proto == IPPROTO_UDP && !skb->encapsulation;
@@ -294,7 +294,7 @@ out_unlock:
static int sit_gro_complete(struct sk_buff *skb, int nhoff)
{
skb->encapsulation = 1;
- skb_shinfo(skb)->gso_type |= SKB_GSO_SIT;
+ skb_shinfo(skb)->gso_type |= SKB_GSO_IPXIP4;
return ipv6_gro_complete(skb, nhoff);
}
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index a13d8c1..0a5a255 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -913,7 +913,7 @@ static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
goto tx_error;
}
- if (iptunnel_handle_offloads(skb, SKB_GSO_SIT)) {
+ if (iptunnel_handle_offloads(skb, SKB_GSO_IPXIP4)) {
ip_rt_put(rt);
goto tx_error;
}
@@ -1000,7 +1000,7 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
struct ip_tunnel *tunnel = netdev_priv(dev);
const struct iphdr *tiph = &tunnel->parms.iph;
- if (iptunnel_handle_offloads(skb, SKB_GSO_IPIP))
+ if (iptunnel_handle_offloads(skb, SKB_GSO_IPXIP4))
goto tx_error;
skb_set_inner_ipproto(skb, IPPROTO_IPIP);
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index 6d19d2e..01d3d89 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -932,17 +932,14 @@ error:
static inline int __tun_gso_type_mask(int encaps_af, int orig_af)
{
- if (encaps_af == AF_INET) {
- if (orig_af == AF_INET)
- return SKB_GSO_IPIP;
-
- return SKB_GSO_SIT;
+ switch (encaps_af) {
+ case AF_INET:
+ return SKB_GSO_IPXIP4;
+ case AF_INET6:
+ return SKB_GSO_IPXIP6;
+ default:
+ return 0;
}
-
- /* GSO: we need to provide proper SKB_GSO_ value for IPv6:
- * SKB_GSO_SIT/IPV6
- */
- return 0;
}
/*
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 03/11] gre6: Fix flag translations
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
2016-05-06 22:11 ` [PATCH v3 net-next 01/11] gso: Remove arbitrary checks for unsupported GSO Tom Herbert
2016-05-06 22:11 ` [PATCH v3 net-next 02/11] net: define gso types for IPx over IPv4 and IPv6 Tom Herbert
@ 2016-05-06 22:11 ` Tom Herbert
2016-05-06 22:11 ` [PATCH v3 net-next 04/11] fou: Call setup_udp_tunnel_sock Tom Herbert
` (8 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:11 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
GRE for IPv6 does not properly translate for GRE flags to tunnel
flags and vice versa. This patch fixes that.
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
net/ipv6/ip6_gre.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 47b671a..70a1f72 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -799,8 +799,8 @@ static void ip6gre_tnl_parm_from_user(struct __ip6_tnl_parm *p,
p->link = u->link;
p->i_key = u->i_key;
p->o_key = u->o_key;
- p->i_flags = u->i_flags;
- p->o_flags = u->o_flags;
+ p->i_flags = gre_flags_to_tnl_flags(u->i_flags);
+ p->o_flags = gre_flags_to_tnl_flags(u->o_flags);
memcpy(p->name, u->name, sizeof(u->name));
}
@@ -817,8 +817,8 @@ static void ip6gre_tnl_parm_to_user(struct ip6_tnl_parm2 *u,
u->link = p->link;
u->i_key = p->i_key;
u->o_key = p->o_key;
- u->i_flags = p->i_flags;
- u->o_flags = p->o_flags;
+ u->i_flags = gre_tnl_flags_to_gre_flags(p->i_flags);
+ u->o_flags = gre_tnl_flags_to_gre_flags(p->o_flags);
memcpy(u->name, p->name, sizeof(u->name));
}
@@ -1217,10 +1217,12 @@ static void ip6gre_netlink_parms(struct nlattr *data[],
parms->link = nla_get_u32(data[IFLA_GRE_LINK]);
if (data[IFLA_GRE_IFLAGS])
- parms->i_flags = nla_get_be16(data[IFLA_GRE_IFLAGS]);
+ parms->i_flags = gre_flags_to_tnl_flags(
+ nla_get_be16(data[IFLA_GRE_IFLAGS]));
if (data[IFLA_GRE_OFLAGS])
- parms->o_flags = nla_get_be16(data[IFLA_GRE_OFLAGS]);
+ parms->o_flags = gre_flags_to_tnl_flags(
+ nla_get_be16(data[IFLA_GRE_OFLAGS]));
if (data[IFLA_GRE_IKEY])
parms->i_key = nla_get_be32(data[IFLA_GRE_IKEY]);
@@ -1412,8 +1414,10 @@ static int ip6gre_fill_info(struct sk_buff *skb, const struct net_device *dev)
struct __ip6_tnl_parm *p = &t->parms;
if (nla_put_u32(skb, IFLA_GRE_LINK, p->link) ||
- nla_put_be16(skb, IFLA_GRE_IFLAGS, p->i_flags) ||
- nla_put_be16(skb, IFLA_GRE_OFLAGS, p->o_flags) ||
+ nla_put_be16(skb, IFLA_GRE_IFLAGS,
+ gre_tnl_flags_to_gre_flags(p->i_flags)) ||
+ nla_put_be16(skb, IFLA_GRE_OFLAGS,
+ gre_tnl_flags_to_gre_flags(p->o_flags)) ||
nla_put_be32(skb, IFLA_GRE_IKEY, p->i_key) ||
nla_put_be32(skb, IFLA_GRE_OKEY, p->o_key) ||
nla_put_in6_addr(skb, IFLA_GRE_LOCAL, &p->laddr) ||
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 04/11] fou: Call setup_udp_tunnel_sock
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
` (2 preceding siblings ...)
2016-05-06 22:11 ` [PATCH v3 net-next 03/11] gre6: Fix flag translations Tom Herbert
@ 2016-05-06 22:11 ` Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 05/11] fou: Split out {fou,gue}_build_header Tom Herbert
` (7 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:11 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
Use helper function to set up UDP tunnel related information for a fou
socket.
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
net/ipv4/fou.c | 50 ++++++++++++++++----------------------------------
1 file changed, 16 insertions(+), 34 deletions(-)
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index 7ac5ec8..a8b5cbf 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -446,31 +446,13 @@ static void fou_release(struct fou *fou)
kfree_rcu(fou, rcu);
}
-static int fou_encap_init(struct sock *sk, struct fou *fou, struct fou_cfg *cfg)
-{
- udp_sk(sk)->encap_rcv = fou_udp_recv;
- udp_sk(sk)->gro_receive = fou_gro_receive;
- udp_sk(sk)->gro_complete = fou_gro_complete;
- fou_from_sock(sk)->protocol = cfg->protocol;
-
- return 0;
-}
-
-static int gue_encap_init(struct sock *sk, struct fou *fou, struct fou_cfg *cfg)
-{
- udp_sk(sk)->encap_rcv = gue_udp_recv;
- udp_sk(sk)->gro_receive = gue_gro_receive;
- udp_sk(sk)->gro_complete = gue_gro_complete;
-
- return 0;
-}
-
static int fou_create(struct net *net, struct fou_cfg *cfg,
struct socket **sockp)
{
struct socket *sock = NULL;
struct fou *fou = NULL;
struct sock *sk;
+ struct udp_tunnel_sock_cfg tunnel_cfg;
int err;
/* Open UDP socket */
@@ -489,33 +471,33 @@ static int fou_create(struct net *net, struct fou_cfg *cfg,
fou->flags = cfg->flags;
fou->port = cfg->udp_config.local_udp_port;
+ fou->type = cfg->type;
+ fou->sock = sock;
+
+ memset(&tunnel_cfg, 0, sizeof(tunnel_cfg));
+ tunnel_cfg.encap_type = 1;
+ tunnel_cfg.sk_user_data = fou;
+ tunnel_cfg.encap_destroy = NULL;
/* Initial for fou type */
switch (cfg->type) {
case FOU_ENCAP_DIRECT:
- err = fou_encap_init(sk, fou, cfg);
- if (err)
- goto error;
+ tunnel_cfg.encap_rcv = fou_udp_recv;
+ tunnel_cfg.gro_receive = fou_gro_receive;
+ tunnel_cfg.gro_complete = fou_gro_complete;
+ fou->protocol = cfg->protocol;
break;
case FOU_ENCAP_GUE:
- err = gue_encap_init(sk, fou, cfg);
- if (err)
- goto error;
+ tunnel_cfg.encap_rcv = gue_udp_recv;
+ tunnel_cfg.gro_receive = gue_gro_receive;
+ tunnel_cfg.gro_complete = gue_gro_complete;
break;
default:
err = -EINVAL;
goto error;
}
- fou->type = cfg->type;
-
- udp_sk(sk)->encap_type = 1;
- udp_encap_enable();
-
- sk->sk_user_data = fou;
- fou->sock = sock;
-
- inet_inc_convert_csum(sk);
+ setup_udp_tunnel_sock(net, sock, &tunnel_cfg);
sk->sk_allocation = GFP_ATOMIC;
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 05/11] fou: Split out {fou,gue}_build_header
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
` (3 preceding siblings ...)
2016-05-06 22:11 ` [PATCH v3 net-next 04/11] fou: Call setup_udp_tunnel_sock Tom Herbert
@ 2016-05-06 22:12 ` Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 06/11] fou: Add encap ops for IPv6 tunnels Tom Herbert
` (6 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:12 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
Create __fou_build_header and __gue_build_header. These implement the
protocol generic parts of building the fou and gue header.
fou_build_header and gue_build_header implement the IPv4 specific
functions and call the __*_build_header functions.
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
include/net/fou.h | 8 ++++----
net/ipv4/fou.c | 47 +++++++++++++++++++++++++++++++++++++----------
2 files changed, 41 insertions(+), 14 deletions(-)
diff --git a/include/net/fou.h b/include/net/fou.h
index 19b8a0c..7d2fda2 100644
--- a/include/net/fou.h
+++ b/include/net/fou.h
@@ -11,9 +11,9 @@
size_t fou_encap_hlen(struct ip_tunnel_encap *e);
static size_t gue_encap_hlen(struct ip_tunnel_encap *e);
-int fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
- u8 *protocol, struct flowi4 *fl4);
-int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
- u8 *protocol, struct flowi4 *fl4);
+int __fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ u8 *protocol, __be16 *sport, int type);
+int __gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ u8 *protocol, __be16 *sport, int type);
#endif
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index a8b5cbf..971c8c6 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -778,6 +778,22 @@ static void fou_build_udp(struct sk_buff *skb, struct ip_tunnel_encap *e,
*protocol = IPPROTO_UDP;
}
+int __fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ u8 *protocol, __be16 *sport, int type)
+{
+ int err;
+
+ err = iptunnel_handle_offloads(skb, type);
+ if (err)
+ return err;
+
+ *sport = e->sport ? : udp_flow_src_port(dev_net(skb->dev),
+ skb, 0, 0, false);
+
+ return 0;
+}
+EXPORT_SYMBOL(__fou_build_header);
+
int fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
u8 *protocol, struct flowi4 *fl4)
{
@@ -786,26 +802,21 @@ int fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
__be16 sport;
int err;
- err = iptunnel_handle_offloads(skb, type);
+ err = __fou_build_header(skb, e, protocol, &sport, type);
if (err)
return err;
- sport = e->sport ? : udp_flow_src_port(dev_net(skb->dev),
- skb, 0, 0, false);
fou_build_udp(skb, e, fl4, protocol, sport);
return 0;
}
EXPORT_SYMBOL(fou_build_header);
-int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
- u8 *protocol, struct flowi4 *fl4)
+int __gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ u8 *protocol, __be16 *sport, int type)
{
- int type = e->flags & TUNNEL_ENCAP_FLAG_CSUM ? SKB_GSO_UDP_TUNNEL_CSUM :
- SKB_GSO_UDP_TUNNEL;
struct guehdr *guehdr;
size_t hdrlen, optlen = 0;
- __be16 sport;
void *data;
bool need_priv = false;
int err;
@@ -824,8 +835,8 @@ int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
return err;
/* Get source port (based on flow hash) before skb_push */
- sport = e->sport ? : udp_flow_src_port(dev_net(skb->dev),
- skb, 0, 0, false);
+ *sport = e->sport ? : udp_flow_src_port(dev_net(skb->dev),
+ skb, 0, 0, false);
hdrlen = sizeof(struct guehdr) + optlen;
@@ -870,6 +881,22 @@ int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
}
+ return 0;
+}
+EXPORT_SYMBOL(__gue_build_header);
+
+int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ u8 *protocol, struct flowi4 *fl4)
+{
+ int type = e->flags & TUNNEL_ENCAP_FLAG_CSUM ? SKB_GSO_UDP_TUNNEL_CSUM :
+ SKB_GSO_UDP_TUNNEL;
+ __be16 sport;
+ int err;
+
+ err = __gue_build_header(skb, e, protocol, &sport, type);
+ if (err)
+ return err;
+
fou_build_udp(skb, e, fl4, protocol, sport);
return 0;
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 06/11] fou: Add encap ops for IPv6 tunnels
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
` (4 preceding siblings ...)
2016-05-06 22:12 ` [PATCH v3 net-next 05/11] fou: Split out {fou,gue}_build_header Tom Herbert
@ 2016-05-06 22:12 ` Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 07/11] ipv6: Fix nexthdr for reinjection Tom Herbert
` (5 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:12 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
Thsi packet adds IP tunnel encapsulation operations for IPv6. This
includes the infrastructure to add and delete operations. IPv6 variants
for fou6_build_header and gue6_build_header are added in a new
fou6 module. These encapsulation operations for fou and gue are
automatically added when the fou6 module loads.
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
include/net/fou.h | 2 +-
include/net/ip6_tunnel.h | 14 +++++
net/ipv6/Makefile | 4 +-
net/ipv6/fou6.c | 140 +++++++++++++++++++++++++++++++++++++++++++++
net/ipv6/ip6_tunnel_core.c | 44 ++++++++++++++
5 files changed, 202 insertions(+), 2 deletions(-)
create mode 100644 net/ipv6/fou6.c
create mode 100644 net/ipv6/ip6_tunnel_core.c
diff --git a/include/net/fou.h b/include/net/fou.h
index 7d2fda2..f5cc691 100644
--- a/include/net/fou.h
+++ b/include/net/fou.h
@@ -9,7 +9,7 @@
#include <net/udp.h>
size_t fou_encap_hlen(struct ip_tunnel_encap *e);
-static size_t gue_encap_hlen(struct ip_tunnel_encap *e);
+size_t gue_encap_hlen(struct ip_tunnel_encap *e);
int __fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
u8 *protocol, __be16 *sport, int type);
diff --git a/include/net/ip6_tunnel.h b/include/net/ip6_tunnel.h
index fb9e015..1c14c27 100644
--- a/include/net/ip6_tunnel.h
+++ b/include/net/ip6_tunnel.h
@@ -34,6 +34,20 @@ struct __ip6_tnl_parm {
__be32 o_key;
};
+struct ip6_tnl_encap_ops {
+ size_t (*encap_hlen)(struct ip_tunnel_encap *e);
+ int (*build_header)(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ u8 *protocol, struct flowi6 *fl6);
+};
+
+extern const struct ip6_tnl_encap_ops __rcu *
+ ip6tun_encaps[MAX_IPTUN_ENCAP_OPS];
+
+int ip6_tnl_encap_add_ops(const struct ip6_tnl_encap_ops *op,
+ unsigned int num);
+int ip6_tnl_encap_del_ops(const struct ip6_tnl_encap_ops *op,
+ unsigned int num);
+
/* IPv6 tunnel */
struct ip6_tnl {
struct ip6_tnl __rcu *next; /* next tunnel in list */
diff --git a/net/ipv6/Makefile b/net/ipv6/Makefile
index 5e9d6bf..5cf4a1f 100644
--- a/net/ipv6/Makefile
+++ b/net/ipv6/Makefile
@@ -9,7 +9,7 @@ ipv6-objs := af_inet6.o anycast.o ip6_output.o ip6_input.o addrconf.o \
route.o ip6_fib.o ipv6_sockglue.o ndisc.o udp.o udplite.o \
raw.o icmp.o mcast.o reassembly.o tcp_ipv6.o ping.o \
exthdrs.o datagram.o ip6_flowlabel.o inet6_connection_sock.o \
- udp_offload.o
+ udp_offload.o ip6_tunnel_core.o
ipv6-offload := ip6_offload.o tcpv6_offload.o exthdrs_offload.o
@@ -43,6 +43,8 @@ obj-$(CONFIG_IPV6_SIT) += sit.o
obj-$(CONFIG_IPV6_TUNNEL) += ip6_tunnel.o
obj-$(CONFIG_IPV6_GRE) += ip6_gre.o
+obj-$(CONFIG_NET_FOU) += fou6.o
+
obj-y += addrconf_core.o exthdrs_core.o ip6_checksum.o ip6_icmp.o
obj-$(CONFIG_INET) += output_core.o protocol.o $(ipv6-offload)
diff --git a/net/ipv6/fou6.c b/net/ipv6/fou6.c
new file mode 100644
index 0000000..c972d0b
--- /dev/null
+++ b/net/ipv6/fou6.c
@@ -0,0 +1,140 @@
+#include <linux/module.h>
+#include <linux/errno.h>
+#include <linux/socket.h>
+#include <linux/skbuff.h>
+#include <linux/ip.h>
+#include <linux/udp.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <net/fou.h>
+#include <net/ip.h>
+#include <net/ip6_tunnel.h>
+#include <net/ip6_checksum.h>
+#include <net/protocol.h>
+#include <net/udp.h>
+#include <net/udp_tunnel.h>
+
+static void fou6_build_udp(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ struct flowi6 *fl6, u8 *protocol, __be16 sport)
+{
+ struct udphdr *uh;
+
+ skb_push(skb, sizeof(struct udphdr));
+ skb_reset_transport_header(skb);
+
+ uh = udp_hdr(skb);
+
+ uh->dest = e->dport;
+ uh->source = sport;
+ uh->len = htons(skb->len);
+ udp6_set_csum(!(e->flags & TUNNEL_ENCAP_FLAG_CSUM6), skb,
+ &fl6->saddr, &fl6->daddr, skb->len);
+
+ *protocol = IPPROTO_UDP;
+}
+
+int fou6_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ u8 *protocol, struct flowi6 *fl6)
+{
+ __be16 sport;
+ int err;
+ int type = e->flags & TUNNEL_ENCAP_FLAG_CSUM6 ?
+ SKB_GSO_UDP_TUNNEL_CSUM : SKB_GSO_UDP_TUNNEL;
+
+ err = __fou_build_header(skb, e, protocol, &sport, type);
+ if (err)
+ return err;
+
+ fou6_build_udp(skb, e, fl6, protocol, sport);
+
+ return 0;
+}
+EXPORT_SYMBOL(fou6_build_header);
+
+int gue6_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ u8 *protocol, struct flowi6 *fl6)
+{
+ __be16 sport;
+ int err;
+ int type = e->flags & TUNNEL_ENCAP_FLAG_CSUM6 ?
+ SKB_GSO_UDP_TUNNEL_CSUM : SKB_GSO_UDP_TUNNEL;
+
+ err = __gue_build_header(skb, e, protocol, &sport, type);
+ if (err)
+ return err;
+
+ fou6_build_udp(skb, e, fl6, protocol, sport);
+
+ return 0;
+}
+EXPORT_SYMBOL(gue6_build_header);
+
+#ifdef CONFIG_NET_FOU_IP_TUNNELS
+
+static const struct ip6_tnl_encap_ops fou_ip6tun_ops = {
+ .encap_hlen = fou_encap_hlen,
+ .build_header = fou6_build_header,
+};
+
+static const struct ip6_tnl_encap_ops gue_ip6tun_ops = {
+ .encap_hlen = gue_encap_hlen,
+ .build_header = gue6_build_header,
+};
+
+static int ip6_tnl_encap_add_fou_ops(void)
+{
+ int ret;
+
+ ret = ip6_tnl_encap_add_ops(&fou_ip6tun_ops, TUNNEL_ENCAP_FOU);
+ if (ret < 0) {
+ pr_err("can't add fou6 ops\n");
+ return ret;
+ }
+
+ ret = ip6_tnl_encap_add_ops(&gue_ip6tun_ops, TUNNEL_ENCAP_GUE);
+ if (ret < 0) {
+ pr_err("can't add gue6 ops\n");
+ ip6_tnl_encap_del_ops(&fou_ip6tun_ops, TUNNEL_ENCAP_FOU);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void ip6_tnl_encap_del_fou_ops(void)
+{
+ ip6_tnl_encap_del_ops(&fou_ip6tun_ops, TUNNEL_ENCAP_FOU);
+ ip6_tnl_encap_del_ops(&gue_ip6tun_ops, TUNNEL_ENCAP_GUE);
+}
+
+#else
+
+static int ip6_tnl_encap_add_fou_ops(void)
+{
+ return 0;
+}
+
+static void ip6_tnl_encap_del_fou_ops(void)
+{
+}
+
+#endif
+
+static int __init fou6_init(void)
+{
+ int ret;
+
+ ret = ip6_tnl_encap_add_fou_ops();
+
+ return ret;
+}
+
+static void __exit fou6_fini(void)
+{
+ ip6_tnl_encap_del_fou_ops();
+}
+
+module_init(fou6_init);
+module_exit(fou6_fini);
+MODULE_AUTHOR("Tom Herbert <therbert@google.com>");
+MODULE_LICENSE("GPL");
diff --git a/net/ipv6/ip6_tunnel_core.c b/net/ipv6/ip6_tunnel_core.c
new file mode 100644
index 0000000..5f5b79e
--- /dev/null
+++ b/net/ipv6/ip6_tunnel_core.c
@@ -0,0 +1,44 @@
+#include <linux/module.h>
+#include <linux/errno.h>
+#include <linux/types.h>
+#include <linux/if.h>
+#include <linux/in.h>
+#include <linux/ip.h>
+#include <linux/net.h>
+#include <linux/in6.h>
+#include <net/ip6_tunnel.h>
+
+const struct ip6_tnl_encap_ops __rcu *
+ ip6tun_encaps[MAX_IPTUN_ENCAP_OPS] __read_mostly;
+EXPORT_SYMBOL(ip6tun_encaps);
+
+int ip6_tnl_encap_add_ops(const struct ip6_tnl_encap_ops *ops,
+ unsigned int num)
+{
+ if (num >= MAX_IPTUN_ENCAP_OPS)
+ return -ERANGE;
+
+ return !cmpxchg((const struct ip6_tnl_encap_ops **)
+ &ip6tun_encaps[num],
+ NULL, ops) ? 0 : -1;
+}
+EXPORT_SYMBOL(ip6_tnl_encap_add_ops);
+
+int ip6_tnl_encap_del_ops(const struct ip6_tnl_encap_ops *ops,
+ unsigned int num)
+{
+ int ret;
+
+ if (num >= MAX_IPTUN_ENCAP_OPS)
+ return -ERANGE;
+
+ ret = (cmpxchg((const struct ip6_tnl_encap_ops **)
+ &ip6tun_encaps[num],
+ ops, NULL) == ops) ? 0 : -1;
+
+ synchronize_net();
+
+ return ret;
+}
+EXPORT_SYMBOL(ip6_tnl_encap_del_ops);
+
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 07/11] ipv6: Fix nexthdr for reinjection
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
` (5 preceding siblings ...)
2016-05-06 22:12 ` [PATCH v3 net-next 06/11] fou: Add encap ops for IPv6 tunnels Tom Herbert
@ 2016-05-06 22:12 ` Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 08/11] ipv6: Change "final" protocol processing for encapsulation Tom Herbert
` (4 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:12 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
In ip6_input_finish the protocol handle returns a value greater than
zero the packet needs to be resubmitted using the returned protocol.
The returned protocol is being ignored and each time through resubmit
nexthdr is taken from an offest in the packet. This patch fixes that
so that nexthdr is taken from return value of the protocol handler.
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
net/ipv6/ip6_input.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 6ed5601..2a0258a 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -222,13 +222,14 @@ static int ip6_input_finish(struct net *net, struct sock *sk, struct sk_buff *sk
*/
rcu_read_lock();
-resubmit:
+
idev = ip6_dst_idev(skb_dst(skb));
if (!pskb_pull(skb, skb_transport_offset(skb)))
goto discard;
nhoff = IP6CB(skb)->nhoff;
nexthdr = skb_network_header(skb)[nhoff];
+resubmit:
raw = raw6_local_deliver(skb, nexthdr);
ipprot = rcu_dereference(inet6_protos[nexthdr]);
if (ipprot) {
@@ -256,10 +257,12 @@ resubmit:
goto discard;
ret = ipprot->handler(skb);
- if (ret > 0)
+ if (ret > 0) {
+ nexthdr = ret;
goto resubmit;
- else if (ret == 0)
+ } else if (ret == 0) {
__IP6_INC_STATS(net, idev, IPSTATS_MIB_INDELIVERS);
+ }
} else {
if (!raw) {
if (xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb)) {
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 08/11] ipv6: Change "final" protocol processing for encapsulation
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
` (6 preceding siblings ...)
2016-05-06 22:12 ` [PATCH v3 net-next 07/11] ipv6: Fix nexthdr for reinjection Tom Herbert
@ 2016-05-06 22:12 ` Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 09/11] fou: Support IPv6 in fou Tom Herbert
` (3 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:12 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
When performing foo-over-UDP, UDP are receveived processed by the
encapsulation header which returns another protocol to process.
This may result in processing two (or more) protocols in the
loop that are marked as INET6_PROTO_FINAL. The actions taken
for hitting a final protocol, in particular the skb_postpull_rcsum
can only be performed.
This patch set adds a check of a final protocol has been seen. The
rules are:
- If the final protocol has not been seen any protocol is processed
(final and non-final). In the case of a final protocol, the final
actions are taken (like the skb_postpull_rcsum)
- If a final protocol has been seen (e.g. an encapsulating UDP
header) then no further non-final protocols are allowed
(e.g. extension headers). For more final protocols the
final actions are not taken (e.g. skb_postpull_rcsum).
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
net/ipv6/ip6_input.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 2a0258a..7d98d01 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -216,6 +216,7 @@ static int ip6_input_finish(struct net *net, struct sock *sk, struct sk_buff *sk
unsigned int nhoff;
int nexthdr;
bool raw;
+ bool have_final = false;
/*
* Parse extension headers
@@ -235,9 +236,21 @@ resubmit:
if (ipprot) {
int ret;
- if (ipprot->flags & INET6_PROTO_FINAL) {
+ if (have_final) {
+ if (!(ipprot->flags & INET6_PROTO_FINAL)) {
+ /* Once we've seen a final protocol don't
+ * allow encapsulation on any non-final
+ * ones. This allows foo in UDP encapsulation
+ * to work.
+ */
+ goto discard;
+ }
+ } else if (ipprot->flags & INET6_PROTO_FINAL) {
const struct ipv6hdr *hdr;
+ /* Only do this once for first final protocol */
+ have_final = true;
+
/* Free reference early: we don't need it any more,
and it may hold ip_conntrack module loaded
indefinitely. */
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 09/11] fou: Support IPv6 in fou
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
` (7 preceding siblings ...)
2016-05-06 22:12 ` [PATCH v3 net-next 08/11] ipv6: Change "final" protocol processing for encapsulation Tom Herbert
@ 2016-05-06 22:12 ` Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 10/11] ip6_tun: Add infrastructure for doing encapsulation Tom Herbert
` (2 subsequent siblings)
11 siblings, 0 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:12 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
This patch adds receive path support for IPv6 with fou.
- Add address family to fou structure for open sockets. This supports
AF_INET and AF_INET6. Lookups for fou ports are performed on both the
port number and family.
- In fou and gue receive adjust tot_len in IPv4 header or payload_len
based on address family.
- Allow AF_INET6 in FOU_ATTR_AF netlink attribute.
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
net/ipv4/fou.c | 47 +++++++++++++++++++++++++++++++++++------------
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index 971c8c6..75db828 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -21,6 +21,7 @@ struct fou {
u8 protocol;
u8 flags;
__be16 port;
+ u8 family;
u16 type;
struct list_head list;
struct rcu_head rcu;
@@ -47,14 +48,17 @@ static inline struct fou *fou_from_sock(struct sock *sk)
return sk->sk_user_data;
}
-static int fou_recv_pull(struct sk_buff *skb, size_t len)
+static int fou_recv_pull(struct sk_buff *skb, struct fou *fou, size_t len)
{
- struct iphdr *iph = ip_hdr(skb);
-
/* Remove 'len' bytes from the packet (UDP header and
* FOU header if present).
*/
- iph->tot_len = htons(ntohs(iph->tot_len) - len);
+ if (fou->family == AF_INET)
+ ip_hdr(skb)->tot_len = htons(ntohs(ip_hdr(skb)->tot_len) - len);
+ else
+ ipv6_hdr(skb)->payload_len =
+ htons(ntohs(ipv6_hdr(skb)->payload_len) - len);
+
__skb_pull(skb, len);
skb_postpull_rcsum(skb, udp_hdr(skb), len);
skb_reset_transport_header(skb);
@@ -68,7 +72,7 @@ static int fou_udp_recv(struct sock *sk, struct sk_buff *skb)
if (!fou)
return 1;
- if (fou_recv_pull(skb, sizeof(struct udphdr)))
+ if (fou_recv_pull(skb, fou, sizeof(struct udphdr)))
goto drop;
return -fou->protocol;
@@ -141,7 +145,11 @@ static int gue_udp_recv(struct sock *sk, struct sk_buff *skb)
hdrlen = sizeof(struct guehdr) + optlen;
- ip_hdr(skb)->tot_len = htons(ntohs(ip_hdr(skb)->tot_len) - len);
+ if (fou->family == AF_INET)
+ ip_hdr(skb)->tot_len = htons(ntohs(ip_hdr(skb)->tot_len) - len);
+ else
+ ipv6_hdr(skb)->payload_len =
+ htons(ntohs(ipv6_hdr(skb)->payload_len) - len);
/* Pull csum through the guehdr now . This can be used if
* there is a remote checksum offload.
@@ -424,7 +432,8 @@ static int fou_add_to_port_list(struct net *net, struct fou *fou)
mutex_lock(&fn->fou_lock);
list_for_each_entry(fout, &fn->fou_list, list) {
- if (fou->port == fout->port) {
+ if (fou->port == fout->port &&
+ fou->family == fout->family) {
mutex_unlock(&fn->fou_lock);
return -EALREADY;
}
@@ -469,8 +478,9 @@ static int fou_create(struct net *net, struct fou_cfg *cfg,
sk = sock->sk;
- fou->flags = cfg->flags;
fou->port = cfg->udp_config.local_udp_port;
+ fou->family = cfg->udp_config.family;
+ fou->flags = cfg->flags;
fou->type = cfg->type;
fou->sock = sock;
@@ -522,12 +532,13 @@ static int fou_destroy(struct net *net, struct fou_cfg *cfg)
{
struct fou_net *fn = net_generic(net, fou_net_id);
__be16 port = cfg->udp_config.local_udp_port;
+ u8 family = cfg->udp_config.family;
int err = -EINVAL;
struct fou *fou;
mutex_lock(&fn->fou_lock);
list_for_each_entry(fou, &fn->fou_list, list) {
- if (fou->port == port) {
+ if (fou->port == port && fou->family == family) {
fou_release(fou);
err = 0;
break;
@@ -565,8 +576,15 @@ static int parse_nl_config(struct genl_info *info,
if (info->attrs[FOU_ATTR_AF]) {
u8 family = nla_get_u8(info->attrs[FOU_ATTR_AF]);
- if (family != AF_INET)
- return -EINVAL;
+ switch (family) {
+ case AF_INET:
+ break;
+ case AF_INET6:
+ cfg->udp_config.ipv6_v6only = 1;
+ break;
+ default:
+ return -EAFNOSUPPORT;
+ }
cfg->udp_config.family = family;
}
@@ -657,6 +675,7 @@ static int fou_nl_cmd_get_port(struct sk_buff *skb, struct genl_info *info)
struct fou_cfg cfg;
struct fou *fout;
__be16 port;
+ u8 family;
int ret;
ret = parse_nl_config(info, &cfg);
@@ -666,6 +685,10 @@ static int fou_nl_cmd_get_port(struct sk_buff *skb, struct genl_info *info)
if (port == 0)
return -EINVAL;
+ family = cfg.udp_config.family;
+ if (family != AF_INET && family != AF_INET6)
+ return -EINVAL;
+
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!msg)
return -ENOMEM;
@@ -673,7 +696,7 @@ static int fou_nl_cmd_get_port(struct sk_buff *skb, struct genl_info *info)
ret = -ESRCH;
mutex_lock(&fn->fou_lock);
list_for_each_entry(fout, &fn->fou_list, list) {
- if (port == fout->port) {
+ if (port == fout->port && family == fout->family) {
ret = fou_dump_info(fout, info->snd_portid,
info->snd_seq, 0, msg,
info->genlhdr->cmd);
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 10/11] ip6_tun: Add infrastructure for doing encapsulation
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
` (8 preceding siblings ...)
2016-05-06 22:12 ` [PATCH v3 net-next 09/11] fou: Support IPv6 in fou Tom Herbert
@ 2016-05-06 22:12 ` Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 11/11] ip6_gre: Add support for fou/gue encapsulation Tom Herbert
2016-05-07 1:09 ` [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Alexander Duyck
11 siblings, 0 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:12 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
Add encap_hlen and ip_tunnel_encap structure to ip6_tnl. Add functions
for getting encap hlen, setting up encap on a tunnel, performing
encapsulation operation.
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
include/net/ip6_tunnel.h | 8 +++++-
net/ipv6/ip6_tunnel.c | 4 +++
net/ipv6/ip6_tunnel_core.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/include/net/ip6_tunnel.h b/include/net/ip6_tunnel.h
index 1c14c27..1b8db86 100644
--- a/include/net/ip6_tunnel.h
+++ b/include/net/ip6_tunnel.h
@@ -66,10 +66,16 @@ struct ip6_tnl {
__u32 o_seqno; /* The last output seqno */
int hlen; /* tun_hlen + encap_hlen */
int tun_hlen; /* Precalculated header length */
+ int encap_hlen; /* Encap header length (FOU,GUE) */
+ struct ip_tunnel_encap encap;
int mlink;
-
};
+int ip6_tnl_encap_setup(struct ip6_tnl *t,
+ struct ip_tunnel_encap *ipencap);
+int ip6_tnl_encap(struct sk_buff *skb, struct ip6_tnl *t,
+ u8 *protocol, struct flowi6 *fl6);
+
/* Tunnel encapsulation limit destination sub-option */
struct ipv6_tlv_tnl_enc_lim {
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index ade55af..2c096ab 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1013,6 +1013,10 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
unsigned int max_headroom = sizeof(struct ipv6hdr);
int err = -1;
+ err = ip6_tnl_encap(skb, t, &proto, fl6);
+ if (err)
+ return err;
+
/* NBMA tunnel */
if (ipv6_addr_any(&t->parms.raddr)) {
struct in6_addr *addr6;
diff --git a/net/ipv6/ip6_tunnel_core.c b/net/ipv6/ip6_tunnel_core.c
index 5f5b79e..94aa414 100644
--- a/net/ipv6/ip6_tunnel_core.c
+++ b/net/ipv6/ip6_tunnel_core.c
@@ -42,3 +42,67 @@ int ip6_tnl_encap_del_ops(const struct ip6_tnl_encap_ops *ops,
}
EXPORT_SYMBOL(ip6_tnl_encap_del_ops);
+static int ip6_encap_hlen(struct ip_tunnel_encap *e)
+{
+ const struct ip6_tnl_encap_ops *ops;
+ int hlen = -EINVAL;
+
+ if (e->type == TUNNEL_ENCAP_NONE)
+ return 0;
+
+ if (e->type >= MAX_IPTUN_ENCAP_OPS)
+ return -EINVAL;
+
+ rcu_read_lock();
+ ops = rcu_dereference(ip6tun_encaps[e->type]);
+ if (likely(ops && ops->encap_hlen))
+ hlen = ops->encap_hlen(e);
+ rcu_read_unlock();
+
+ return hlen;
+}
+
+int ip6_tnl_encap_setup(struct ip6_tnl *t,
+ struct ip_tunnel_encap *ipencap)
+{
+ int hlen;
+
+ memset(&t->encap, 0, sizeof(t->encap));
+
+ hlen = ip6_encap_hlen(ipencap);
+ if (hlen < 0)
+ return hlen;
+
+ t->encap.type = ipencap->type;
+ t->encap.sport = ipencap->sport;
+ t->encap.dport = ipencap->dport;
+ t->encap.flags = ipencap->flags;
+
+ t->encap_hlen = hlen;
+ t->hlen = t->encap_hlen + t->tun_hlen;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ip6_tnl_encap_setup);
+
+int ip6_tnl_encap(struct sk_buff *skb, struct ip6_tnl *t,
+ u8 *protocol, struct flowi6 *fl6)
+{
+ const struct ip6_tnl_encap_ops *ops;
+ int ret = -EINVAL;
+
+ if (t->encap.type == TUNNEL_ENCAP_NONE)
+ return 0;
+
+ if (t->encap.type >= MAX_IPTUN_ENCAP_OPS)
+ return -EINVAL;
+
+ rcu_read_lock();
+ ops = rcu_dereference(ip6tun_encaps[t->encap.type]);
+ if (likely(ops && ops->build_header))
+ ret = ops->build_header(skb, &t->encap, protocol, fl6);
+ rcu_read_unlock();
+
+ return ret;
+}
+EXPORT_SYMBOL(ip6_tnl_encap);
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH v3 net-next 11/11] ip6_gre: Add support for fou/gue encapsulation
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
` (9 preceding siblings ...)
2016-05-06 22:12 ` [PATCH v3 net-next 10/11] ip6_tun: Add infrastructure for doing encapsulation Tom Herbert
@ 2016-05-06 22:12 ` Tom Herbert
2016-05-07 1:09 ` [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Alexander Duyck
11 siblings, 0 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:12 UTC (permalink / raw)
To: davem, netdev; +Cc: kernel-team
Add netlink and setup for encapsulation
Signed-off-by: Tom Herbert <tom@herbertland.com>
---
net/ipv6/ip6_gre.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 75 insertions(+)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 70a1f72..ed5ddcc 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1027,6 +1027,8 @@ static int ip6gre_tunnel_init_common(struct net_device *dev)
tunnel->tun_hlen = gre_calc_hlen(tunnel->parms.o_flags);
+ tunnel->hlen = tunnel->tun_hlen + tunnel->encap_hlen;
+
t_hlen = tunnel->hlen + sizeof(struct ipv6hdr);
dev->needed_headroom = LL_MAX_HEADER + t_hlen + 4;
@@ -1293,15 +1295,57 @@ static void ip6gre_tap_setup(struct net_device *dev)
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
}
+static bool ip6gre_netlink_encap_parms(struct nlattr *data[],
+ struct ip_tunnel_encap *ipencap)
+{
+ bool ret = false;
+
+ memset(ipencap, 0, sizeof(*ipencap));
+
+ if (!data)
+ return ret;
+
+ if (data[IFLA_GRE_ENCAP_TYPE]) {
+ ret = true;
+ ipencap->type = nla_get_u16(data[IFLA_GRE_ENCAP_TYPE]);
+ }
+
+ if (data[IFLA_GRE_ENCAP_FLAGS]) {
+ ret = true;
+ ipencap->flags = nla_get_u16(data[IFLA_GRE_ENCAP_FLAGS]);
+ }
+
+ if (data[IFLA_GRE_ENCAP_SPORT]) {
+ ret = true;
+ ipencap->sport = nla_get_be16(data[IFLA_GRE_ENCAP_SPORT]);
+ }
+
+ if (data[IFLA_GRE_ENCAP_DPORT]) {
+ ret = true;
+ ipencap->dport = nla_get_be16(data[IFLA_GRE_ENCAP_DPORT]);
+ }
+
+ return ret;
+}
+
static int ip6gre_newlink(struct net *src_net, struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
{
struct ip6_tnl *nt;
struct net *net = dev_net(dev);
struct ip6gre_net *ign = net_generic(net, ip6gre_net_id);
+ struct ip_tunnel_encap ipencap;
int err;
nt = netdev_priv(dev);
+
+ if (ip6gre_netlink_encap_parms(data, &ipencap)) {
+ int err = ip6_tnl_encap_setup(nt, &ipencap);
+
+ if (err < 0)
+ return err;
+ }
+
ip6gre_netlink_parms(data, &nt->parms);
if (ip6gre_tunnel_find(net, &nt->parms, dev->type))
@@ -1348,10 +1392,18 @@ static int ip6gre_changelink(struct net_device *dev, struct nlattr *tb[],
struct net *net = nt->net;
struct ip6gre_net *ign = net_generic(net, ip6gre_net_id);
struct __ip6_tnl_parm p;
+ struct ip_tunnel_encap ipencap;
if (dev == ign->fb_tunnel_dev)
return -EINVAL;
+ if (ip6gre_netlink_encap_parms(data, &ipencap)) {
+ int err = ip6_tnl_encap_setup(nt, &ipencap);
+
+ if (err < 0)
+ return err;
+ }
+
ip6gre_netlink_parms(data, &p);
t = ip6gre_tunnel_locate(net, &p, 0);
@@ -1405,6 +1457,14 @@ static size_t ip6gre_get_size(const struct net_device *dev)
nla_total_size(4) +
/* IFLA_GRE_FLAGS */
nla_total_size(4) +
+ /* IFLA_GRE_ENCAP_TYPE */
+ nla_total_size(2) +
+ /* IFLA_GRE_ENCAP_FLAGS */
+ nla_total_size(2) +
+ /* IFLA_GRE_ENCAP_SPORT */
+ nla_total_size(2) +
+ /* IFLA_GRE_ENCAP_DPORT */
+ nla_total_size(2) +
0;
}
@@ -1428,6 +1488,17 @@ static int ip6gre_fill_info(struct sk_buff *skb, const struct net_device *dev)
nla_put_be32(skb, IFLA_GRE_FLOWINFO, p->flowinfo) ||
nla_put_u32(skb, IFLA_GRE_FLAGS, p->flags))
goto nla_put_failure;
+
+ if (nla_put_u16(skb, IFLA_GRE_ENCAP_TYPE,
+ t->encap.type) ||
+ nla_put_be16(skb, IFLA_GRE_ENCAP_SPORT,
+ t->encap.sport) ||
+ nla_put_be16(skb, IFLA_GRE_ENCAP_DPORT,
+ t->encap.dport) ||
+ nla_put_u16(skb, IFLA_GRE_ENCAP_FLAGS,
+ t->encap.flags))
+ goto nla_put_failure;
+
return 0;
nla_put_failure:
@@ -1446,6 +1517,10 @@ static const struct nla_policy ip6gre_policy[IFLA_GRE_MAX + 1] = {
[IFLA_GRE_ENCAP_LIMIT] = { .type = NLA_U8 },
[IFLA_GRE_FLOWINFO] = { .type = NLA_U32 },
[IFLA_GRE_FLAGS] = { .type = NLA_U32 },
+ [IFLA_GRE_ENCAP_TYPE] = { .type = NLA_U16 },
+ [IFLA_GRE_ENCAP_FLAGS] = { .type = NLA_U16 },
+ [IFLA_GRE_ENCAP_SPORT] = { .type = NLA_U16 },
+ [IFLA_GRE_ENCAP_DPORT] = { .type = NLA_U16 },
};
static struct rtnl_link_ops ip6gre_link_ops __read_mostly = {
--
2.8.0.rc2
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 01/11] gso: Remove arbitrary checks for unsupported GSO
2016-05-06 22:11 ` [PATCH v3 net-next 01/11] gso: Remove arbitrary checks for unsupported GSO Tom Herbert
@ 2016-05-06 22:34 ` Alexander Duyck
2016-05-07 2:44 ` Alexander Duyck
1 sibling, 0 replies; 26+ messages in thread
From: Alexander Duyck @ 2016-05-06 22:34 UTC (permalink / raw)
To: Tom Herbert, davem, netdev; +Cc: kernel-team
On 05/06/2016 03:11 PM, Tom Herbert wrote:
> In several gso_segment functions there are checks of gso_type against
> a seemingly arbitrary list of SKB_GSO_* flags. This seems like an
> attempt to identify unsupported GSO types, but since the stack is
> the one that set these GSO types in the first place this seems
> unnecessary to do. If a combination isn't valid in the first
> place that stack should not allow setting it.
>
> This is a code simplication especially for add new GSO types.
>
> Signed-off-by: Tom Herbert <tom@herbertland.com>
> ---
> net/ipv4/af_inet.c | 18 ------------------
> net/ipv4/gre_offload.c | 14 --------------
> net/ipv4/tcp_offload.c | 19 -------------------
> net/ipv4/udp_offload.c | 10 ----------
> net/ipv6/ip6_offload.c | 18 ------------------
> net/ipv6/udp_offload.c | 13 -------------
> net/mpls/mpls_gso.c | 9 ---------
> 7 files changed, 101 deletions(-)
>
This is a nice clean-up since tunnels have essentially made things like
trying to filter TSOV4 or TSOV6 pointless for the network layer.
Acked-by: Alexander Duyck <aduyck@mirantis.com>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 02/11] net: define gso types for IPx over IPv4 and IPv6
2016-05-06 22:11 ` [PATCH v3 net-next 02/11] net: define gso types for IPx over IPv4 and IPv6 Tom Herbert
@ 2016-05-06 22:48 ` Alexander Duyck
2016-05-06 22:55 ` Tom Herbert
0 siblings, 1 reply; 26+ messages in thread
From: Alexander Duyck @ 2016-05-06 22:48 UTC (permalink / raw)
To: Tom Herbert, davem, netdev; +Cc: kernel-team
On 05/06/2016 03:11 PM, Tom Herbert wrote:
> This patch defines two new GDO definitions SKB_GSO_IPXIP4 and
> SKB_GSO_IPXIP6 along with corresponding NETIF_F_GSO_IPXIP4 and
> NETIF_F_GSO_IPXIP6. These are used to described IP in IP
> tunnel and what the outer protocol is. The inner protocol
> can be deduced from other GSO types (e.g. SKB_GSO_TCPV4 and
> SKB_GSO_TCPV6). The GSO types of SKB_GSO_IPIP and SKB_GSO_SIT
> are removed (these are both instances of SKB_GSO_IPXIP4).
> SKB_GSO_IPXIP6 will be used when support for GSO with IP
> encapsulation over IPv6 is added.
>
> Signed-off-by: Tom Herbert <tom@herbertland.com>
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 5 ++---
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 ++--
> drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +--
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 3 +--
> drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 3 +--
> drivers/net/ethernet/intel/i40evf/i40evf_main.c | 3 +--
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +--
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 3 +--
> include/linux/netdev_features.h | 12 ++++++------
> include/linux/netdevice.h | 4 ++--
> include/linux/skbuff.h | 4 ++--
> net/core/ethtool.c | 4 ++--
> net/ipv4/af_inet.c | 2 +-
> net/ipv4/ipip.c | 2 +-
> net/ipv6/ip6_offload.c | 4 ++--
> net/ipv6/sit.c | 4 ++--
> net/netfilter/ipvs/ip_vs_xmit.c | 17 +++++++----------
> 17 files changed, 35 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> index d465bd7..0a5b770 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> @@ -13259,12 +13259,11 @@ static int bnx2x_init_dev(struct bnx2x *bp, struct pci_dev *pdev,
> NETIF_F_RXHASH | NETIF_F_HW_VLAN_CTAG_TX;
> if (!chip_is_e1x) {
> dev->hw_features |= NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL |
> - NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT;
> + NETIF_F_GSO_IPXIP4;
> dev->hw_enc_features =
> NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_SG |
> NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 |
> - NETIF_F_GSO_IPIP |
> - NETIF_F_GSO_SIT |
> + NETIF_F_GSO_IPXIP4 |
> NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL;
> }
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index fd85b6d..e449228 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> @@ -6218,7 +6218,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_SG |
> NETIF_F_TSO | NETIF_F_TSO6 |
> NETIF_F_GSO_UDP_TUNNEL | NETIF_F_GSO_GRE |
> - NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT |
> + NETIF_F_GSO_IPXIP4 |
> NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_GSO_GRE_CSUM |
> NETIF_F_GSO_PARTIAL | NETIF_F_RXHASH |
> NETIF_F_RXCSUM | NETIF_F_LRO | NETIF_F_GRO;
> @@ -6228,7 +6228,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> NETIF_F_TSO | NETIF_F_TSO6 |
> NETIF_F_GSO_UDP_TUNNEL | NETIF_F_GSO_GRE |
> NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_GSO_GRE_CSUM |
> - NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT |
> + NETIF_F_GSO_IPXIP4;
> NETIF_F_GSO_PARTIAL;
> dev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM |
> NETIF_F_GSO_GRE_CSUM;
You should try building the bnxt driver at least if you are making
changes to it. This bit is broken. It should be an '|' and not a ';' here.
The other bits seem to be correct. I'll try testing this over the next
few hours to see if I can find any other issues.
- Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 02/11] net: define gso types for IPx over IPv4 and IPv6
2016-05-06 22:48 ` Alexander Duyck
@ 2016-05-06 22:55 ` Tom Herbert
0 siblings, 0 replies; 26+ messages in thread
From: Tom Herbert @ 2016-05-06 22:55 UTC (permalink / raw)
To: Alexander Duyck
Cc: David S. Miller, Linux Kernel Network Developers, Kernel Team
On Fri, May 6, 2016 at 3:48 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On 05/06/2016 03:11 PM, Tom Herbert wrote:
>>
>> This patch defines two new GDO definitions SKB_GSO_IPXIP4 and
>> SKB_GSO_IPXIP6 along with corresponding NETIF_F_GSO_IPXIP4 and
>> NETIF_F_GSO_IPXIP6. These are used to described IP in IP
>> tunnel and what the outer protocol is. The inner protocol
>> can be deduced from other GSO types (e.g. SKB_GSO_TCPV4 and
>> SKB_GSO_TCPV6). The GSO types of SKB_GSO_IPIP and SKB_GSO_SIT
>> are removed (these are both instances of SKB_GSO_IPXIP4).
>> SKB_GSO_IPXIP6 will be used when support for GSO with IP
>> encapsulation over IPv6 is added.
>>
>> Signed-off-by: Tom Herbert <tom@herbertland.com>
>> ---
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 5 ++---
>> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 ++--
>> drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +--
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 3 +--
>> drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 3 +--
>> drivers/net/ethernet/intel/i40evf/i40evf_main.c | 3 +--
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +--
>> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 3 +--
>> include/linux/netdev_features.h | 12 ++++++------
>> include/linux/netdevice.h | 4 ++--
>> include/linux/skbuff.h | 4 ++--
>> net/core/ethtool.c | 4 ++--
>> net/ipv4/af_inet.c | 2 +-
>> net/ipv4/ipip.c | 2 +-
>> net/ipv6/ip6_offload.c | 4 ++--
>> net/ipv6/sit.c | 4 ++--
>> net/netfilter/ipvs/ip_vs_xmit.c | 17 +++++++----------
>> 17 files changed, 35 insertions(+), 45 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>> index d465bd7..0a5b770 100644
>> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>> @@ -13259,12 +13259,11 @@ static int bnx2x_init_dev(struct bnx2x *bp,
>> struct pci_dev *pdev,
>> NETIF_F_RXHASH | NETIF_F_HW_VLAN_CTAG_TX;
>> if (!chip_is_e1x) {
>> dev->hw_features |= NETIF_F_GSO_GRE |
>> NETIF_F_GSO_UDP_TUNNEL |
>> - NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT;
>> + NETIF_F_GSO_IPXIP4;
>> dev->hw_enc_features =
>> NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_SG |
>> NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 |
>> - NETIF_F_GSO_IPIP |
>> - NETIF_F_GSO_SIT |
>> + NETIF_F_GSO_IPXIP4 |
>> NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL;
>> }
>>
>> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> index fd85b6d..e449228 100644
>> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> @@ -6218,7 +6218,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const
>> struct pci_device_id *ent)
>> dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
>> NETIF_F_SG |
>> NETIF_F_TSO | NETIF_F_TSO6 |
>> NETIF_F_GSO_UDP_TUNNEL | NETIF_F_GSO_GRE |
>> - NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT |
>> + NETIF_F_GSO_IPXIP4 |
>> NETIF_F_GSO_UDP_TUNNEL_CSUM |
>> NETIF_F_GSO_GRE_CSUM |
>> NETIF_F_GSO_PARTIAL | NETIF_F_RXHASH |
>> NETIF_F_RXCSUM | NETIF_F_LRO | NETIF_F_GRO;
>> @@ -6228,7 +6228,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const
>> struct pci_device_id *ent)
>> NETIF_F_TSO | NETIF_F_TSO6 |
>> NETIF_F_GSO_UDP_TUNNEL | NETIF_F_GSO_GRE |
>> NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_GSO_GRE_CSUM
>> |
>> - NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT |
>> + NETIF_F_GSO_IPXIP4;
>> NETIF_F_GSO_PARTIAL;
>> dev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM |
>> NETIF_F_GSO_GRE_CSUM;
>
>
> You should try building the bnxt driver at least if you are making changes
> to it. This bit is broken. It should be an '|' and not a ';' here.
>
> The other bits seem to be correct. I'll try testing this over the next few
> hours to see if I can find any other issues.
Huh, that's odd. I'm pretty sure I built drivers/net with allyesconfig
with this.
Thanks for catching it.
>
> - Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
` (10 preceding siblings ...)
2016-05-06 22:12 ` [PATCH v3 net-next 11/11] ip6_gre: Add support for fou/gue encapsulation Tom Herbert
@ 2016-05-07 1:09 ` Alexander Duyck
2016-05-07 1:57 ` Tom Herbert
11 siblings, 1 reply; 26+ messages in thread
From: Alexander Duyck @ 2016-05-07 1:09 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
> This patch set:
> - Fixes GRE6 to process translate flags correctly from configuration
> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
> - Add support for FOU and GUE in IPv6
> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
> - Fixes ip6_input to deal with UDP encapsulations
> - Some other minor fixes
>
> v2:
> - Removed a check of GSO types in MPLS
> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
> from Alexander)
> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
> fix makes that uncessary
> - Don't bother clearing encapsulation flag in UDP tunnel segment
> (another item suggested by Alexander).
>
> v3:
> - Address some minor comments from Alexander
>
> Tested:
> Tested a variety of case, but not the full matrix (which is quite
> large now). Most of the obivous cases (e.g. GRE) work fine. Still
> some issues probably with GSO/GRO being effective in all cases.
>
> - IPv4/GRE/GUE/IPv6 with RCO
> 1 TCP_STREAM
> 6616 Mbps
> 200 TCP_RR
> 1244043 tps
> 141/243/446 90/95/99% latencies
> 86.61% CPU utilization
> - IPv6/GRE/GUE/IPv6 with RCO
> 1 TCP_STREAM
> 6940 Mbps
> 200 TCP_RR
> 1270903 tps
> 138/236/440 90/95/99% latencies
> 87.51% CPU utilization
>
> - IP6IP6
> 1 TCP_STREAM
> 2576 Mbps
> 200 TCP_RR
> 498981 tps
> 388/498/631 90/95/99% latencies
> 19.75% CPU utilization (1 CPU saturated)
>
> - IP6IP6/GUE/IPv6 with RCO
> 1 TCP_STREAM
> 1854 Mbps
> 200 TCP_RR
> 1233818 tps
> 143/244/451 90/95/99% latencies
> 87.57 CPU utilization
>
> - IP4IP6
> 1 TCP_STREAM
> 200 TCP_RR
> 763774 tps
> 250/318/466 90/95/99% latencies
> 35.25% CPU utilization (1 CPU saturated)
>
> - GRE with keyid
> 200 TCP_RR
> 744173 tps
> 258/332/461 90/95/99% latencies
> 34.59% CPU utilization (1 CPU saturated)
So I tried testing your patch set and it looks like I cannot get GRE
working for any netperf test. If I pop the patches off it is even
worse since it looks like patch 3 fixes some tunnel flags issues, but
still doesn't resolve all the issues introduced with b05229f44228
("gre6: Cleanup GREv6 transmit path, call common GRE functions").
Reverting the entire patch seems to resolve the issues, but I will try
to pick it apart tonight to see if I can find the other issues that
weren't addressed in this patch series.
- Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
2016-05-07 1:09 ` [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Alexander Duyck
@ 2016-05-07 1:57 ` Tom Herbert
2016-05-07 2:03 ` Alexander Duyck
0 siblings, 1 reply; 26+ messages in thread
From: Tom Herbert @ 2016-05-07 1:57 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, Netdev, Kernel Team
On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>> This patch set:
>> - Fixes GRE6 to process translate flags correctly from configuration
>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>> - Add support for FOU and GUE in IPv6
>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>> - Fixes ip6_input to deal with UDP encapsulations
>> - Some other minor fixes
>>
>> v2:
>> - Removed a check of GSO types in MPLS
>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>> from Alexander)
>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>> fix makes that uncessary
>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>> (another item suggested by Alexander).
>>
>> v3:
>> - Address some minor comments from Alexander
>>
>> Tested:
>> Tested a variety of case, but not the full matrix (which is quite
>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>> some issues probably with GSO/GRO being effective in all cases.
>>
>> - IPv4/GRE/GUE/IPv6 with RCO
>> 1 TCP_STREAM
>> 6616 Mbps
>> 200 TCP_RR
>> 1244043 tps
>> 141/243/446 90/95/99% latencies
>> 86.61% CPU utilization
>> - IPv6/GRE/GUE/IPv6 with RCO
>> 1 TCP_STREAM
>> 6940 Mbps
>> 200 TCP_RR
>> 1270903 tps
>> 138/236/440 90/95/99% latencies
>> 87.51% CPU utilization
>>
>> - IP6IP6
>> 1 TCP_STREAM
>> 2576 Mbps
>> 200 TCP_RR
>> 498981 tps
>> 388/498/631 90/95/99% latencies
>> 19.75% CPU utilization (1 CPU saturated)
>>
>> - IP6IP6/GUE/IPv6 with RCO
>> 1 TCP_STREAM
>> 1854 Mbps
>> 200 TCP_RR
>> 1233818 tps
>> 143/244/451 90/95/99% latencies
>> 87.57 CPU utilization
>>
>> - IP4IP6
>> 1 TCP_STREAM
>> 200 TCP_RR
>> 763774 tps
>> 250/318/466 90/95/99% latencies
>> 35.25% CPU utilization (1 CPU saturated)
>>
>> - GRE with keyid
>> 200 TCP_RR
>> 744173 tps
>> 258/332/461 90/95/99% latencies
>> 34.59% CPU utilization (1 CPU saturated)
>
> So I tried testing your patch set and it looks like I cannot get GRE
> working for any netperf test. If I pop the patches off it is even
> worse since it looks like patch 3 fixes some tunnel flags issues, but
> still doesn't resolve all the issues introduced with b05229f44228
> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
> Reverting the entire patch seems to resolve the issues, but I will try
> to pick it apart tonight to see if I can find the other issues that
> weren't addressed in this patch series.
>
Can you give details about configuration, test you're running, and HW?
> - Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
2016-05-07 1:57 ` Tom Herbert
@ 2016-05-07 2:03 ` Alexander Duyck
2016-05-07 2:11 ` Tom Herbert
0 siblings, 1 reply; 26+ messages in thread
From: Alexander Duyck @ 2016-05-07 2:03 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> This patch set:
>>> - Fixes GRE6 to process translate flags correctly from configuration
>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>> - Add support for FOU and GUE in IPv6
>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>> - Fixes ip6_input to deal with UDP encapsulations
>>> - Some other minor fixes
>>>
>>> v2:
>>> - Removed a check of GSO types in MPLS
>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>> from Alexander)
>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>> fix makes that uncessary
>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>> (another item suggested by Alexander).
>>>
>>> v3:
>>> - Address some minor comments from Alexander
>>>
>>> Tested:
>>> Tested a variety of case, but not the full matrix (which is quite
>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>> some issues probably with GSO/GRO being effective in all cases.
>>>
>>> - IPv4/GRE/GUE/IPv6 with RCO
>>> 1 TCP_STREAM
>>> 6616 Mbps
>>> 200 TCP_RR
>>> 1244043 tps
>>> 141/243/446 90/95/99% latencies
>>> 86.61% CPU utilization
>>> - IPv6/GRE/GUE/IPv6 with RCO
>>> 1 TCP_STREAM
>>> 6940 Mbps
>>> 200 TCP_RR
>>> 1270903 tps
>>> 138/236/440 90/95/99% latencies
>>> 87.51% CPU utilization
>>>
>>> - IP6IP6
>>> 1 TCP_STREAM
>>> 2576 Mbps
>>> 200 TCP_RR
>>> 498981 tps
>>> 388/498/631 90/95/99% latencies
>>> 19.75% CPU utilization (1 CPU saturated)
>>>
>>> - IP6IP6/GUE/IPv6 with RCO
>>> 1 TCP_STREAM
>>> 1854 Mbps
>>> 200 TCP_RR
>>> 1233818 tps
>>> 143/244/451 90/95/99% latencies
>>> 87.57 CPU utilization
>>>
>>> - IP4IP6
>>> 1 TCP_STREAM
>>> 200 TCP_RR
>>> 763774 tps
>>> 250/318/466 90/95/99% latencies
>>> 35.25% CPU utilization (1 CPU saturated)
>>>
>>> - GRE with keyid
>>> 200 TCP_RR
>>> 744173 tps
>>> 258/332/461 90/95/99% latencies
>>> 34.59% CPU utilization (1 CPU saturated)
>>
>> So I tried testing your patch set and it looks like I cannot get GRE
>> working for any netperf test. If I pop the patches off it is even
>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>> still doesn't resolve all the issues introduced with b05229f44228
>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>> Reverting the entire patch seems to resolve the issues, but I will try
>> to pick it apart tonight to see if I can find the other issues that
>> weren't addressed in this patch series.
>>
>
> Can you give details about configuration, test you're running, and HW?
The issue looks like it may be specific to ip6gretap. I'm running the
test over an i40e adapter, but it shouldn't make much difference. I'm
thinking it may have something to do with the MTU configuration as
that is one of the things I am noticing has changed between the
working and the broken version of the code.
- Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
2016-05-07 2:03 ` Alexander Duyck
@ 2016-05-07 2:11 ` Tom Herbert
2016-05-07 3:03 ` Alexander Duyck
0 siblings, 1 reply; 26+ messages in thread
From: Tom Herbert @ 2016-05-07 2:11 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, Netdev, Kernel Team
On Fri, May 6, 2016 at 7:03 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
>> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
>> <alexander.duyck@gmail.com> wrote:
>>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>> This patch set:
>>>> - Fixes GRE6 to process translate flags correctly from configuration
>>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>>> - Add support for FOU and GUE in IPv6
>>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>>> - Fixes ip6_input to deal with UDP encapsulations
>>>> - Some other minor fixes
>>>>
>>>> v2:
>>>> - Removed a check of GSO types in MPLS
>>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>>> from Alexander)
>>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>>> fix makes that uncessary
>>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>>> (another item suggested by Alexander).
>>>>
>>>> v3:
>>>> - Address some minor comments from Alexander
>>>>
>>>> Tested:
>>>> Tested a variety of case, but not the full matrix (which is quite
>>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>>> some issues probably with GSO/GRO being effective in all cases.
>>>>
>>>> - IPv4/GRE/GUE/IPv6 with RCO
>>>> 1 TCP_STREAM
>>>> 6616 Mbps
>>>> 200 TCP_RR
>>>> 1244043 tps
>>>> 141/243/446 90/95/99% latencies
>>>> 86.61% CPU utilization
>>>> - IPv6/GRE/GUE/IPv6 with RCO
>>>> 1 TCP_STREAM
>>>> 6940 Mbps
>>>> 200 TCP_RR
>>>> 1270903 tps
>>>> 138/236/440 90/95/99% latencies
>>>> 87.51% CPU utilization
>>>>
>>>> - IP6IP6
>>>> 1 TCP_STREAM
>>>> 2576 Mbps
>>>> 200 TCP_RR
>>>> 498981 tps
>>>> 388/498/631 90/95/99% latencies
>>>> 19.75% CPU utilization (1 CPU saturated)
>>>>
>>>> - IP6IP6/GUE/IPv6 with RCO
>>>> 1 TCP_STREAM
>>>> 1854 Mbps
>>>> 200 TCP_RR
>>>> 1233818 tps
>>>> 143/244/451 90/95/99% latencies
>>>> 87.57 CPU utilization
>>>>
>>>> - IP4IP6
>>>> 1 TCP_STREAM
>>>> 200 TCP_RR
>>>> 763774 tps
>>>> 250/318/466 90/95/99% latencies
>>>> 35.25% CPU utilization (1 CPU saturated)
>>>>
>>>> - GRE with keyid
>>>> 200 TCP_RR
>>>> 744173 tps
>>>> 258/332/461 90/95/99% latencies
>>>> 34.59% CPU utilization (1 CPU saturated)
>>>
>>> So I tried testing your patch set and it looks like I cannot get GRE
>>> working for any netperf test. If I pop the patches off it is even
>>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>>> still doesn't resolve all the issues introduced with b05229f44228
>>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>>> Reverting the entire patch seems to resolve the issues, but I will try
>>> to pick it apart tonight to see if I can find the other issues that
>>> weren't addressed in this patch series.
>>>
>>
>> Can you give details about configuration, test you're running, and HW?
>
> The issue looks like it may be specific to ip6gretap. I'm running the
> test over an i40e adapter, but it shouldn't make much difference. I'm
> thinking it may have something to do with the MTU configuration as
> that is one of the things I am noticing has changed between the
> working and the broken version of the code.
>
I'm not seeing any issue with configuring:
ip link add name tun8 type ip6gretap remote
2401:db00:20:911a:face:0:27:0 local 2401:db00:20:911a:face:0:25:0 ttl
225
MTU issues would not surprise me with IPv6 though. This is part of the
area of code that seems drastically different than what IPv4 is doing.
Tom
> - Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 01/11] gso: Remove arbitrary checks for unsupported GSO
2016-05-06 22:11 ` [PATCH v3 net-next 01/11] gso: Remove arbitrary checks for unsupported GSO Tom Herbert
2016-05-06 22:34 ` Alexander Duyck
@ 2016-05-07 2:44 ` Alexander Duyck
1 sibling, 0 replies; 26+ messages in thread
From: Alexander Duyck @ 2016-05-07 2:44 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
> diff --git a/net/mpls/mpls_gso.c b/net/mpls/mpls_gso.c
> index bbcf604..6de1e13 100644
> --- a/net/mpls/mpls_gso.c
> +++ b/net/mpls/mpls_gso.c
> @@ -26,15 +26,6 @@ static struct sk_buff *mpls_gso_segment(struct sk_buff *skb,
> netdev_features_t mpls_features;
> __be16 mpls_protocol;
>
> - if (unlikely(skb_shinfo(skb)->gso_type &
> - ~(SKB_GSO_TCPV4 |
> - SKB_GSO_TCPV6 |
> - SKB_GSO_UDP |
> - SKB_GSO_DODGY |
> - SKB_GSO_TCP_FIXEDID |
> - SKB_GSO_TCP_ECN)))
> - goto out;
> -
> /* Setup inner SKB. */
> mpls_protocol = skb->protocol;
> skb->protocol = skb->inner_protocol;
Actually I just noticed a build warning for this patch. I guess the
label out isn't used anywhere else so you should probably drop it for
the mpls_gso_segment function.
- Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
2016-05-07 2:11 ` Tom Herbert
@ 2016-05-07 3:03 ` Alexander Duyck
2016-05-09 16:56 ` Tom Herbert
0 siblings, 1 reply; 26+ messages in thread
From: Alexander Duyck @ 2016-05-07 3:03 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
On Fri, May 6, 2016 at 7:11 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Fri, May 6, 2016 at 7:03 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
>>> <alexander.duyck@gmail.com> wrote:
>>>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>> This patch set:
>>>>> - Fixes GRE6 to process translate flags correctly from configuration
>>>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>>>> - Add support for FOU and GUE in IPv6
>>>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>>>> - Fixes ip6_input to deal with UDP encapsulations
>>>>> - Some other minor fixes
>>>>>
>>>>> v2:
>>>>> - Removed a check of GSO types in MPLS
>>>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>>>> from Alexander)
>>>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>>>> fix makes that uncessary
>>>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>>>> (another item suggested by Alexander).
>>>>>
>>>>> v3:
>>>>> - Address some minor comments from Alexander
>>>>>
>>>>> Tested:
>>>>> Tested a variety of case, but not the full matrix (which is quite
>>>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>>>> some issues probably with GSO/GRO being effective in all cases.
>>>>>
>>>>> - IPv4/GRE/GUE/IPv6 with RCO
>>>>> 1 TCP_STREAM
>>>>> 6616 Mbps
>>>>> 200 TCP_RR
>>>>> 1244043 tps
>>>>> 141/243/446 90/95/99% latencies
>>>>> 86.61% CPU utilization
>>>>> - IPv6/GRE/GUE/IPv6 with RCO
>>>>> 1 TCP_STREAM
>>>>> 6940 Mbps
>>>>> 200 TCP_RR
>>>>> 1270903 tps
>>>>> 138/236/440 90/95/99% latencies
>>>>> 87.51% CPU utilization
>>>>>
>>>>> - IP6IP6
>>>>> 1 TCP_STREAM
>>>>> 2576 Mbps
>>>>> 200 TCP_RR
>>>>> 498981 tps
>>>>> 388/498/631 90/95/99% latencies
>>>>> 19.75% CPU utilization (1 CPU saturated)
>>>>>
>>>>> - IP6IP6/GUE/IPv6 with RCO
>>>>> 1 TCP_STREAM
>>>>> 1854 Mbps
>>>>> 200 TCP_RR
>>>>> 1233818 tps
>>>>> 143/244/451 90/95/99% latencies
>>>>> 87.57 CPU utilization
>>>>>
>>>>> - IP4IP6
>>>>> 1 TCP_STREAM
>>>>> 200 TCP_RR
>>>>> 763774 tps
>>>>> 250/318/466 90/95/99% latencies
>>>>> 35.25% CPU utilization (1 CPU saturated)
>>>>>
>>>>> - GRE with keyid
>>>>> 200 TCP_RR
>>>>> 744173 tps
>>>>> 258/332/461 90/95/99% latencies
>>>>> 34.59% CPU utilization (1 CPU saturated)
>>>>
>>>> So I tried testing your patch set and it looks like I cannot get GRE
>>>> working for any netperf test. If I pop the patches off it is even
>>>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>>>> still doesn't resolve all the issues introduced with b05229f44228
>>>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>>>> Reverting the entire patch seems to resolve the issues, but I will try
>>>> to pick it apart tonight to see if I can find the other issues that
>>>> weren't addressed in this patch series.
>>>>
>>>
>>> Can you give details about configuration, test you're running, and HW?
>>
>> The issue looks like it may be specific to ip6gretap. I'm running the
>> test over an i40e adapter, but it shouldn't make much difference. I'm
>> thinking it may have something to do with the MTU configuration as
>> that is one of the things I am noticing has changed between the
>> working and the broken version of the code.
>>
> I'm not seeing any issue with configuring:
>
> ip link add name tun8 type ip6gretap remote
> 2401:db00:20:911a:face:0:27:0 local 2401:db00:20:911a:face:0:25:0 ttl
> 225
>
> MTU issues would not surprise me with IPv6 though. This is part of the
> area of code that seems drastically different than what IPv4 is doing.
I am also using a key.
ip link add $name type ip6gretap key $net \
local fec0::1 remote $addr6 ttl 225 dev $PF0
Does the device you are using support any kind of checksum offload for
inner headers on GRE tunnels? It looks like if I turn off checksums
and correct the MTU I can then send traffic without issues. I'd say
that the Tx cleanup probably introduced 3 regressions. The first one
you addressed in patch 3 which fixes the flags. The second being the
fact that the MTU is wrong, and the third being something that
apparently broke checksum and maybe segmentation offload for
ip6gretap.
Really I think the transmit path cleanup should have probably been
broken down into a set of patches rather than slamming it in all in
one block. I can spend some time next week trying to sort it out if
you don't have any hardware that supports GRE segmentation or checksum
offload. If worse comes to worse I will just try breaking the revert
down into a set of smaller patches so I can figure out exactly which
change broke things.
- Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
2016-05-07 3:03 ` Alexander Duyck
@ 2016-05-09 16:56 ` Tom Herbert
2016-05-09 17:32 ` Alexander Duyck
0 siblings, 1 reply; 26+ messages in thread
From: Tom Herbert @ 2016-05-09 16:56 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, Netdev, Kernel Team
On Fri, May 6, 2016 at 8:03 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Fri, May 6, 2016 at 7:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>> On Fri, May 6, 2016 at 7:03 PM, Alexander Duyck
>> <alexander.duyck@gmail.com> wrote:
>>> On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
>>>> <alexander.duyck@gmail.com> wrote:
>>>>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>> This patch set:
>>>>>> - Fixes GRE6 to process translate flags correctly from configuration
>>>>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>>>>> - Add support for FOU and GUE in IPv6
>>>>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>>>>> - Fixes ip6_input to deal with UDP encapsulations
>>>>>> - Some other minor fixes
>>>>>>
>>>>>> v2:
>>>>>> - Removed a check of GSO types in MPLS
>>>>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>>>>> from Alexander)
>>>>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>>>>> fix makes that uncessary
>>>>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>>>>> (another item suggested by Alexander).
>>>>>>
>>>>>> v3:
>>>>>> - Address some minor comments from Alexander
>>>>>>
>>>>>> Tested:
>>>>>> Tested a variety of case, but not the full matrix (which is quite
>>>>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>>>>> some issues probably with GSO/GRO being effective in all cases.
>>>>>>
>>>>>> - IPv4/GRE/GUE/IPv6 with RCO
>>>>>> 1 TCP_STREAM
>>>>>> 6616 Mbps
>>>>>> 200 TCP_RR
>>>>>> 1244043 tps
>>>>>> 141/243/446 90/95/99% latencies
>>>>>> 86.61% CPU utilization
>>>>>> - IPv6/GRE/GUE/IPv6 with RCO
>>>>>> 1 TCP_STREAM
>>>>>> 6940 Mbps
>>>>>> 200 TCP_RR
>>>>>> 1270903 tps
>>>>>> 138/236/440 90/95/99% latencies
>>>>>> 87.51% CPU utilization
>>>>>>
>>>>>> - IP6IP6
>>>>>> 1 TCP_STREAM
>>>>>> 2576 Mbps
>>>>>> 200 TCP_RR
>>>>>> 498981 tps
>>>>>> 388/498/631 90/95/99% latencies
>>>>>> 19.75% CPU utilization (1 CPU saturated)
>>>>>>
>>>>>> - IP6IP6/GUE/IPv6 with RCO
>>>>>> 1 TCP_STREAM
>>>>>> 1854 Mbps
>>>>>> 200 TCP_RR
>>>>>> 1233818 tps
>>>>>> 143/244/451 90/95/99% latencies
>>>>>> 87.57 CPU utilization
>>>>>>
>>>>>> - IP4IP6
>>>>>> 1 TCP_STREAM
>>>>>> 200 TCP_RR
>>>>>> 763774 tps
>>>>>> 250/318/466 90/95/99% latencies
>>>>>> 35.25% CPU utilization (1 CPU saturated)
>>>>>>
>>>>>> - GRE with keyid
>>>>>> 200 TCP_RR
>>>>>> 744173 tps
>>>>>> 258/332/461 90/95/99% latencies
>>>>>> 34.59% CPU utilization (1 CPU saturated)
>>>>>
>>>>> So I tried testing your patch set and it looks like I cannot get GRE
>>>>> working for any netperf test. If I pop the patches off it is even
>>>>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>>>>> still doesn't resolve all the issues introduced with b05229f44228
>>>>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>>>>> Reverting the entire patch seems to resolve the issues, but I will try
>>>>> to pick it apart tonight to see if I can find the other issues that
>>>>> weren't addressed in this patch series.
>>>>>
>>>>
>>>> Can you give details about configuration, test you're running, and HW?
>>>
>>> The issue looks like it may be specific to ip6gretap. I'm running the
>>> test over an i40e adapter, but it shouldn't make much difference. I'm
>>> thinking it may have something to do with the MTU configuration as
>>> that is one of the things I am noticing has changed between the
>>> working and the broken version of the code.
>>>
>> I'm not seeing any issue with configuring:
>>
>> ip link add name tun8 type ip6gretap remote
>> 2401:db00:20:911a:face:0:27:0 local 2401:db00:20:911a:face:0:25:0 ttl
>> 225
>>
>> MTU issues would not surprise me with IPv6 though. This is part of the
>> area of code that seems drastically different than what IPv4 is doing.
>
> I am also using a key.
>
> ip link add $name type ip6gretap key $net \
> local fec0::1 remote $addr6 ttl 225 dev $PF0
>
I don't see any issue with key enabled.
> Does the device you are using support any kind of checksum offload for
> inner headers on GRE tunnels? It looks like if I turn off checksums
I don't believe so.
> and correct the MTU I can then send traffic without issues. I'd say
> that the Tx cleanup probably introduced 3 regressions. The first one
> you addressed in patch 3 which fixes the flags. The second being the
> fact that the MTU is wrong, and the third being something that
> apparently broke checksum and maybe segmentation offload for
> ip6gretap.
>
The MTU can be set in place in IPv6 code that doesn't exist in Ipv4. I
am especially wondering about the "if (p->flags & IP6_TNL_F_CAP_XMIT)"
block.
> Really I think the transmit path cleanup should have probably been
> broken down into a set of patches rather than slamming it in all in
> one block. I can spend some time next week trying to sort it out if
> you don't have any hardware that supports GRE segmentation or checksum
> offload. If worse comes to worse I will just try breaking the revert
> down into a set of smaller patches so I can figure out exactly which
> change broke things.
>
I am still trying to reproduce.
Tom
> - Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
2016-05-09 16:56 ` Tom Herbert
@ 2016-05-09 17:32 ` Alexander Duyck
2016-05-09 21:35 ` Alexander Duyck
0 siblings, 1 reply; 26+ messages in thread
From: Alexander Duyck @ 2016-05-09 17:32 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
On Mon, May 9, 2016 at 9:56 AM, Tom Herbert <tom@herbertland.com> wrote:
> On Fri, May 6, 2016 at 8:03 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Fri, May 6, 2016 at 7:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> On Fri, May 6, 2016 at 7:03 PM, Alexander Duyck
>>> <alexander.duyck@gmail.com> wrote:
>>>> On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
>>>>> <alexander.duyck@gmail.com> wrote:
>>>>>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>> This patch set:
>>>>>>> - Fixes GRE6 to process translate flags correctly from configuration
>>>>>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>>>>>> - Add support for FOU and GUE in IPv6
>>>>>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>>>>>> - Fixes ip6_input to deal with UDP encapsulations
>>>>>>> - Some other minor fixes
>>>>>>>
>>>>>>> v2:
>>>>>>> - Removed a check of GSO types in MPLS
>>>>>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>>>>>> from Alexander)
>>>>>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>>>>>> fix makes that uncessary
>>>>>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>>>>>> (another item suggested by Alexander).
>>>>>>>
>>>>>>> v3:
>>>>>>> - Address some minor comments from Alexander
>>>>>>>
>>>>>>> Tested:
>>>>>>> Tested a variety of case, but not the full matrix (which is quite
>>>>>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>>>>>> some issues probably with GSO/GRO being effective in all cases.
>>>>>>>
>>>>>>> - IPv4/GRE/GUE/IPv6 with RCO
>>>>>>> 1 TCP_STREAM
>>>>>>> 6616 Mbps
>>>>>>> 200 TCP_RR
>>>>>>> 1244043 tps
>>>>>>> 141/243/446 90/95/99% latencies
>>>>>>> 86.61% CPU utilization
>>>>>>> - IPv6/GRE/GUE/IPv6 with RCO
>>>>>>> 1 TCP_STREAM
>>>>>>> 6940 Mbps
>>>>>>> 200 TCP_RR
>>>>>>> 1270903 tps
>>>>>>> 138/236/440 90/95/99% latencies
>>>>>>> 87.51% CPU utilization
>>>>>>>
>>>>>>> - IP6IP6
>>>>>>> 1 TCP_STREAM
>>>>>>> 2576 Mbps
>>>>>>> 200 TCP_RR
>>>>>>> 498981 tps
>>>>>>> 388/498/631 90/95/99% latencies
>>>>>>> 19.75% CPU utilization (1 CPU saturated)
>>>>>>>
>>>>>>> - IP6IP6/GUE/IPv6 with RCO
>>>>>>> 1 TCP_STREAM
>>>>>>> 1854 Mbps
>>>>>>> 200 TCP_RR
>>>>>>> 1233818 tps
>>>>>>> 143/244/451 90/95/99% latencies
>>>>>>> 87.57 CPU utilization
>>>>>>>
>>>>>>> - IP4IP6
>>>>>>> 1 TCP_STREAM
>>>>>>> 200 TCP_RR
>>>>>>> 763774 tps
>>>>>>> 250/318/466 90/95/99% latencies
>>>>>>> 35.25% CPU utilization (1 CPU saturated)
>>>>>>>
>>>>>>> - GRE with keyid
>>>>>>> 200 TCP_RR
>>>>>>> 744173 tps
>>>>>>> 258/332/461 90/95/99% latencies
>>>>>>> 34.59% CPU utilization (1 CPU saturated)
>>>>>>
>>>>>> So I tried testing your patch set and it looks like I cannot get GRE
>>>>>> working for any netperf test. If I pop the patches off it is even
>>>>>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>>>>>> still doesn't resolve all the issues introduced with b05229f44228
>>>>>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>>>>>> Reverting the entire patch seems to resolve the issues, but I will try
>>>>>> to pick it apart tonight to see if I can find the other issues that
>>>>>> weren't addressed in this patch series.
>>>>>>
>>>>>
>>>>> Can you give details about configuration, test you're running, and HW?
>>>>
>>>> The issue looks like it may be specific to ip6gretap. I'm running the
>>>> test over an i40e adapter, but it shouldn't make much difference. I'm
>>>> thinking it may have something to do with the MTU configuration as
>>>> that is one of the things I am noticing has changed between the
>>>> working and the broken version of the code.
>>>>
>>> I'm not seeing any issue with configuring:
>>>
>>> ip link add name tun8 type ip6gretap remote
>>> 2401:db00:20:911a:face:0:27:0 local 2401:db00:20:911a:face:0:25:0 ttl
>>> 225
>>>
>>> MTU issues would not surprise me with IPv6 though. This is part of the
>>> area of code that seems drastically different than what IPv4 is doing.
>>
>> I am also using a key.
>>
>> ip link add $name type ip6gretap key $net \
>> local fec0::1 remote $addr6 ttl 225 dev $PF0
>>
> I don't see any issue with key enabled.
>
>> Does the device you are using support any kind of checksum offload for
>> inner headers on GRE tunnels? It looks like if I turn off checksums
>
> I don't believe so.
>
>> and correct the MTU I can then send traffic without issues. I'd say
>> that the Tx cleanup probably introduced 3 regressions. The first one
>> you addressed in patch 3 which fixes the flags. The second being the
>> fact that the MTU is wrong, and the third being something that
>> apparently broke checksum and maybe segmentation offload for
>> ip6gretap.
>>
> The MTU can be set in place in IPv6 code that doesn't exist in Ipv4. I
> am especially wondering about the "if (p->flags & IP6_TNL_F_CAP_XMIT)"
> block.
>
>> Really I think the transmit path cleanup should have probably been
>> broken down into a set of patches rather than slamming it in all in
>> one block. I can spend some time next week trying to sort it out if
>> you don't have any hardware that supports GRE segmentation or checksum
>> offload. If worse comes to worse I will just try breaking the revert
>> down into a set of smaller patches so I can figure out exactly which
>> change broke things.
>>
> I am still trying to reproduce.
What NICs are you testing with? Depending on the NIC I might be able
to point you in the direction of something that can reproduce the
issue.
At this point I am thinking it is an issue with a header offset since
I believe GSO resets all that and probably corrects the issue.
Thanks.
- Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
2016-05-09 17:32 ` Alexander Duyck
@ 2016-05-09 21:35 ` Alexander Duyck
2016-05-09 21:37 ` Tom Herbert
0 siblings, 1 reply; 26+ messages in thread
From: Alexander Duyck @ 2016-05-09 21:35 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
On Mon, May 9, 2016 at 10:32 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Mon, May 9, 2016 at 9:56 AM, Tom Herbert <tom@herbertland.com> wrote:
>> On Fri, May 6, 2016 at 8:03 PM, Alexander Duyck
>> <alexander.duyck@gmail.com> wrote:
>>> On Fri, May 6, 2016 at 7:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>> On Fri, May 6, 2016 at 7:03 PM, Alexander Duyck
>>>> <alexander.duyck@gmail.com> wrote:
>>>>> On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
>>>>>> <alexander.duyck@gmail.com> wrote:
>>>>>>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>>> This patch set:
>>>>>>>> - Fixes GRE6 to process translate flags correctly from configuration
>>>>>>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>>>>>>> - Add support for FOU and GUE in IPv6
>>>>>>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>>>>>>> - Fixes ip6_input to deal with UDP encapsulations
>>>>>>>> - Some other minor fixes
>>>>>>>>
>>>>>>>> v2:
>>>>>>>> - Removed a check of GSO types in MPLS
>>>>>>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>>>>>>> from Alexander)
>>>>>>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>>>>>>> fix makes that uncessary
>>>>>>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>>>>>>> (another item suggested by Alexander).
>>>>>>>>
>>>>>>>> v3:
>>>>>>>> - Address some minor comments from Alexander
>>>>>>>>
>>>>>>>> Tested:
>>>>>>>> Tested a variety of case, but not the full matrix (which is quite
>>>>>>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>>>>>>> some issues probably with GSO/GRO being effective in all cases.
>>>>>>>>
>>>>>>>> - IPv4/GRE/GUE/IPv6 with RCO
>>>>>>>> 1 TCP_STREAM
>>>>>>>> 6616 Mbps
>>>>>>>> 200 TCP_RR
>>>>>>>> 1244043 tps
>>>>>>>> 141/243/446 90/95/99% latencies
>>>>>>>> 86.61% CPU utilization
>>>>>>>> - IPv6/GRE/GUE/IPv6 with RCO
>>>>>>>> 1 TCP_STREAM
>>>>>>>> 6940 Mbps
>>>>>>>> 200 TCP_RR
>>>>>>>> 1270903 tps
>>>>>>>> 138/236/440 90/95/99% latencies
>>>>>>>> 87.51% CPU utilization
>>>>>>>>
>>>>>>>> - IP6IP6
>>>>>>>> 1 TCP_STREAM
>>>>>>>> 2576 Mbps
>>>>>>>> 200 TCP_RR
>>>>>>>> 498981 tps
>>>>>>>> 388/498/631 90/95/99% latencies
>>>>>>>> 19.75% CPU utilization (1 CPU saturated)
>>>>>>>>
>>>>>>>> - IP6IP6/GUE/IPv6 with RCO
>>>>>>>> 1 TCP_STREAM
>>>>>>>> 1854 Mbps
>>>>>>>> 200 TCP_RR
>>>>>>>> 1233818 tps
>>>>>>>> 143/244/451 90/95/99% latencies
>>>>>>>> 87.57 CPU utilization
>>>>>>>>
>>>>>>>> - IP4IP6
>>>>>>>> 1 TCP_STREAM
>>>>>>>> 200 TCP_RR
>>>>>>>> 763774 tps
>>>>>>>> 250/318/466 90/95/99% latencies
>>>>>>>> 35.25% CPU utilization (1 CPU saturated)
>>>>>>>>
>>>>>>>> - GRE with keyid
>>>>>>>> 200 TCP_RR
>>>>>>>> 744173 tps
>>>>>>>> 258/332/461 90/95/99% latencies
>>>>>>>> 34.59% CPU utilization (1 CPU saturated)
>>>>>>>
>>>>>>> So I tried testing your patch set and it looks like I cannot get GRE
>>>>>>> working for any netperf test. If I pop the patches off it is even
>>>>>>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>>>>>>> still doesn't resolve all the issues introduced with b05229f44228
>>>>>>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>>>>>>> Reverting the entire patch seems to resolve the issues, but I will try
>>>>>>> to pick it apart tonight to see if I can find the other issues that
>>>>>>> weren't addressed in this patch series.
>>>>>>>
>>>>>>
>>>>>> Can you give details about configuration, test you're running, and HW?
>>>>>
>>>>> The issue looks like it may be specific to ip6gretap. I'm running the
>>>>> test over an i40e adapter, but it shouldn't make much difference. I'm
>>>>> thinking it may have something to do with the MTU configuration as
>>>>> that is one of the things I am noticing has changed between the
>>>>> working and the broken version of the code.
>>>>>
>>>> I'm not seeing any issue with configuring:
>>>>
>>>> ip link add name tun8 type ip6gretap remote
>>>> 2401:db00:20:911a:face:0:27:0 local 2401:db00:20:911a:face:0:25:0 ttl
>>>> 225
>>>>
>>>> MTU issues would not surprise me with IPv6 though. This is part of the
>>>> area of code that seems drastically different than what IPv4 is doing.
>>>
>>> I am also using a key.
>>>
>>> ip link add $name type ip6gretap key $net \
>>> local fec0::1 remote $addr6 ttl 225 dev $PF0
>>>
>> I don't see any issue with key enabled.
>>
>>> Does the device you are using support any kind of checksum offload for
>>> inner headers on GRE tunnels? It looks like if I turn off checksums
>>
>> I don't believe so.
>>
>>> and correct the MTU I can then send traffic without issues. I'd say
>>> that the Tx cleanup probably introduced 3 regressions. The first one
>>> you addressed in patch 3 which fixes the flags. The second being the
>>> fact that the MTU is wrong, and the third being something that
>>> apparently broke checksum and maybe segmentation offload for
>>> ip6gretap.
>>>
>> The MTU can be set in place in IPv6 code that doesn't exist in Ipv4. I
>> am especially wondering about the "if (p->flags & IP6_TNL_F_CAP_XMIT)"
>> block.
So I think I have figured out the MTU problem. You need to go through
and audit the spots where you are using GRE_ flags instead of TUNNEL_
flags. Specifically in ip6gre_tnl_link_config you are using GRE_
flags to test o_flags which is configured to use the TUNNEL_ prefixed
flags. When I changed those out then the MTU started coming out
correct again. There were a couple other places you were using
GRE_SEQ where you should have been using TUNNEL_SEQ as well so you
could probably clean those up and add them to patch 3 of your set that
was fixing the flags so that they should be TUNNEL_ prefixed.
>>> Really I think the transmit path cleanup should have probably been
>>> broken down into a set of patches rather than slamming it in all in
>>> one block. I can spend some time next week trying to sort it out if
>>> you don't have any hardware that supports GRE segmentation or checksum
>>> offload. If worse comes to worse I will just try breaking the revert
>>> down into a set of smaller patches so I can figure out exactly which
>>> change broke things.
>>>
>> I am still trying to reproduce.
>
> What NICs are you testing with? Depending on the NIC I might be able
> to point you in the direction of something that can reproduce the
> issue.
>
> At this point I am thinking it is an issue with a header offset since
> I believe GSO resets all that and probably corrects the issue.
I'm still doing some digging on my end. I'm hoping to have this
figured out by the end of today.
- Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
2016-05-09 21:35 ` Alexander Duyck
@ 2016-05-09 21:37 ` Tom Herbert
2016-05-09 22:32 ` Alexander Duyck
0 siblings, 1 reply; 26+ messages in thread
From: Tom Herbert @ 2016-05-09 21:37 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, Netdev, Kernel Team
On Mon, May 9, 2016 at 2:35 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Mon, May 9, 2016 at 10:32 AM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Mon, May 9, 2016 at 9:56 AM, Tom Herbert <tom@herbertland.com> wrote:
>>> On Fri, May 6, 2016 at 8:03 PM, Alexander Duyck
>>> <alexander.duyck@gmail.com> wrote:
>>>> On Fri, May 6, 2016 at 7:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>> On Fri, May 6, 2016 at 7:03 PM, Alexander Duyck
>>>>> <alexander.duyck@gmail.com> wrote:
>>>>>> On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
>>>>>>> <alexander.duyck@gmail.com> wrote:
>>>>>>>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>>>> This patch set:
>>>>>>>>> - Fixes GRE6 to process translate flags correctly from configuration
>>>>>>>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>>>>>>>> - Add support for FOU and GUE in IPv6
>>>>>>>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>>>>>>>> - Fixes ip6_input to deal with UDP encapsulations
>>>>>>>>> - Some other minor fixes
>>>>>>>>>
>>>>>>>>> v2:
>>>>>>>>> - Removed a check of GSO types in MPLS
>>>>>>>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>>>>>>>> from Alexander)
>>>>>>>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>>>>>>>> fix makes that uncessary
>>>>>>>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>>>>>>>> (another item suggested by Alexander).
>>>>>>>>>
>>>>>>>>> v3:
>>>>>>>>> - Address some minor comments from Alexander
>>>>>>>>>
>>>>>>>>> Tested:
>>>>>>>>> Tested a variety of case, but not the full matrix (which is quite
>>>>>>>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>>>>>>>> some issues probably with GSO/GRO being effective in all cases.
>>>>>>>>>
>>>>>>>>> - IPv4/GRE/GUE/IPv6 with RCO
>>>>>>>>> 1 TCP_STREAM
>>>>>>>>> 6616 Mbps
>>>>>>>>> 200 TCP_RR
>>>>>>>>> 1244043 tps
>>>>>>>>> 141/243/446 90/95/99% latencies
>>>>>>>>> 86.61% CPU utilization
>>>>>>>>> - IPv6/GRE/GUE/IPv6 with RCO
>>>>>>>>> 1 TCP_STREAM
>>>>>>>>> 6940 Mbps
>>>>>>>>> 200 TCP_RR
>>>>>>>>> 1270903 tps
>>>>>>>>> 138/236/440 90/95/99% latencies
>>>>>>>>> 87.51% CPU utilization
>>>>>>>>>
>>>>>>>>> - IP6IP6
>>>>>>>>> 1 TCP_STREAM
>>>>>>>>> 2576 Mbps
>>>>>>>>> 200 TCP_RR
>>>>>>>>> 498981 tps
>>>>>>>>> 388/498/631 90/95/99% latencies
>>>>>>>>> 19.75% CPU utilization (1 CPU saturated)
>>>>>>>>>
>>>>>>>>> - IP6IP6/GUE/IPv6 with RCO
>>>>>>>>> 1 TCP_STREAM
>>>>>>>>> 1854 Mbps
>>>>>>>>> 200 TCP_RR
>>>>>>>>> 1233818 tps
>>>>>>>>> 143/244/451 90/95/99% latencies
>>>>>>>>> 87.57 CPU utilization
>>>>>>>>>
>>>>>>>>> - IP4IP6
>>>>>>>>> 1 TCP_STREAM
>>>>>>>>> 200 TCP_RR
>>>>>>>>> 763774 tps
>>>>>>>>> 250/318/466 90/95/99% latencies
>>>>>>>>> 35.25% CPU utilization (1 CPU saturated)
>>>>>>>>>
>>>>>>>>> - GRE with keyid
>>>>>>>>> 200 TCP_RR
>>>>>>>>> 744173 tps
>>>>>>>>> 258/332/461 90/95/99% latencies
>>>>>>>>> 34.59% CPU utilization (1 CPU saturated)
>>>>>>>>
>>>>>>>> So I tried testing your patch set and it looks like I cannot get GRE
>>>>>>>> working for any netperf test. If I pop the patches off it is even
>>>>>>>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>>>>>>>> still doesn't resolve all the issues introduced with b05229f44228
>>>>>>>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>>>>>>>> Reverting the entire patch seems to resolve the issues, but I will try
>>>>>>>> to pick it apart tonight to see if I can find the other issues that
>>>>>>>> weren't addressed in this patch series.
>>>>>>>>
>>>>>>>
>>>>>>> Can you give details about configuration, test you're running, and HW?
>>>>>>
>>>>>> The issue looks like it may be specific to ip6gretap. I'm running the
>>>>>> test over an i40e adapter, but it shouldn't make much difference. I'm
>>>>>> thinking it may have something to do with the MTU configuration as
>>>>>> that is one of the things I am noticing has changed between the
>>>>>> working and the broken version of the code.
>>>>>>
>>>>> I'm not seeing any issue with configuring:
>>>>>
>>>>> ip link add name tun8 type ip6gretap remote
>>>>> 2401:db00:20:911a:face:0:27:0 local 2401:db00:20:911a:face:0:25:0 ttl
>>>>> 225
>>>>>
>>>>> MTU issues would not surprise me with IPv6 though. This is part of the
>>>>> area of code that seems drastically different than what IPv4 is doing.
>>>>
>>>> I am also using a key.
>>>>
>>>> ip link add $name type ip6gretap key $net \
>>>> local fec0::1 remote $addr6 ttl 225 dev $PF0
>>>>
>>> I don't see any issue with key enabled.
>>>
>>>> Does the device you are using support any kind of checksum offload for
>>>> inner headers on GRE tunnels? It looks like if I turn off checksums
>>>
>>> I don't believe so.
>>>
>>>> and correct the MTU I can then send traffic without issues. I'd say
>>>> that the Tx cleanup probably introduced 3 regressions. The first one
>>>> you addressed in patch 3 which fixes the flags. The second being the
>>>> fact that the MTU is wrong, and the third being something that
>>>> apparently broke checksum and maybe segmentation offload for
>>>> ip6gretap.
>>>>
>>> The MTU can be set in place in IPv6 code that doesn't exist in Ipv4. I
>>> am especially wondering about the "if (p->flags & IP6_TNL_F_CAP_XMIT)"
>>> block.
>
> So I think I have figured out the MTU problem. You need to go through
> and audit the spots where you are using GRE_ flags instead of TUNNEL_
> flags. Specifically in ip6gre_tnl_link_config you are using GRE_
> flags to test o_flags which is configured to use the TUNNEL_ prefixed
> flags. When I changed those out then the MTU started coming out
> correct again. There were a couple other places you were using
> GRE_SEQ where you should have been using TUNNEL_SEQ as well so you
> could probably clean those up and add them to patch 3 of your set that
> was fixing the flags so that they should be TUNNEL_ prefixed.
>
>>>> Really I think the transmit path cleanup should have probably been
>>>> broken down into a set of patches rather than slamming it in all in
>>>> one block. I can spend some time next week trying to sort it out if
>>>> you don't have any hardware that supports GRE segmentation or checksum
>>>> offload. If worse comes to worse I will just try breaking the revert
>>>> down into a set of smaller patches so I can figure out exactly which
>>>> change broke things.
>>>>
>>> I am still trying to reproduce.
>>
>> What NICs are you testing with? Depending on the NIC I might be able
>> to point you in the direction of something that can reproduce the
>> issue.
>>
>> At this point I am thinking it is an issue with a header offset since
>> I believe GSO resets all that and probably corrects the issue.
>
> I'm still doing some digging on my end. I'm hoping to have this
> figured out by the end of today.
>
Yes, I will be sending a patch shortly for that if you can try it.
Tom
> - Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
2016-05-09 21:37 ` Tom Herbert
@ 2016-05-09 22:32 ` Alexander Duyck
0 siblings, 0 replies; 26+ messages in thread
From: Alexander Duyck @ 2016-05-09 22:32 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Netdev, Kernel Team
On Mon, May 9, 2016 at 2:37 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Mon, May 9, 2016 at 2:35 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Mon, May 9, 2016 at 10:32 AM, Alexander Duyck
>> <alexander.duyck@gmail.com> wrote:
>>> On Mon, May 9, 2016 at 9:56 AM, Tom Herbert <tom@herbertland.com> wrote:
>>>> On Fri, May 6, 2016 at 8:03 PM, Alexander Duyck
>>>> <alexander.duyck@gmail.com> wrote:
>>>>> On Fri, May 6, 2016 at 7:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>> On Fri, May 6, 2016 at 7:03 PM, Alexander Duyck
>>>>>> <alexander.duyck@gmail.com> wrote:
>>>>>>> On Fri, May 6, 2016 at 6:57 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>>> On Fri, May 6, 2016 at 6:09 PM, Alexander Duyck
>>>>>>>> <alexander.duyck@gmail.com> wrote:
>>>>>>>>> On Fri, May 6, 2016 at 3:11 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>>>>> This patch set:
>>>>>>>>>> - Fixes GRE6 to process translate flags correctly from configuration
>>>>>>>>>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>>>>>>>>>> - Add support for FOU and GUE in IPv6
>>>>>>>>>> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
>>>>>>>>>> - Fixes ip6_input to deal with UDP encapsulations
>>>>>>>>>> - Some other minor fixes
>>>>>>>>>>
>>>>>>>>>> v2:
>>>>>>>>>> - Removed a check of GSO types in MPLS
>>>>>>>>>> - Define GSO type SKB_GSO_IPXIP6 and SKB_GSO_IPXIP4 (based on input
>>>>>>>>>> from Alexander)
>>>>>>>>>> - Don't define GSO types specifally for IP6IP6 and IP4IP6, above
>>>>>>>>>> fix makes that uncessary
>>>>>>>>>> - Don't bother clearing encapsulation flag in UDP tunnel segment
>>>>>>>>>> (another item suggested by Alexander).
>>>>>>>>>>
>>>>>>>>>> v3:
>>>>>>>>>> - Address some minor comments from Alexander
>>>>>>>>>>
>>>>>>>>>> Tested:
>>>>>>>>>> Tested a variety of case, but not the full matrix (which is quite
>>>>>>>>>> large now). Most of the obivous cases (e.g. GRE) work fine. Still
>>>>>>>>>> some issues probably with GSO/GRO being effective in all cases.
>>>>>>>>>>
>>>>>>>>>> - IPv4/GRE/GUE/IPv6 with RCO
>>>>>>>>>> 1 TCP_STREAM
>>>>>>>>>> 6616 Mbps
>>>>>>>>>> 200 TCP_RR
>>>>>>>>>> 1244043 tps
>>>>>>>>>> 141/243/446 90/95/99% latencies
>>>>>>>>>> 86.61% CPU utilization
>>>>>>>>>> - IPv6/GRE/GUE/IPv6 with RCO
>>>>>>>>>> 1 TCP_STREAM
>>>>>>>>>> 6940 Mbps
>>>>>>>>>> 200 TCP_RR
>>>>>>>>>> 1270903 tps
>>>>>>>>>> 138/236/440 90/95/99% latencies
>>>>>>>>>> 87.51% CPU utilization
>>>>>>>>>>
>>>>>>>>>> - IP6IP6
>>>>>>>>>> 1 TCP_STREAM
>>>>>>>>>> 2576 Mbps
>>>>>>>>>> 200 TCP_RR
>>>>>>>>>> 498981 tps
>>>>>>>>>> 388/498/631 90/95/99% latencies
>>>>>>>>>> 19.75% CPU utilization (1 CPU saturated)
>>>>>>>>>>
>>>>>>>>>> - IP6IP6/GUE/IPv6 with RCO
>>>>>>>>>> 1 TCP_STREAM
>>>>>>>>>> 1854 Mbps
>>>>>>>>>> 200 TCP_RR
>>>>>>>>>> 1233818 tps
>>>>>>>>>> 143/244/451 90/95/99% latencies
>>>>>>>>>> 87.57 CPU utilization
>>>>>>>>>>
>>>>>>>>>> - IP4IP6
>>>>>>>>>> 1 TCP_STREAM
>>>>>>>>>> 200 TCP_RR
>>>>>>>>>> 763774 tps
>>>>>>>>>> 250/318/466 90/95/99% latencies
>>>>>>>>>> 35.25% CPU utilization (1 CPU saturated)
>>>>>>>>>>
>>>>>>>>>> - GRE with keyid
>>>>>>>>>> 200 TCP_RR
>>>>>>>>>> 744173 tps
>>>>>>>>>> 258/332/461 90/95/99% latencies
>>>>>>>>>> 34.59% CPU utilization (1 CPU saturated)
>>>>>>>>>
>>>>>>>>> So I tried testing your patch set and it looks like I cannot get GRE
>>>>>>>>> working for any netperf test. If I pop the patches off it is even
>>>>>>>>> worse since it looks like patch 3 fixes some tunnel flags issues, but
>>>>>>>>> still doesn't resolve all the issues introduced with b05229f44228
>>>>>>>>> ("gre6: Cleanup GREv6 transmit path, call common GRE functions").
>>>>>>>>> Reverting the entire patch seems to resolve the issues, but I will try
>>>>>>>>> to pick it apart tonight to see if I can find the other issues that
>>>>>>>>> weren't addressed in this patch series.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Can you give details about configuration, test you're running, and HW?
>>>>>>>
>>>>>>> The issue looks like it may be specific to ip6gretap. I'm running the
>>>>>>> test over an i40e adapter, but it shouldn't make much difference. I'm
>>>>>>> thinking it may have something to do with the MTU configuration as
>>>>>>> that is one of the things I am noticing has changed between the
>>>>>>> working and the broken version of the code.
>>>>>>>
>>>>>> I'm not seeing any issue with configuring:
>>>>>>
>>>>>> ip link add name tun8 type ip6gretap remote
>>>>>> 2401:db00:20:911a:face:0:27:0 local 2401:db00:20:911a:face:0:25:0 ttl
>>>>>> 225
>>>>>>
>>>>>> MTU issues would not surprise me with IPv6 though. This is part of the
>>>>>> area of code that seems drastically different than what IPv4 is doing.
>>>>>
>>>>> I am also using a key.
>>>>>
>>>>> ip link add $name type ip6gretap key $net \
>>>>> local fec0::1 remote $addr6 ttl 225 dev $PF0
>>>>>
>>>> I don't see any issue with key enabled.
>>>>
>>>>> Does the device you are using support any kind of checksum offload for
>>>>> inner headers on GRE tunnels? It looks like if I turn off checksums
>>>>
>>>> I don't believe so.
>>>>
>>>>> and correct the MTU I can then send traffic without issues. I'd say
>>>>> that the Tx cleanup probably introduced 3 regressions. The first one
>>>>> you addressed in patch 3 which fixes the flags. The second being the
>>>>> fact that the MTU is wrong, and the third being something that
>>>>> apparently broke checksum and maybe segmentation offload for
>>>>> ip6gretap.
>>>>>
>>>> The MTU can be set in place in IPv6 code that doesn't exist in Ipv4. I
>>>> am especially wondering about the "if (p->flags & IP6_TNL_F_CAP_XMIT)"
>>>> block.
>>
>> So I think I have figured out the MTU problem. You need to go through
>> and audit the spots where you are using GRE_ flags instead of TUNNEL_
>> flags. Specifically in ip6gre_tnl_link_config you are using GRE_
>> flags to test o_flags which is configured to use the TUNNEL_ prefixed
>> flags. When I changed those out then the MTU started coming out
>> correct again. There were a couple other places you were using
>> GRE_SEQ where you should have been using TUNNEL_SEQ as well so you
>> could probably clean those up and add them to patch 3 of your set that
>> was fixing the flags so that they should be TUNNEL_ prefixed.
>>
>>>>> Really I think the transmit path cleanup should have probably been
>>>>> broken down into a set of patches rather than slamming it in all in
>>>>> one block. I can spend some time next week trying to sort it out if
>>>>> you don't have any hardware that supports GRE segmentation or checksum
>>>>> offload. If worse comes to worse I will just try breaking the revert
>>>>> down into a set of smaller patches so I can figure out exactly which
>>>>> change broke things.
>>>>>
>>>> I am still trying to reproduce.
>>>
>>> What NICs are you testing with? Depending on the NIC I might be able
>>> to point you in the direction of something that can reproduce the
>>> issue.
>>>
>>> At this point I am thinking it is an issue with a header offset since
>>> I believe GSO resets all that and probably corrects the issue.
>>
>> I'm still doing some digging on my end. I'm hoping to have this
>> figured out by the end of today.
>>
>
> Yes, I will be sending a patch shortly for that if you can try it.
Yes. I will be available to test whatever you can provide.
In the meantime I have identified two other issues.
1. skb_set_inner_protocol is being called with the wrong value in
__gre6_xmit. It should be passed protocol, not proto.
2. If __gre6_xmit is going to use ip6_tnl_xmit then we cannot clobber
skb->transport_header as we currently do inside of ip6_tnl_xmit
because it creates an invalid value for the offset. I believe that
would have broken FOU/GUE over the tunnel as well since the transport
header would be needed to support offloads.
If you can get these two issues, plus the one flags issue I mentioned
earlier it should resolve things and make it so that we can go back to
getting ip6gretap working with hardware offloads again.
- Alex
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2016-05-09 22:32 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-06 22:11 [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Tom Herbert
2016-05-06 22:11 ` [PATCH v3 net-next 01/11] gso: Remove arbitrary checks for unsupported GSO Tom Herbert
2016-05-06 22:34 ` Alexander Duyck
2016-05-07 2:44 ` Alexander Duyck
2016-05-06 22:11 ` [PATCH v3 net-next 02/11] net: define gso types for IPx over IPv4 and IPv6 Tom Herbert
2016-05-06 22:48 ` Alexander Duyck
2016-05-06 22:55 ` Tom Herbert
2016-05-06 22:11 ` [PATCH v3 net-next 03/11] gre6: Fix flag translations Tom Herbert
2016-05-06 22:11 ` [PATCH v3 net-next 04/11] fou: Call setup_udp_tunnel_sock Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 05/11] fou: Split out {fou,gue}_build_header Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 06/11] fou: Add encap ops for IPv6 tunnels Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 07/11] ipv6: Fix nexthdr for reinjection Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 08/11] ipv6: Change "final" protocol processing for encapsulation Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 09/11] fou: Support IPv6 in fou Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 10/11] ip6_tun: Add infrastructure for doing encapsulation Tom Herbert
2016-05-06 22:12 ` [PATCH v3 net-next 11/11] ip6_gre: Add support for fou/gue encapsulation Tom Herbert
2016-05-07 1:09 ` [PATCH v3 net-next 00/11] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling Alexander Duyck
2016-05-07 1:57 ` Tom Herbert
2016-05-07 2:03 ` Alexander Duyck
2016-05-07 2:11 ` Tom Herbert
2016-05-07 3:03 ` Alexander Duyck
2016-05-09 16:56 ` Tom Herbert
2016-05-09 17:32 ` Alexander Duyck
2016-05-09 21:35 ` Alexander Duyck
2016-05-09 21:37 ` Tom Herbert
2016-05-09 22:32 ` Alexander Duyck
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.