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 C5279A0547; Fri, 9 Apr 2021 18:55:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 67BC91410CB; Fri, 9 Apr 2021 18:55:29 +0200 (CEST) Received: from sysclose.org (smtp.sysclose.org [69.164.214.230]) by mails.dpdk.org (Postfix) with ESMTP id 5E4541410B6 for ; Fri, 9 Apr 2021 18:55:28 +0200 (CEST) Received: from localhost (unknown [45.71.105.250]) by sysclose.org (Postfix) with ESMTPSA id B28942F49; Fri, 9 Apr 2021 16:55:28 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 sysclose.org B28942F49 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sysclose.org; s=201903; t=1617987329; bh=ihvnDHlialhg1E/HsRFjORjmvN5rKtZuq+5glzCFcko=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=l2Xsy/ZbB/lh7DK696rStRzfFa9lBYUFBR2LgeZf2dyxxONostA6zgkXsrZAs1Zdm 10KnvyZtOcQVftuvu4+hOHBZM7nXxZJcgGNlbuBHNbnBLWg+b3yuWs2quVw6SNwSrB /68hr7arEH8LEzyq7cc18i/Tz0m4yzzdplF8fqpfhVR1UF+Ib+B++LZa1SHv4d1JUw 9M8L+V23x2YvRBjj+Y1rXk/JP4fWnsUkgZmROKqutgMhXLFhL3W1u343zSGmyz/XOB H93MMInuDXEduOqPpfCrONH7iDn/dyFoFmFPX2SzJhHRq9tLMN61GG8mSWzpbzR8NJ JnkVgMlsDn5bg== Date: Fri, 9 Apr 2021 13:55:21 -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> <20210409133018.GB1650@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210409133018.GB1650@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 Fri, Apr 09, 2021 at 03:30:18PM +0200, Olivier Matz wrote: > On Thu, Apr 08, 2021 at 09:58:35AM -0300, Flavio Leitner wrote: > > 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. [...] > > 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? > > After this documentation step, in few releases, we could relax the > constraint on PMD: applications will be expected to set TCP_CKSUM when > TCP_SEG is set, so no need for the PMD to force TCP_CKSUM to 1 if > TCP_SEG is set. The documentation will be updated again. > > This plan can be described in the deprecation notice, and later in the > release note. > > How does it sound? Works for me. Thanks, -- fbl