From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C8459A052A for ; Tue, 2 Feb 2021 10:45:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B05A0240338; Tue, 2 Feb 2021 10:45:40 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id 61B54240336 for ; Tue, 2 Feb 2021 10:45:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612259138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JT6oGQnZ57lbAIeNAPNDp+zbxxWUwPjiDCnqJlLud+o=; b=GIwlKnPOLqDYu2mBVyiGXrE++cPjL97t3MdlO9D+H/Y6clFpuhrFn/4ofr9kaS5bkHkhQU 0i/3ASp0awc6zZuiRwQTPskQPQLtxKm+UF7jkwLHlonbjZpQwiEXtrKGc1URG3rltbgqPN zSEQDR/VJ4zO3gNTxIRymFrprc9wWv8= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-76-ncz-4CBGPH-lCqSSOLmfrA-1; Tue, 02 Feb 2021 04:45:33 -0500 X-MC-Unique: ncz-4CBGPH-lCqSSOLmfrA-1 Received: by mail-vs1-f71.google.com with SMTP id z9so806915vsn.6 for ; Tue, 02 Feb 2021 01:45:33 -0800 (PST) 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; bh=JT6oGQnZ57lbAIeNAPNDp+zbxxWUwPjiDCnqJlLud+o=; b=aGdVJtIvwSEAtPhYvyRmu3dHlOO2bxMLVfGw0ZClVaDRQP4aD+S0r9QpjnYJjpSw+c l1DVjfaVDdCcVU2+e8+qbKQNd/xzxreRcZxVT8/mAAYLyuKNdQMByXx6td6ftyw0ROTX c5NbGIpEswZIg2Bz4ffO+rDNTND30fgOLWUez1lgQv7/9EyyPT6n0aUQ8/kNpYU3lVZr 1gG6uC397dKCjuUK7ZMSekCJCmEjSL8oEeAIu1CG34GM59sI4NO3mx+FuZZOD83/EUm7 FQF/V02uUYukHkFepUjSr6Y3UgMjALMxLDKz97yVpuPJ6XPSyCi5Zb5ijO7DcgqrL6MS FGCw== X-Gm-Message-State: AOAM530QoQ4A36fvO9/+q/0n5jANW0AIR+3Q1akKfI9EW9rPpW/lORya /1qsC5gijTPJQ0i2xTiMCc9+Wm7kPRe7PeyhPJwCQ+y8xXackWwSk+5Fb2TOeQ7+EEqFfgDK11g xNqRSW5nn8ZqTwzTvxOKnE9s= X-Received: by 2002:ab0:2356:: with SMTP id h22mr11324546uao.86.1612259133418; Tue, 02 Feb 2021 01:45:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJzQaZaWqWb7PvtGmxhQvuYjlDDWVx47UzxBAqLLb0HKDws1oYwSucTkE8DzKjhaAXTkYivV74uo3I0Cvc0htE4= X-Received: by 2002:ab0:2356:: with SMTP id h22mr11324530uao.86.1612259133111; Tue, 02 Feb 2021 01:45:33 -0800 (PST) MIME-Version: 1.0 References: <20210202070652.145861-1-haiyue.wang@intel.com> In-Reply-To: <20210202070652.145861-1-haiyue.wang@intel.com> From: David Marchand Date: Tue, 2 Feb 2021 10:45:21 +0100 Message-ID: To: Haiyue Wang Cc: dev , pvalerio@redhat.com, Aaron Conole , Qi Zhang , Leyi Rong , "Tu, Lijuan" , dpdk stable , Jeff Guo , Bruce Richardson , Konstantin Ananyev , Jerin Jacob Kollanukkaran , "Ruifeng Wang (Arm Technology China)" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-stable] [PATCH v1] net/ixgbe: adjust error for UDP with zero checksum X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hello Haiyue, Thanks for working on it quickly. Cc: ARM maintainers. On Tue, Feb 2, 2021 at 8:23 AM Haiyue Wang wrote: > > There is an 82599 errata that UDP frames with a zero checksum are > incorrectly marked as checksum invalid by the hardware. This was Maybe add a reference to the 82599 hw errata, is this listed in the datasheet? > leading to misleading PKT_RX_L4_CKSUM_BAD flag. This patch adds a > test around this checksum error flag set for this condition. > > 1. UDP Test > sendp(Ether()/IP()/UDP(chksum=0)/Raw("a"*100), iface="ens802f0") > port 0/queue 0: received 1 packets > ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD > > 2. TCP Test > sendp(Ether()/IP()/TCP(chksum=0)/Raw("a"*100), iface="ens802f0") > port 0/queue 0: received 1 packets > ol_flags: PKT_RX_L4_CKSUM_BAD PKT_RX_IP_CKSUM_GOOD > > Bugzilla ID: 629 The problem has always been present, so I would flag: Fixes: af75078fece3 ("first public release") > Cc: stable@dpdk.org > Reported-by: Paolo Valerio > Signed-off-by: Haiyue Wang > --- > doc/guides/nics/ixgbe.rst | 6 ++++ > drivers/net/ixgbe/ixgbe_rxtx.c | 27 +++++++++++--- > drivers/net/ixgbe/ixgbe_rxtx.h | 2 ++ > drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 49 ++++++++++++++++++++------ > 4 files changed, 70 insertions(+), 14 deletions(-) > > diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst > index 696cbd93b..de210b7b8 100644 > --- a/doc/guides/nics/ixgbe.rst > +++ b/doc/guides/nics/ixgbe.rst > @@ -287,6 +287,12 @@ the VFs which are required.:: > Currently hot-plugging of representor ports is not supported so all required > representors must be specified on the creation of the PF. > > +Limitations or Known issues > +--------------------------- > +The 82599 hardware errata: UDP frames with a zero checksum can be marked as > +checksum errors. To support zero checksum, the UDP checksum is always marked > +as good. > + If the driver/hw can't report a valid checksum hint, it should announce it does not know if the checksum is valid (neither bad, nor good). So the workaround for udp packets (on this hw model) would be to report PKT_RX_L4_CKSUM_UNKNOWN. The sw application will then have to recompute the checksum itself if needed. -- David Marchand