Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp6015641pxb; Mon, 14 Feb 2022 13:11:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJy16GEpFzPCGXdEO9Sfawn9uaXDQBwHjRSWiGuR1490adBkwIf0FpLLKH9H/+ovFWwOxFx/ X-Received: by 2002:a63:ad4e:: with SMTP id y14mr777430pgo.214.1644873083689; Mon, 14 Feb 2022 13:11:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644873083; cv=none; d=google.com; s=arc-20160816; b=uZAjNIlkySEHwUKf1gtmoQmah2y3pcj8KezGMJPYfjOpSk7zje0eZSYUqEWNZ5hQNV SARCuv7vTVUZ9SAia4OBz76U204JOxBM/SkEqHQoMElK4QBRPHTCn6ohsKElwvEA+T/z g99mmYx3/j209IsdN+t/dOg/3hJs5of53HSJLi2XPH1YGHE8LmJB3dDauYNo0WIsghtq pMKKG3MG/unqJWujIun0a0z1bYqG/7urd3BlLbus+xhlBb3nlX1hww/P2C5CWEtIrG4d 4bqijgVwF+i3ZHQf6wgHaFuxkmeufY6LoJtgi6rG2hHxwtZg5Te0xuLLFGe8kexb+dqf GueQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=BDXZaoizDr7YeP+Atw0KemHoKPFgMstyLuuzXFa0H7A=; b=Gypwc/WCU+waMvFPARTEvVlvDuQHOQbjKR7TsTb+J3engYstvm+EsZaQ/8AD8C4ePX b0T3/nkd/eyQF1t6LZEAdNKde1wmgjBFFO4yV04boygGz6f12RXkDS1dg/iAqh0iABfn g+Cf3YuAIcEUz2ecH27Qp7V7wCx8nSH2VgC8svvgCwuAPutSu3jI/rXNvyWBTr6Ai1sB Fxpb5ivNLCs3Emny788SGdNtq+Rvm8d9/z0zdENXMdvz2blObrqP3sDzGlJkb5vMDxAS pBFNEBXkTxPWGmqDc42QOMeb1AU/v2S77x5M5vCNyqyXcqFgacejDnLdozyDBtziW+Ic Rd8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=JxVo9WTF; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id f2si742363pgv.426.2022.02.14.13.11.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 13:11:23 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=JxVo9WTF; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8D6D72128A7; Mon, 14 Feb 2022 12:31:11 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238710AbiBNE2o (ORCPT + 99 others); Sun, 13 Feb 2022 23:28:44 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:60800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231851AbiBNE2m (ORCPT ); Sun, 13 Feb 2022 23:28:42 -0500 Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34FB619280 for ; Sun, 13 Feb 2022 20:28:35 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id r20so17436944vsn.0 for ; Sun, 13 Feb 2022 20:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BDXZaoizDr7YeP+Atw0KemHoKPFgMstyLuuzXFa0H7A=; b=JxVo9WTFlUz8ugjDViLyEpxDozrHP7l7WFND0eUKV3mTbcXf0yjHAUSqHC2vjTPcIY CnkabDxTOe6KQPS5T7g+LAfvUGte9ljzmdD4sX1Z8PN2XpCZorXV/yfxLyvyjHYc8KKp qB7gAgJpnBgCPYC1hdNb50ZTlVVIzreAa26SYJATmDWtc+VHNRLzcdnq0/KEzUaHjDwj xyCrKkEUgUWEerqlXegww/9o08SpIKQBvbLCZnRUe3FbXb73bz740rCUg7aj2tv1zYP5 u8qdR8BSn4MuQDxZYZTdmVccUR1VOW2YfmcbfRTuVghM6i4arryelaYk8t9822kql6z8 rlgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BDXZaoizDr7YeP+Atw0KemHoKPFgMstyLuuzXFa0H7A=; b=FCKI/yvA+M4LGIW0QHaG+AnwpHyIQj2AmBAQuSgB2kggq9Le/LSRJQfddkDwGQNCnK K3fOBxTibR4Vy+nu0JS3LwDXqKxR3Q6LdtnPt+SE4buMRhxtCLKOZanaWHpn52D8L9UP k4Zi0VVmFO56nAnre+Yk4N8Q2v9FJny72xETbQRSrlwqbjacz+kKDBf6OB+ykh7GxqCu CFuwNpqZgYg4gZQe1gB9RWmArgZNJayqwfPETAS7BuolKnJlQeR/R4MIkcZNCJOkH+wu cyQIJFF1sVwobs2JKGmXwUH9XdNclfjOEJ25+a9fCVy7Ua0omN5KvT1qazZ9z+ctTxMX bDqA== X-Gm-Message-State: AOAM530z/Jg+TJ7c2vMD/GpHKGUrdztrkMZdfSoviOEaVoyuNj5OUAKV 9rE6nBEy5x04g9/ylPT+DsuqFvnk0WM= X-Received: by 2002:a05:6102:364:: with SMTP id f4mr3116549vsa.21.1644812914320; Sun, 13 Feb 2022 20:28:34 -0800 (PST) Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com. [209.85.222.47]) by smtp.gmail.com with ESMTPSA id r2sm92136vka.52.2022.02.13.20.28.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Feb 2022 20:28:33 -0800 (PST) Received: by mail-ua1-f47.google.com with SMTP id 103so7521985uag.4 for ; Sun, 13 Feb 2022 20:28:33 -0800 (PST) X-Received: by 2002:ab0:2710:: with SMTP id s16mr3410627uao.37.1644812913237; Sun, 13 Feb 2022 20:28:33 -0800 (PST) MIME-Version: 1.0 References: <20220213150234.31602-1-thomas.liu@ucloud.cn> In-Reply-To: From: Willem de Bruijn Date: Sun, 13 Feb 2022 23:27:57 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] gso: do not skip outer ip header in case of ipip and net_failover To: Tao Liu Cc: Willem de Bruijn , davem@davemloft.net, yoshfuji@linux-ipv6.org, dsahern@kernel.org, kuba@kernel.org, edumazet@google.com, sridhar.samudrala@intel.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 13, 2022 at 11:03 PM Tao Liu wrote: > > Sorry for bothering, just repost it. > > > 2022=E5=B9=B42=E6=9C=8814=E6=97=A5 09:28=EF=BC=8CWillem de Bruijn =E5=86=99=E9=81=93=EF=BC=9A > > > > On Sun, Feb 13, 2022 at 10:10 AM Tao Liu wrote: > >> > >> We encouter a tcp drop issue in our cloud environment. Packet GROed in= host > >> forwards to a VM virtio_net nic with net_failover enabled. VM acts as = a > >> IPVS LB with ipip encapsulation. The full path like: > >> host gro -> vm virtio_net rx -> net_failover rx -> ipvs fullnat > >> -> ipip encap -> net_failover tx -> virtio_net tx > >> > >> When net_failover transmits a ipip pkt (gso_type =3D 0x0103), there is= no gso > >> performed because it supports TSO and GSO_IPXIP4. But network_header h= as > >> been pointing to inner ip header. > > > > If the packet is configured correctly, and net_failover advertises > > that it can handle TSO packets with IPIP encap, then still virtio_net > > should not advertise it and software GSO be applied on its > > dev_queue_xmit call. > > > > This is assuming that the packet not only has SKB_GSO_IPXIP4 correctly > > set, but also tunneling fields like skb->encapsulated and > > skb_inner_network_header. > Thanks very much for your comment! > > Yes, the packet is correct. Another thing i have not pointed directly is > that the pkt has SKB_GSO_DODGY. net_failover do not advertises GSO_ROBUST > but virtio_net do. If net_failover does not advertise NETIF_F_GSO_ROBUST, then tcp_gso_segment will pass a packet with SKB_GSO_DODGY to the software gso stack, not taking the branch if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) { > >> --- > >> net/ipv4/af_inet.c | 10 +++++++++- > >> 1 file changed, 9 insertions(+), 1 deletion(-) > >> > >> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c > >> index 9c465ba..f8b3f8a 100644 > >> --- a/net/ipv4/af_inet.c > >> +++ b/net/ipv4/af_inet.c > >> @@ -1425,10 +1425,18 @@ struct sk_buff *inet_gso_segment(struct sk_buf= f *skb, > >> static struct sk_buff *ipip_gso_segment(struct sk_buff *skb, > >> netdev_features_t features) > >> { > >> + struct sk_buff *segs; > >> + int nhoff; > >> + > >> if (!(skb_shinfo(skb)->gso_type & SKB_GSO_IPXIP4)) > >> return ERR_PTR(-EINVAL); > >> > >> - return inet_gso_segment(skb, features); > >> + nhoff =3D skb_network_header(skb) - skb_mac_header(skb); > >> + segs =3D inet_gso_segment(skb, features); > >> + if (!segs) > >> + skb->network_header =3D skb_mac_header(skb) + nhoff - = skb->head; > >> + > >> + return segs; > >> } > > > > If this would be needed for IPIP, then the same would be needed for SIT= , etc. > > > > Is the skb_network_header > > > > 1. correctly pointing to the outer header of the TSO packet before the > > call to inet_gso_segment > > 2. incorrectly pointing to the inner header of the (still) TSO packet > > after the call to inet_gso_segment > > > > inet_gso_segment already does the same operation: save nhoff, pull > > network header, call callbacks.gso_segment (which can be > > ipip_gso_segment->inet_gso_segment), then place the network header > > back at nhoff. > > > values print in skb_mac_gso_segment() before callbacks.gso_segment: > ipip: vlan_depth=3D0 mac_len=3D0 skb->network_header=3D206 > net_failover: vlan_depth=3D14 mac_len=3D14 skb->network_header=3D186 > virtio_net: vlan_depth=3D34 mac_len=3D34 skb->network_header=3D206 > > agree to add sit/ip4ip6/ip6ip6, and patch can be simplified as: If IPIP GSO was so broken, I think we would have found it long before. As said, inet_gso_segment should already do the right thing for ipip: it will be called twice.