Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp323254pxv; Thu, 15 Jul 2021 05:15:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNQaFjndnwuPi+4Z7tNJYL0WBcgRNRXJ7+uesf2nf7K5l5aVtbFmKmSirKDAARcTwRfU+n X-Received: by 2002:a05:6e02:1a67:: with SMTP id w7mr2440783ilv.175.1626351331012; Thu, 15 Jul 2021 05:15:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626351331; cv=none; d=google.com; s=arc-20160816; b=VZiD5Pbf/Amv1FGLmvuVPZ61v94hLd8EIny08k/b5e8t7xrh/4gV5b1gr6TFw92uCI GTb/N7JjLp7gOxTqKe8ijhj/fCmDeONH5eou4stho8NL1Usshv2ksAyR82xZkuwVtWFT 7WE7wv4FKEFmXlgvAPx8DaZ2wZcUdH6zgjeUz0HcdP1TKcVvzWAgZdkVRxQNsj9rp7U+ HX6/JU2mwD03TScH8SpDi5g17/F57qYIE+U9O3FT5Qf52tnSJLqvpcWpwviQ6SQkbHb+ NDUXvSoh1q7Yz2XoeuFZvrdMllAryOTm5vD7QsOLSn4ZGeAV8npvf0lNsck8aNrzzJBa +2UQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:references:in-reply-to :sensitivity:importance:date:subject:cc:to:from:message-id :mime-version:dkim-signature; bh=9hH7pCsS3p3U1mleP+c/0/VnKG1nmgnWed1gDDvBfLY=; b=gD/zwzHdFDFGSbXYr0pombEK3HAzwKcltxDpWXa8ZFDSffbihASCD2vYOzm+O2VN6H eLXwPf0i6CNYqPz+5TCifas5nwhVK9AaQTYGh9OKnMetgtiqH1dObqzrw5nQGCAgSUQ4 vcQgwohFaWW+jcdKz0Kzwxk4RyPtku647/ct1ogSgOAW3KfwQ30en41oKsvGn+mq+aIh MqZ7Ab164EXDCW2JDWXuCjauTGY7OJv9vDSbBQjrilG3Dn1UoxJUVgZsA1+IGm+0Fyo5 B86sfcKORefzRmTjycsKywsLY3SXUXs9T9GSTcp9DNh0XrorxXxjCxQCelu6x2YiHpbv HEkQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmx.net header.s=badeba3b8450 header.b=HBxW61sA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmx.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u11si8860098jau.121.2021.07.15.05.15.19; Thu, 15 Jul 2021 05:15:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmx.net header.s=badeba3b8450 header.b=HBxW61sA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmx.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241860AbhGOLTR (ORCPT + 99 others); Thu, 15 Jul 2021 07:19:17 -0400 Received: from mout.gmx.net ([212.227.17.20]:36537 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241852AbhGOLTR (ORCPT ); Thu, 15 Jul 2021 07:19:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626347772; bh=TLXUsDdT2Ni6P1bd2RJdAeMmR/wZbLbHTRLAmPJxv9U=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=HBxW61sAJodPP7wxHBOZdiu36Jbz9H+AMbkbpijQprGXDaTmY7QuXjxCAhpxzsikX Iz22GxP85dV0s5RnKDUPPj7ZKwxdstEPALAbBg5MCzfwMmHJLNqu5vvwDHbx7H2Z5i 5+4DaiJyCwJJDLid9wJU72zKRJVDrz1/czbUsDPE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [87.130.101.138] ([87.130.101.138]) by web-mail.gmx.net (3c-app-gmx-bap31.server.lan [172.19.172.101]) (via HTTP); Thu, 15 Jul 2021 13:16:12 +0200 MIME-Version: 1.0 Message-ID: From: Lino Sanfilippo To: Vladimir Oltean Cc: Andrew Lunn , woojung.huh@microchip.com, UNGLinuxDriver@microchip.com, vivien.didelot@gmail.com, f.fainelli@gmail.com, davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Aw: Re: [PATCH 2/2] net: dsa: tag_ksz: dont let the hardware process the layer 4 checksum Content-Type: text/plain; charset=UTF-8 Date: Thu, 15 Jul 2021 13:16:12 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <20210715065455.7nu7zgle2haa6wku@skbuf> References: <20210714191723.31294-1-LinoSanfilippo@gmx.de> <20210714191723.31294-3-LinoSanfilippo@gmx.de> <20210714194812.stay3oqyw3ogshhj@skbuf> <20210715065455.7nu7zgle2haa6wku@skbuf> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:CxxzBKXA9/qQJnsYgLSgPmS6MXvvV0h4Kj1Fl2Xg5dCkDIN0g9efjUiBvzt36HXv+xA71 N+F2XpU2MS7kk1PaxtzWsfM1ujMmwTGnIvVypWa+rT6BogXiXuuMnYaDCOO6xGRNXHhzzLA+SLUQ TUWaCLO4wsAq9HmQr0kLPMxGTh8mflK+ATN3HHxkOw5Ghgn880EOViy5cu36EupiTcGBZxDt/jsF WnEOYl8AXNCetaMGN09GT1Q41h5IyxQdxY35Wxp2v+pI/m/QcN6P3UBPDDnd2FMBdEZx2JQNWuZb Cg= X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:tFCbLYKOsxI=:hcAc+94wjwYA1qNadjyAij PL8NfrQtYM5aC7v4qjlz7YdGgnglSoobRAWrEdqWWH9WS8R54gLaKaED+Jm/7WRnCqiuKtr3V WC4JVQ3nyFcA9F4njhgwFG2JOXBjORL4K2iByBtzbeecwprA6hadRlRK3nYxl/H7CVbqPliAd cuqqJT+llBhKpxZrVnvrOZqsSA9JW/cBchm0I1Q5aoS2yjoYmWDYTRLcLtYSLDFVMOosdIUzl i23W+0yxIDqMX227rC8et2tuVKixVBA/JJiGTamSxjMbE6BfCA54sU7668wFRMLi0njTHMjNn 0adz+KyNvpA3yKJslSK8yl5O7hYbEXInAyh7HtHuJ40rGYH48MqitNsK8p52HmeT9mH4uOQbQ PRv0B8/2fwEoBplb33wqORf4CmRJcGWmUv3RV2pWAZ9BR5NWVMFinYno8GQY3nQVW14mM18c5 91HVTAjl85WbKKasm1T69ii62szoq+gSBO17rDqgCZVCahknT3e+iYKLFmENayUdvBpmXKfPm 8y+WL69RWGthcWJBLl4HWrTG/nO1AK6a67QqVLBxhRmE6JA610dOB9pGa+XgWvGuaJTt7nYjF raD1109waV1BFEuYTj6n9MdAextpFmgtUM4bb2BCq0PtHbhXQYkIsktzBIGjAk1uBJZR8jdZT H/X4U6rJaMhHp+M85WoBWHB6UT0C9Gk7DRLXD3vaarVRkHFpy2wgUpV2I2AOcvU2z9GVbpKLJ 9hcMOWcvclLSqruz+i2HIG+GX0ZrPe5siIsEOSuP/1M9IJBVJRkbDAcWFkHSPaDFPXDlkabe0 J5AR9JhoDTV4deyi7u3zgN1jkOqGNZfsYSKYLM1ix1oxkACZ7o= Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vladimir, > Gesendet: Donnerstag, 15. Juli 2021 um 08:54 Uhr > Von: "Vladimir Oltean" > An: "Andrew Lunn" > Cc: "Lino Sanfilippo" , woojung.huh@microchip.com= , UNGLinuxDriver@microchip.com, vivien.didelot@gmail.com, f.fainelli@gmail= .com, davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, linux-= kernel@vger.kernel.org > Betreff: Re: [PATCH 2/2] net: dsa: tag_ksz: dont let the hardware proces= s the layer 4 checksum > > On Wed, Jul 14, 2021 at 10:15:20PM +0200, Andrew Lunn wrote: > > On Wed, Jul 14, 2021 at 10:48:12PM +0300, Vladimir Oltean wrote: > > > Hi Lino, > > > > > > On Wed, Jul 14, 2021 at 09:17:23PM +0200, Lino Sanfilippo wrote: > > > > If the checksum calculation is offloaded to the network device (e.= g due to > > > > NETIF_F_HW_CSUM inherited from the DSA master device), the calcula= ted > > > > layer 4 checksum is incorrect. This is since the DSA tag which is = placed > > > > after the layer 4 data is seen as a part of the data portion and t= hus > > > > errorneously included into the checksum calculation. > > > > To avoid this, always calculate the layer 4 checksum in software. > > > > > > > > Signed-off-by: Lino Sanfilippo > > > > --- > > > > > > This needs to be solved more generically for all tail taggers. Let m= e > > > try out a few things tomorrow and come with a proposal. > > > > Maybe the skb_linearize() is also a generic problem, since many of the > > tag drivers are using skb_put()? It looks like skb_linearize() is > > cheap because checking if the skb is already linear is cheap. So maybe > > we want to do it unconditionally? > > Yeah, but we should let the stack deal with both issues in validate_xmit= _skb(). > There is a skb_needs_linearize() call which returns false because the > DSA interface inherits NETIF_F_SG from the master via dsa_slave_create()= : > > slave_dev->features =3D master->vlan_features | NETIF_F_HW_TC; > > Arguably that's the problem right there, we shouldn't inherit neither > NETIF_F_HW_CSUM nor NETIF_F_SG from the list of features inheritable by > 8021q uppers. > > - If we inherit NETIF_F_SG we obligate ourselves to call skb_linearize() > for tail taggers on xmit. DSA probably doesn't break anything for > header taggers though even if the xmit skb is paged, since the DSA > header would always be part of the skb head, so this is a feature we > could keep for them. > - If we inherit NETIF_F_HW_CSUM from the master for tail taggers, it is > actively detrimential to keep this feature enabled, as proven my Lino. > As for header taggers, I fail to see how this would be helpful, since > the DSA master would always fail to see the real IP header (it has > been pushed to the right by the DSA tag), and therefore, the DSA > master offload would be effectively bypassed. So no point, really, in > inheriting it in the first place in any situation. > > Lino, to fix these bugs by letting validate_xmit_skb() know what works > for DSA and what doesn't, could you please: > > (a) move the current slave_dev->features assignment to > dsa_slave_setup_tagger()? We now support changing the tagging > protocol at runtime, and everything that depends on what the tagging > protocol is (in this case, tag_ops->needed_headroom vs > tag_ops->needed_tailroom) should be put in that function. > (b) unconditionally clear NETIF_F_HW_CSUM from slave_dev->features, > after inheriting the vlan_features from the master? > (c) clear NETIF_F_SG from slave_dev->features if we have a non-zero > tag_ops->needed_tailroom? > Sure, I will test this solution. But I think NETIF_F_FRAGLIST should also = be cleared in this case, right? Regards, Lino