Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3607052pxk; Mon, 7 Sep 2020 19:34:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzB20jMlM80KXuSB9l3I9w+6ZcvOcRnQ7yZhloZl4jrjjE0ZXXSDXmreu74BOYz1fvG3QGu X-Received: by 2002:a17:906:4755:: with SMTP id j21mr24254407ejs.228.1599532484304; Mon, 07 Sep 2020 19:34:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599532484; cv=none; d=google.com; s=arc-20160816; b=uT6lgid13RC3x5Fp6LacrAIVefkczmZ2pBgAkAFHamsJleXZ6oMyAiZsSulyMrce/+ igtLsQUGOLLRU+jybnOMPNQz8/G3LcvVJwsqQQRDbi7UmEBC3cjsQ2Xcc3ehilh7o8HW uDbNLFJYMHzD/t7wxUc4019PhRvJzYmwSic07GFnVEGpRpNqnTho+ZR+CJjgfGwC5FfY 9VwQ3B32h9Pj36VflIKMB9GU2ycJySuAyCWJaLXDaBxpBlLGfoBn4N/IbdnZzAa13oGS z7/C4Fafgn2kv2Tn42TSvYNirEk5OyZYsS9RdcrnynVWGaYazF9WC75WfWNUpcyGoiPg q4lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Q/0rEnQFLlmCpkyfxc6neDs70cmjlZtPS5vPyDq1yno=; b=GGmMnDuJjwsgDgmVNhFojzaa8SlrGJi/EFSNuGuRH5eyraYV8prxoot5nYL0vUzcZg GWuQLp44x1895aQVA66f1Pti/7qClS+7HfSFYHDl8NvgXzwKxUueVPgxV992cbXCiub0 nhoxCm3zmr4l5npwsUcHWCFDD6EHBFa5xpwWUESsDIq4aoUZeOl+IHlelHH3TzWxqJAm RnbRpCG1mPM/uLZiNpt6sBLMNJ4BjD89WVv8nx9aSEurGQLbsoXRLVZ2IvWWBpJS5x7Q 9C2VdYF6rpfqvEXOcqzcG8ODVfhJ2Lbdy7PwnaXVxE0IMJ8Y3Bxgjcfmifv6zEokuTrO wqAQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n25si10716062edt.464.2020.09.07.19.34.21; Mon, 07 Sep 2020 19:34:44 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728295AbgIHCcp (ORCPT + 99 others); Mon, 7 Sep 2020 22:32:45 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:11250 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728188AbgIHCco (ORCPT ); Mon, 7 Sep 2020 22:32:44 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id AE010DC4C4B66C34BA9E; Tue, 8 Sep 2020 10:32:41 +0800 (CST) Received: from [127.0.0.1] (10.74.149.191) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.487.0; Tue, 8 Sep 2020 10:32:35 +0800 Subject: Re: [PATCH net-next 0/2] net: two updates related to UDP GSO To: Willem de Bruijn CC: Jakub Kicinski , David Miller , Network Development , linux-kernel , , , References: <1599286273-26553-1-git-send-email-tanhuazhong@huawei.com> <20200906114153.7dccce5d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <126e5424-2453-eef4-d5b6-adeaedbb6eca@huawei.com> From: tanhuazhong Message-ID: <6cb146b5-8e0d-ed22-a0c1-b54c59685aa5@huawei.com> Date: Tue, 8 Sep 2020 10:32:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.74.149.191] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/9/7 23:35, Willem de Bruijn wrote: > On Mon, Sep 7, 2020 at 3:38 PM tanhuazhong wrote: >> >> >> >> On 2020/9/7 17:22, Willem de Bruijn wrote: >>> On Sun, Sep 6, 2020 at 8:42 PM Jakub Kicinski wrote: >>>> >>>> On Sat, 5 Sep 2020 14:11:11 +0800 Huazhong Tan wrote: >>>>> There are two updates relates to UDP GSO. >>>>> #1 adds a new GSO type for UDPv6 >>>>> #2 adds check for UDP GSO when csum is disable in netdev_fix_features(). >>>>> >>>>> Changes since RFC V2: >>>>> - modifies the timing of setting UDP GSO type when doing UDP GRO in #1. >>>>> >>>>> Changes since RFC V1: >>>>> - updates NETIF_F_GSO_LAST suggested by Willem de Bruijn. >>>>> and add NETIF_F_GSO_UDPV6_L4 feature for each driver who support UDP GSO in #1. >>>>> - add #2 who needs #1. >>>> >>>> Please CC people who gave you feedback (Willem). >>>> >>>> I don't feel good about this series. IPv6 is not optional any more. >>>> AFAIU you have some issues with csum support in your device? Can you >>>> use .ndo_features_check() to handle this? >>>> >>>> The change in semantics of NETIF_F_GSO_UDP_L4 from "v4 and v6" to >>>> "just v4" can trip people over; this is not a new feature people >>>> may be depending on the current semantics. >>>> >>>> Willem, what are your thoughts on this? >>> >>> If that is the only reason, +1 on fixing it up in the driver's >>> ndo_features_check. >>> >> >> Hi, Willem & Jakub. >> >> This series mainly fixes the feature dependency between hardware >> checksum and UDP GSO. >> When turn off hardware checksum offload, run 'ethtool -k [devname]' >> we can see TSO is off as well, but udp gso still is on. > > I see. That does not entirely require separate IPv4 and IPv6 flags. It > can be disabled if either checksum offload is disabled. I'm not aware > of any hardware that only supports checksum offload for one of the two > network protocols. > below patch is acceptable? i have sent this patch before (https://patchwork.ozlabs.org/project/netdev/patch/1594180136-15912-3-git-send-email-tanhuazhong@huawei.com/) diff --git a/net/core/dev.c b/net/core/dev.c index c02bae9..dcb6b35 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -9095,6 +9095,12 @@ static netdev_features_t netdev_fix_features(struct net_device *dev, features &= ~NETIF_F_TSO6; } + if ((features & NETIF_F_GSO_UDP_L4) && !(features & NETIF_F_HW_CSUM) && + (!(features & NETIF_F_IP_CSUM) || !(features & NETIF_F_IPV6_CSUM))) { + netdev_dbg(dev, "Dropping UDP GSO features since no CSUM feature.\n"); + features &= ~NETIF_F_GSO_UDP_L4; + } + /* TSO with IPv4 ID mangling requires IPv4 TSO be enabled */ if ((features & NETIF_F_TSO_MANGLEID) && !(features & NETIF_F_TSO)) features &= ~NETIF_F_TSO_MANGLEID; As Eric Dumazet commented "This would prevent a device providing IPv4 checksum only (no IPv6 csum support) from sending IPv4 UDP GSO packets ?", so i send this series to decouple them. Is there any good ways to shuttle this issue? Or as you said there is not device only support checksum offload for one of the two network protocols. > Alternatively, the real value of splitting the type is in advertising > the features separately through ethtool. That requires additional > changes. > > . >