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=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,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 30452C282C7 for ; Tue, 29 Jan 2019 04:02:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E672F20869 for ; Tue, 29 Jan 2019 04:02:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com header.i=@herbertland-com.20150623.gappssmtp.com header.b="JYR1o7Eg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727032AbfA2ECG (ORCPT ); Mon, 28 Jan 2019 23:02:06 -0500 Received: from mail-qt1-f195.google.com ([209.85.160.195]:46493 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726762AbfA2ECG (ORCPT ); Mon, 28 Jan 2019 23:02:06 -0500 Received: by mail-qt1-f195.google.com with SMTP id y20so20808868qtm.13 for ; Mon, 28 Jan 2019 20:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/KbBTy4zaLzzrBebwBDsfi8+Y3oNz4qZh0fuJbV8ySk=; b=JYR1o7EgUdOIF3a6J3hRDvM4zcFk+d8k9pdGlVLitbX3hMLeZVXTbaab44+l5lod3F wM9wCtonNfDVmOYCmZUkOBc7Y8WvX1xNIuKW3uRT4fR475Gjul3InG85QPW9K7FCOhHG oTylz/iSJLcyqzkvh5GjfjY9xKgHmx8/bBCOuTpTCopRBpQUQS+0hmeTu/E3oM9z1KTT E3wVPzRffo76WlNNWTcvluI3bRYZwkKSDC1F79B+zFQ1f5OtbwxskZTkCsj22dGRJ6I+ zTTFb8fPquUIWoSJD4XIy3U3yvzHDrAYEoaOWYi/3+ba0AJnjuAaea1pEpejd1hMG0Vx LGzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/KbBTy4zaLzzrBebwBDsfi8+Y3oNz4qZh0fuJbV8ySk=; b=rByMR51/yxQWA5Ir4UGgTnRWuMSBksM1RhpB3HqJxK76byQbsLV9q3Ffj4fX/FrzSy x5eos0zyRjJWwMRRMDfOq6dYjN5YIGp+7mqAUuaOo7rBaZTNSfEHp/jBBPGJRmbjTQCE NjKQ8G1xNvGIccJQBSEhfuGv26jB61znPh9Q5Jz8o61EYcduY9+T63yAW7PVmFaqevR6 o2LwD6jD7eJNDNUW2w0ogXwbTJyw1yEm8sD2czPGbwWj4Qec1a4Lr1PjmfuJC9FW6PNS 6wfuGv5MC8/oiSui/txmqmjMrUSewpiYWh4OHuoOzZopGhMydqSrFdma7HjUYIXgzKKo Y72Q== X-Gm-Message-State: AJcUukeJwyYet5yPuW6BvKsK/7/eJPU3r8+IAWd22M760R9GkUntqpSU LXaSyDkoMgD21YHJEglGvH94hxTomi3KfrrmiSawjw== X-Google-Smtp-Source: ALg8bN5Sh9Atn9ykp0FAB8hH2LGV3amkw3Ij2Q0pXkrClVjxPGrNzclR7KbEYbKasqut10OepxadY+4TmvWykeFQSdc= X-Received: by 2002:a0c:f584:: with SMTP id k4mr23059444qvm.22.1548734524569; Mon, 28 Jan 2019 20:02:04 -0800 (PST) MIME-Version: 1.0 References: <1548214428-114642-1-git-send-email-maowenan@huawei.com> In-Reply-To: From: Tom Herbert Date: Mon, 28 Jan 2019 20:01:53 -0800 Message-ID: Subject: Re: [PATCH net-next] net: udp Allow CHECKSUM_UNNECESSARY packets to do GRO. To: maowenan Cc: Linux Kernel Network Developers , "David S. Miller" , Eric Dumazet Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Jan 28, 2019 at 7:00 PM maowenan wrote: > > Hi all=EF=BC=8C > 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=3D0, > > skb_gro_checksum_validate_zero_check() will set the > > skb->ip_summed =3D CHECKSUM_UNNECESSARY; > > skb->csum_level =3D 0; > > Then udp_gro_receive() will flush the packet which is not CHECKSUM_PART= IAL, > > It is not our expect, because check=3D0 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 p= ath. > > */ > > __skb_incr_checksum_unnecessary(skb); > > + NAPI_GRO_CB(skb)->csum_cnt =3D 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 !=3D CHECKSUM_PARTIAL && NAPI_GRO_CB(skb)->csum_cnt =3D=3D 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.