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 A8A06A0579; Thu, 8 Apr 2021 14:05:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3ED4D40698; Thu, 8 Apr 2021 14:05:23 +0200 (CEST) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by mails.dpdk.org (Postfix) with ESMTP id 6047140138 for ; Thu, 8 Apr 2021 14:05:22 +0200 (CEST) Received: by mail-wr1-f44.google.com with SMTP id 12so1864155wrz.7 for ; Thu, 08 Apr 2021 05:05:22 -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:user-agent; bh=Bl42GuWFgFzkYQwbDDEC5wo5fxvws62XdwgkzhItzRY=; b=ARpJy0gqNv9iGztbFJjUHO2WXHzo1TAFy4gqwXBb+Ongl+U/+FL0PI/3M1NIMAxJit akLpx6gq7XrPjUVYx/aoo3hfKZgs1JPAYx9h1OkJuk0xdir9n3qgm7ATpfxKGAnqSxoa mZSta/dzgRGcR14mMnjxVRYERVhbivhoSAXKDQWaMS9fn003h32I76je/2fExsj7C7uI Rr0dWGgxtH0Vv6ApXz0PzQ4Xo3WBvfIljhh/YI5XEjwrpeZlhAwPA1n8lDX5WJfsJ9Vn 9rhavt6vU6iPIzqGA+HVWfRolXvlwfC9tO1FRSArSkwrVELdRREXmWTs42hd8f0A71Kt FvOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Bl42GuWFgFzkYQwbDDEC5wo5fxvws62XdwgkzhItzRY=; b=ZoPEUNENd2sASns0hcv5YCv0oRSS2GI2wpmLDnD7poUcltVoWE1JG0ovMG9auHYk8/ n2RYo0imCm2Ie0nsd+i6Xpa2duat1ttyXnXEK9Pp29sY2VjPDzp+eAV3eBJW1rJgxwMl 1ywCFi+tvCPKdGbqLm2EL7t1rwHJCjOqE4zfyQPCG/kc+92DNwNMQiABwHiSuA6h7mh0 TL83n20DNsYLth02kj+YXJmrH4uG1868eMLBOquPUQzhkY+09yGvaTM9E7wkZ5Pex9fg rCO9ABicASEOy2/fVufptmLaxgyhQdo34bjGvkENyaEwHFybny8al2lxQdKyd6MUu2KC 50gQ== X-Gm-Message-State: AOAM533UbZKD/iFF/+e87TkCceEOWr0VieYQRm8DGuvYKrKznxgqJ0K1 JD6ynhExh63G1P+pUgLPCxbirg== X-Google-Smtp-Source: ABdhPJxhKGDeAJQItr+TFoymSgP3OvbwdmHOPupd/b3NVaUnXJ3JTgXjZoMCPXY29JIl2Gm0Jc+8aw== X-Received: by 2002:a5d:64af:: with SMTP id m15mr10676671wrp.231.1617883522067; Thu, 08 Apr 2021 05:05:22 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id k16sm34024684wro.11.2021.04.08.05.05.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Apr 2021 05:05:21 -0700 (PDT) Date: Thu, 8 Apr 2021 14:05:21 +0200 From: Olivier Matz To: Flavio Leitner Cc: David Marchand , dev@dpdk.org, maxime.coquelin@redhat.com, i.maximets@ovn.org, Keith Wiles Message-ID: <20210408120521.GW1650@platinum> References: <20210401095243.18211-1-david.marchand@redhat.com> <20210401095243.18211-3-david.marchand@redhat.com> <20210408074159.GQ1650@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH 2/5] net/tap: do not touch Tx offload flags 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" On Thu, Apr 08, 2021 at 08:21:58AM -0300, Flavio Leitner wrote: > On Thu, Apr 08, 2021 at 09:41:59AM +0200, Olivier Matz wrote: > > On Wed, Apr 07, 2021 at 05:15:39PM -0300, Flavio Leitner wrote: > > > On Thu, Apr 01, 2021 at 11:52:40AM +0200, David Marchand wrote: > > > > Tx offload flags are of the application responsibility. > > > > Leave the mbuf alone and check for TSO where needed. > > > > > > > > Signed-off-by: David Marchand > > > > --- > > > > > > The patch looks good, but maybe a better approach would be > > > to change the documentation to require the TCP_CKSUM flag > > > when TCP_SEG is used, otherwise this flag adjusting needs > > > to be replicated every time TCP_SEG is used. > > > > > > The above could break existing applications, so perhaps doing > > > something like below would be better and backwards compatible? > > > Then we can remove those places tweaking the flags completely. > > > > As a first step, I suggest to document that: > > - applications must set TCP_CKSUM when setting TCP_SEG > > That's what I suggest above. > > > - pmds must suppose that TCP_CKSUM is set when TCP_SEG is set > > But that keeps the problem of implying the TCP_CKSUM flag in > various places. Yes. What I propose is just a first step: better document what is the current expected behavior, before doing something else. > > This is clearer that what we have today, and I think it does not break > > anything. This will guide apps in the correct direction, facilitating > > an eventual future PMD change. > > > > > diff --git a/lib/librte_mbuf/rte_mbuf_core.h b/lib/librte_mbuf/rte_mbuf_core.h > > > index c17dc95c5..6a0c2cdd9 100644 > > > --- a/lib/librte_mbuf/rte_mbuf_core.h > > > +++ b/lib/librte_mbuf/rte_mbuf_core.h > > > @@ -298,7 +298,7 @@ extern "C" { > > > * - if it's IPv4, set the PKT_TX_IP_CKSUM flag > > > * - fill the mbuf offload information: l2_len, l3_len, l4_len, tso_segsz > > > */ > > > -#define PKT_TX_TCP_SEG (1ULL << 50) > > > +#define PKT_TX_TCP_SEG (1ULL << 50) | PKT_TX_TCP_CKSUM > > > > > > /** TX IEEE1588 packet to timestamp. */ > > > #define PKT_TX_IEEE1588_TMST (1ULL << 51) > > > > I'm afraid some applications or drivers use extended bit manipulations > > to do the conversion from/to another domain (like hardware descriptors > > or application-specific flags). They may expect this constant to be a > > uniq flag. > > Interesting, do you have an example? Because each flag still has an > separate meaning. Honnestly no, I don't have any good example, just a (maybe unfounded) doubt. I have in mind operations that are done with tables or vector instructions inside the drivers, but this is mainly done for Rx, not Tx. You can look at Tx functions like mlx5_set_cksum_table() or nix_xmit_pkts_vector(), or Rx functions like desc_to_olflags_v() or enic_noscatter_vec_recv_pkts() to see what kind of stuff I'm talking about.