From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6120C169C4 for ; Tue, 29 Jan 2019 08:08:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BF380214DA for ; Tue, 29 Jan 2019 08:08:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726276AbfA2IIX (ORCPT ); Tue, 29 Jan 2019 03:08:23 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:40908 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725468AbfA2IIX (ORCPT ); Tue, 29 Jan 2019 03:08:23 -0500 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id ACA3FA8583297E51AC8B; Tue, 29 Jan 2019 16:08:21 +0800 (CST) Received: from [127.0.0.1] (10.177.96.96) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.408.0; Tue, 29 Jan 2019 16:08:19 +0800 Subject: Re: [PATCH net-next] net: udp Allow CHECKSUM_UNNECESSARY packets to do GRO. To: Tom Herbert References: <1548214428-114642-1-git-send-email-maowenan@huawei.com> <038cf844-ca2f-8db2-7ed6-fee39cbcfc7d@huawei.com> CC: Linux Kernel Network Developers , "David S. Miller" , Eric Dumazet From: maowenan Message-ID: Date: Tue, 29 Jan 2019 16:08:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.177.96.96] X-CFilter-Loop: Reflected Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2019/1/29 14:24, Tom Herbert wrote: > On Mon, Jan 28, 2019 at 10:04 PM maowenan wrote: >> >> >> >> On 2019/1/29 12:01, Tom Herbert wrote: >>> On Mon, Jan 28, 2019 at 7:00 PM maowenan wrote: >>>> >>>> Hi all， >>>> Do you have any comments about this change? >>>> >>>> >>>> On 2019/1/23 11:33, Mao Wenan wrote: >>>>> When udp4_gro_receive() get one packet that uh->check=0, >>>>> skb_gro_checksum_validate_zero_check() will set the >>>>> skb->ip_summed = CHECKSUM_UNNECESSARY; >>>>> skb->csum_level = 0; >>>>> Then udp_gro_receive() will flush the packet which is not CHECKSUM_PARTIAL, >>>>> It is not our expect, because check=0 in udp header indicates this >>>>> packet is no need to caculate checksum, we should go further to do GRO. >>>>> >>>>> This patch changes the value of csum_cnt according to skb->csum_level. >>>>> --- >>>>> include/linux/netdevice.h | 1 + >>>>> 1 file changed, 1 insertion(+) >>>>> >>>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h >>>>> index 1377d08..9c819f1 100644 >>>>> --- a/include/linux/netdevice.h >>>>> +++ b/include/linux/netdevice.h >>>>> @@ -2764,6 +2764,7 @@ static inline void skb_gro_incr_csum_unnecessary(struct sk_buff *skb) >>>>> * during GRO. This saves work if we fallback to normal path. >>>>> */ >>>>> __skb_incr_checksum_unnecessary(skb); >>>>> + NAPI_GRO_CB(skb)->csum_cnt = skb->csum_level + 1; >>> >>> That doesn't look right. This would be reinitializing the GRO >>> checksums from the beginning. >>> >>>>> } >>>>> } >>>>> >>>>> >>>> >>> I assume the code is bailing on this conditional: >>> >>> if (NAPI_GRO_CB(skb)->encap_mark || >>> (skb->ip_summed != CHECKSUM_PARTIAL && >>> NAPI_GRO_CB(skb)->csum_cnt == 0 && >>> !NAPI_GRO_CB(skb)->csum_valid) || >>> !udp_sk(sk)->gro_receive) >>> goto out_unlock; >>> >>> I am trying to remember why this needs to check csum_cnt. If there was >>> a csum_cnt for the UDP csum being zero from checksum-unnecessary, it >>> was consumed by skb_gro_checksum_validate_zero_check in UDP4 GRO >>> received. >> >> We have met the scene about two VMs in different host with vxlan packets, when udp4_gro_receive receives >> one packet with ip_summed=CHECKSUM_NONE,csum_cnt=0,csum_valid=0,and udp->check=0, then skb_gro_checksum_validate_zero_check()-> >> skb_gro_incr_csum_unnecessary() validate it and set ip_summed=CHECKSUM_UNNECESSARY,csum_level=0, but csum_cnt and csum_valid >> keep zero value. Then it will be flushed in udp_gro_receive(), the codes as you have showed. >> >> so I think it forgets to modify csum_cnt since csum_level is changed in skb_gro_incr_csum_unnecessary()->__skb_incr_checksum_unnecessary(). >> > Yes, but the csum_level is changing since we've gone beyond the > checksums initially reported inc checksum-unnecessary. GRO csum_cnt is > initialized to skb->csum_level + 1 at the start of GRO processing. > > If I recall, the rule is that UDP GRO requires at least one non-zero > checksum to be verified. The idea is that if we end up computing > packet checksums on the host for inner checksums like TCP during GRO, > then that's negating the performance benefits of GRO. Had UDP check > not been zero then we would do checksum unnecessary conversion and so > csum_valid would be set for the remainded of GRO processing. The > existing code is following the rule I believe, so this may be working > as intended. Do you have any suggestion if I need do GRO as udp->check is zero? My previous modification which works fine as below: if (NAPI_GRO_CB(skb)->encap_mark || (skb->ip_summed != CHECKSUM_PARTIAL && + skb->ip_summed != CHECKSUM_UNNECESSARY && NAPI_GRO_CB(skb)->csum_cnt == 0 && !NAPI_GRO_CB(skb)->csum_valid) || !udp_sk(sk)->gro_receive) goto out_unlock; > > Tom > >>> >>> . >>> >> > > . >