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 02495A052A for ; Tue, 2 Feb 2021 18:42:45 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DE38424036F; Tue, 2 Feb 2021 18:42:45 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id 23F2924036F for ; Tue, 2 Feb 2021 18:42:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612287763; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=7xpXPh/JJ5EBsVHVxhKOyQiwtnzjPozPbKJJY5mir1U=; b=TiO7D/Hm2rO/PahxcLHK86d8V+cPjQBKcwl2Y/56BebmyTa9+I+XkXtsWpcS8c+3G74A5C 5SFaGjttH6sIo12M5zqT+LHYUWPeVJ4moSkTTz4e++H/06sXNIz3e31opwvChroMNTn8Js Ne8fVDZ6SU5nqgrfVPnUwMED4ZDXp04= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-373--fFXGFjQPgeRAsEJVK53RQ-1; Tue, 02 Feb 2021 12:42:40 -0500 X-MC-Unique: -fFXGFjQPgeRAsEJVK53RQ-1 Received: by mail-ed1-f71.google.com with SMTP id m16so9891531edd.21 for ; Tue, 02 Feb 2021 09:42:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:cc:subject:in-reply-to:date :message-id:mime-version; bh=7xpXPh/JJ5EBsVHVxhKOyQiwtnzjPozPbKJJY5mir1U=; b=e/VvW9bztIFgSGLjPnQyjYLWhofLE1QKiSs0IkUo0v6G9cMa6N5fnqQIzWG9E/NjEg RbL3JSGbWddXdKgVGTWySh3KHgXpwLczanOvdky10KjMGFSuLiP0X+izDhG/GW4NS8FO GYgmAD9NwyUH1GoibTi6viTu+pGrTviYTuNmd2DJ0OOLhSvoxAv5OShf/2df4xnGGqsZ RSpAo77LOGZO0xSYh2PxGevVpCA0DE1TQfA56Rqlta3COFJwgFJd8dAJIQzEzYS7kupg WDbxq3/BC1dL5LnJHoAepvukA14X9pkwFyy86lsal52FsZiG6OFH5RwFbsOeE26W31fZ EyXA== X-Gm-Message-State: AOAM530RKNC3sqgk9STTWzJ9SIOhfbgAs1ZCHrGA3dg0VOpPsmfGcIxs DjdbIzooKtFa1m0zcohqOUfiZ/v/4R20iMCqRYNbi/TToR78NeYRIvLdcngM02sIY4fba8R5tKt TZLirnaE= X-Received: by 2002:a17:906:ca04:: with SMTP id jt4mr3888770ejb.548.1612287759365; Tue, 02 Feb 2021 09:42:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJxoVnc3GrSZifyNigOS0jCn9tfuH3bcFoEJaZYAXi/M+MKCPj0liL77tSrkil+nzFk2smVwUg== X-Received: by 2002:a17:906:ca04:: with SMTP id jt4mr3888745ejb.548.1612287759139; Tue, 02 Feb 2021 09:42:39 -0800 (PST) Received: from localhost (net-37-116-32-78.cust.vodafonedsl.it. [37.116.32.78]) by smtp.gmail.com with ESMTPSA id m22sm1083614edp.63.2021.02.02.09.42.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 09:42:38 -0800 (PST) From: Paolo Valerio To: "Wang, Haiyue" , David Marchand Cc: dev , Aaron Conole , "Zhang, Qi Z" , "Rong, Leyi" , "Tu, Lijuan" , dpdk stable , "Guo, Jia" , "Richardson, Bruce" , "Ananyev, Konstantin" , Jerin Jacob Kollanukkaran , "Ruifeng Wang (Arm Technology China)" Cc: In-Reply-To: Date: Tue, 02 Feb 2021 18:42:34 +0100 Message-ID: <87o8h29xit.fsf@fed.void> MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pvalerio@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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" "Wang, Haiyue" writes: >> -----Original Message----- >> From: Wang, Haiyue >> Sent: Tuesday, February 2, 2021 20:57 >> To: David Marchand >> Cc: dev ; pvalerio@redhat.com; Aaron Conole ; Zhang, Qi Z >> ; Rong, Leyi ; Tu, Lijuan ; dpdk >> stable ; Guo, Jia ; Richardson, Bruce ; >> Ananyev, Konstantin ; Jerin Jacob Kollanukkaran ; >> Ruifeng Wang (Arm Technology China) >> Subject: RE: [PATCH v1] net/ixgbe: adjust error for UDP with zero checksum >> >> > -----Original Message----- >> > From: David Marchand >> > Sent: Tuesday, February 2, 2021 20:54 >> > To: Wang, Haiyue >> > Cc: dev ; pvalerio@redhat.com; Aaron Conole ; Zhang, Qi Z >> > ; Rong, Leyi ; Tu, Lijuan ; dpdk >> > stable ; Guo, Jia ; Richardson, Bruce >> ; >> > Ananyev, Konstantin ; Jerin Jacob Kollanukkaran ; >> > Ruifeng Wang (Arm Technology China) >> > Subject: Re: [PATCH v1] net/ixgbe: adjust error for UDP with zero checksum >> > >> > On Tue, Feb 2, 2021 at 1:42 PM Wang, Haiyue wrote: >> > > > 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. >> > > > >> > > >> > > Make sense, but not sure the vector path can handle this more easily. Will try. >> > >> > Refining this a bit. >> > It looks like hw correctly reports "good" checksums, so maybe instead >> > report PKT_RX_L4_CKSUM_UNKNOWN only for reports of "bad" checksums >> > from the hw? >> >> I guess Paolo will complain about the performance drop for zero checksum >> UDP. ;-) >> :) > > Deep into OVS for detail, 'PKT_RX_L4_CKSUM_UNKNOWN' is a graceful way. ;-) > Will work for this target. yes, validation gets skipped in such case. I'll be happy to test it once posted. > > /* Validation must be skipped if checksum is 0 on IPv4 packets */ > return (udp->udp_csum == 0 && key->dl_type == htons(ETH_TYPE_IP)) > || (validate_checksum ? checksum_valid(key, data, size, l3) : true); > >> > >> > -- >> > David Marchand