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 EB73FA0579; Thu, 8 Apr 2021 14:58:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D6E49140FAC; Thu, 8 Apr 2021 14:58:42 +0200 (CEST) Received: from sysclose.org (smtp.sysclose.org [69.164.214.230]) by mails.dpdk.org (Postfix) with ESMTP id 33A3340698 for ; Thu, 8 Apr 2021 14:58:41 +0200 (CEST) Received: from localhost (unknown [45.71.105.250]) by sysclose.org (Postfix) with ESMTPSA id 2DDE62EF9; Thu, 8 Apr 2021 12:58:41 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 sysclose.org 2DDE62EF9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sysclose.org; s=201903; t=1617886721; bh=BtGUSuke3tSW6IhR7V5aR47fDz6eguAfIvJCNyMjtqo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=k1eNVh0Ux2G6sahAg83MCiPCgeobS+yqB2VfOsupyJQf9jVsaNllCP9Ck+3+66YBq K9Rnm7pqiI8Q4FxX8Kz5cTVKx0mNKhVovfkHzpzNbaGXadH9UFofsmyEdzcXIEX7UB M8PXP5/1GGY+rVkwMV7/m0e50fS8rnxPlV0rXSBIbmALL+vVPYy1B8s30w4EUJsZWI qY5mfGsp9vSYy0PTHvNbMAHLQ0m3mndr59n8OlX/dmO5hRaPY4daVRbFGo3k06ZTYB QPiXcqrvYKdrhG0XQdZ2gds25Xq44xaakeQwP2fqkK/fmYh8Dv1FsPHXeHgYdiNsah ifZ91ElcNFW2w== Date: Thu, 8 Apr 2021 09:58:35 -0300 From: Flavio Leitner To: Olivier Matz Cc: David Marchand , dev@dpdk.org, maxime.coquelin@redhat.com, i.maximets@ovn.org, Keith Wiles Message-ID: References: <20210401095243.18211-1-david.marchand@redhat.com> <20210401095243.18211-3-david.marchand@redhat.com> <20210408074159.GQ1650@platinum> <20210408120521.GW1650@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210408120521.GW1650@platinum> 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 02:05:21PM +0200, Olivier Matz wrote: > 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. I see your point. Going back to improving the documentation as a first step, what would be the next steps? Are we going to wait few releases and then remove the flag tweaking code assuming that PMDs and apps are ok? Thanks, -- fbl