| Message ID | 1382692140.7572.79.camel@edumazet-glaptop.roam.corp.google.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Eric Dumazet <eric.dumazet@gmail.com> Date: Fri, 25 Oct 2013 02:09:00 -0700 > @@ -1252,6 +1252,7 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb, > const struct net_offload *ops; > unsigned int offset = 0; > struct iphdr *iph; > + bool udpfrag; > bool tunnel; > int proto; > int nhoff; > @@ -1306,10 +1307,11 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb, > if (IS_ERR_OR_NULL(segs)) > goto out; > > + udpfrag = !!skb->encapsulation && proto == IPPROTO_UDP; > skb = segs; > do { > iph = (struct iphdr *)(skb_mac_header(skb) + nhoff); > - if (!tunnel && proto == IPPROTO_UDP) { > + if (udpfrag) { > iph->id = htons(id); > iph->frag_off = htons(offset >> 3); > if (skb->next != NULL) > The "tunnel" variable becomes unused once you do this, please remove it. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 25, 2013 at 3:18 PM, David Miller <davem@davemloft.net> wrote: > From: Eric Dumazet <eric.dumazet@gmail.com> > Date: Fri, 25 Oct 2013 02:09:00 -0700 > >> @@ -1252,6 +1252,7 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb, >> const struct net_offload *ops; >> unsigned int offset = 0; >> struct iphdr *iph; >> + bool udpfrag; >> bool tunnel; >> int proto; >> int nhoff; >> @@ -1306,10 +1307,11 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb, >> if (IS_ERR_OR_NULL(segs)) >> goto out; >> >> + udpfrag = !!skb->encapsulation && proto == IPPROTO_UDP; >> skb = segs; >> do { >> iph = (struct iphdr *)(skb_mac_header(skb) + nhoff); >> - if (!tunnel && proto == IPPROTO_UDP) { >> + if (udpfrag) { >> iph->id = htons(id); >> iph->frag_off = htons(offset >> 3); >> if (skb->next != NULL) >> > > The "tunnel" variable becomes unused once you do this, please remove it. 'bool tunnel' actually still used to indicate encap_level > 0 Eric's fix brings back performance for vxlan and gre keeps working. Thx! net/core/skbuff.c:3474 skb_try_coalesce() warning, I mentioned before, is unrelated. I still see it with this patch. Running either gre or vxlan tunnels. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Alexei Starovoitov <ast@plumgrid.com> Date: Fri, 25 Oct 2013 15:41:47 -0700 > 'bool tunnel' actually still used to indicate encap_level > 0 Good catch, I misread the code. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2013-10-25 at 15:41 -0700, Alexei Starovoitov wrote: > 'bool tunnel' actually still used to indicate encap_level > 0 > Yes, I am studying if the setting of skb->encapsulation = 1 was really needed in the : if (tunnel) { skb_reset_inner_headers(skb); skb->encapsulation = 1; } And was planning to rename 'bool tunnel' by 'bool stacked' or something... > Eric's fix brings back performance for vxlan and gre keeps working. Thx! Please note the original performance is not that good, you mentioned 230 Mbps on lxc, while I get more than 5Gb/s on a 10G link. This should be investigated ... > > net/core/skbuff.c:3474 skb_try_coalesce() warning, I mentioned before, > is unrelated. > I still see it with this patch. Running either gre or vxlan tunnels. I think this might be related to commit 6ff50cd55545 ("tcp: gso: do not generate out of order packets") I'll investigate this as well, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2013-10-25 at 16:25 -0700, Eric Dumazet wrote: > Please note the original performance is not that good, you mentioned 230 > Mbps on lxc, while I get more than 5Gb/s on a 10G link. > > This should be investigated ... This is probably trivial to increase performance : veth currently do not support any kind of tunneling TSO : tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-ipip-segmentation: off [fixed] tx-sit-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-mpls-segmentation: off [fixed] I'll submit a patch for net-next -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c index f4a159e..17dd8320 100644 --- a/net/ipv4/af_inet.c +++ b/net/ipv4/af_inet.c @@ -1252,6 +1252,7 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb, const struct net_offload *ops; unsigned int offset = 0; struct iphdr *iph; + bool udpfrag; bool tunnel; int proto; int nhoff; @@ -1306,10 +1307,11 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb, if (IS_ERR_OR_NULL(segs)) goto out; + udpfrag = !!skb->encapsulation && proto == IPPROTO_UDP; skb = segs; do { iph = (struct iphdr *)(skb_mac_header(skb) + nhoff); - if (!tunnel && proto == IPPROTO_UDP) { + if (udpfrag) { iph->id = htons(id); iph->frag_off = htons(offset >> 3); if (skb->next != NULL)