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 E68BDA0C4B; Thu, 14 Oct 2021 17:46:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CC5C641219; Thu, 14 Oct 2021 17:46:07 +0200 (CEST) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by mails.dpdk.org (Postfix) with ESMTP id 719054112E for ; Thu, 14 Oct 2021 17:46:06 +0200 (CEST) Received: by mail-wr1-f54.google.com with SMTP id v17so20835492wrv.9 for ; Thu, 14 Oct 2021 08:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mjT6KqicuTvQYtUru04pBTnAxf3PLRSSMEbIDDEs+7E=; b=O8PYLmH6GGMaEtM4uVEfEOS5vYhttwe61ba2cp+NHinbl7yDtfMiDRm4d0d6AfCly8 xlfgLLEI34icRmkQrJsgQUTZUPmccWsfEgqggd4BW3XGV+swr/XFNvtjQ+U3aBwZg0jw EYA1ollo4NHsF9pi4CegtbvDwtTA6fd5Avmxkr8Re37JydRTLPJqzKdM8MPuoQmeW/Qr r4hYdZ5LlxUP5hWSJ/t7qWSJpYlbvPrAW8JMjEi4nzU4oPA9BR6sKD+iOrzY+cpD7HO4 V68jXFBnq+v6C+8/81qIwOIZi3q4t8gDyYHO9cUNm63n8cvsyxqBfVUwI1W/sa9QZNpf 1fjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mjT6KqicuTvQYtUru04pBTnAxf3PLRSSMEbIDDEs+7E=; b=L6ADtqNQbif4L/Bpl7suSfdAR+bZL1tfQQJRhGla6ZnzXm6NWvBqeRtJ8kHTNAOYf9 KfUtHHofrvDNaQJ6J3RtHihVt0MDJUNXZKYGga4LudqMCqD/Il9JBqPq+mNtsSeeDRbw uDN2fJ8Qaq7JYGETf1gIvLrDKORpoxmtJ4hJr5aAFqSRpqH5YX4HiJJdMwgT1CTShMMc RbZNEHmroiANbTcIsPggwZsCeIo4Hp+htW4xAT/lKwaF7PXgvjhTeQfYhikL4FrkEsbL sAiVN4LBFESw5cknAr627OAiE7I8W+MqNQaA4HTVMareIIrM2rmDqWOyMxvccqjWPRWt +/hw== X-Gm-Message-State: AOAM530D0X/FDdc4G3ODikObggMvO3ZI5ZhDWdj5sOGKZsAprd1vfsXe Es5Ag2KZ5eBhcZyv0YTZ6W+tuQ== X-Google-Smtp-Source: ABdhPJx7MuDJKsbH3ol7HEvrUIi2IaW3/mMpICHQaoDlA/1C49YhAKXpFUwbs3WFbN0NlutgnyWCpw== X-Received: by 2002:adf:e0cc:: with SMTP id m12mr7735277wri.62.1634226365987; Thu, 14 Oct 2021 08:46:05 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id 10sm4853847wme.27.2021.10.14.08.46.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 08:46:04 -0700 (PDT) Date: Thu, 14 Oct 2021 17:46:03 +0200 From: Olivier Matz To: Radu Nicolau Cc: dev@dpdk.org, Declan Doherty Message-ID: References: <20210903105942.265501-1-radu.nicolau@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210903105942.265501-1-radu.nicolau@intel.com> Subject: Re: [dpdk-dev] [PATCH] net: add support for UDP segmentation case X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Radu, On Fri, Sep 03, 2021 at 11:59:42AM +0100, Radu Nicolau wrote: > [PATCH] net: add support for UDP segmentation case What about this title instead? net: exclude IP len from phdr cksum if offloading UDP frag > Add support to the ipv4/ipv6 pseudo-header function when TSO is enabled > in the UDP case, eg PKT_TX_UDP_SEG is set in the mbuf ol_flags I think it would be clearer to say "UDP fragmentation" instead of "TSO is enabled in the UDP case". > Signed-off-by: Declan Doherty > Signed-off-by: Radu Nicolau > --- > lib/net/rte_ip.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h > index 05948b69b7..c916ec1b09 100644 > --- a/lib/net/rte_ip.h > +++ b/lib/net/rte_ip.h > @@ -333,7 +333,7 @@ rte_ipv4_phdr_cksum(const struct rte_ipv4_hdr *ipv4_hdr, uint64_t ol_flags) > psd_hdr.dst_addr = ipv4_hdr->dst_addr; > psd_hdr.zero = 0; > psd_hdr.proto = ipv4_hdr->next_proto_id; > - if (ol_flags & PKT_TX_TCP_SEG) { > + if (ol_flags & (PKT_TX_TCP_SEG | PKT_TX_UDP_SEG)) { > psd_hdr.len = 0; > } else { > l3_len = rte_be_to_cpu_16(ipv4_hdr->total_length); Can you also update the API comment? > @@ -474,7 +474,7 @@ rte_ipv6_phdr_cksum(const struct rte_ipv6_hdr *ipv6_hdr, uint64_t ol_flags) > } psd_hdr; > > psd_hdr.proto = (uint32_t)(ipv6_hdr->proto << 24); > - if (ol_flags & PKT_TX_TCP_SEG) { > + if (ol_flags & (PKT_TX_TCP_SEG | PKT_TX_UDP_SEG)) { > psd_hdr.len = 0; > } else { > psd_hdr.len = ipv6_hdr->payload_len; > -- > 2.25.1 > No objection for this patch, but I think we should consider removing this ol_flags parameter from the pseudo header checksum calculation functions in the future, because it is a bit confusing. Historically, this was done in commit 4199fdea60c3 ("mbuf: generic support for TCP segmentation offload") because we were expecting that this pseudo-header checksum (required by Intel hw when doing checksum or TSO) will be done in the same way for many drivers (i.e. without the IP length for TSO). I don't know if it is the case. Or maybe a 'use_0_length' parameter would make more sense than 'ol_flags'. Thanks, Olivier