From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 811461B739 for ; Fri, 11 Jan 2019 09:36:01 +0100 (CET) Received: from rsa59-2-82-233-193-189.fbx.proxad.net ([82.233.193.189] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ghsJw-0004s9-9O; Fri, 11 Jan 2019 09:37:41 +0100 Received: by droids-corp.org (sSMTP sendmail emulation); Fri, 11 Jan 2019 09:35:47 +0100 Date: Fri, 11 Jan 2019 09:35:47 +0100 From: Olivier Matz To: Andrew Rybchenko Cc: Stephen Hemminger , Rami Rosen , Thomas Monjalon , Morten =?iso-8859-1?Q?Br=F8rup?= , dev@dpdk.org, ferruh.yigit@intel.com Message-ID: <20190111083547.btj6omdj7pp4aeqa@platinum> References: <98CBD80474FA8B44BF855DF32C47DC35B425B1@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35B425B8@smartserver.smartshare.dk> <3446539.r5cUhzCBca@xps> <20190110161158.0177a203@hermes.lan> <73285400-c67b-48cf-88be-b20bb05b5484@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73285400-c67b-48cf-88be-b20bb05b5484@solarflare.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [RFC] function to parse packet headers X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 08:36:01 -0000 Hi, On Fri, Jan 11, 2019 at 10:56:11AM +0300, Andrew Rybchenko wrote: > On 1/11/19 3:11 AM, Stephen Hemminger wrote: > > On Thu, 10 Jan 2019 03:03:24 +0200 > > Rami Rosen wrote: > > > > > Hi, Morten, > > > > > > > And regarding avoiding code duplicity, I'm pursuing Olivier about merging > > > packet header validation into rte_net_get_ptype() instead of writing a > > > separate function. > > > This seems also a good alternative. > > > +1 Thanks Morten for volunteering for this task. I also think that rte_net is the proper place. rte_net_get_ptype() is indeed quite similar, except that it won't return any length. So it may not be that easy to share the code between rte_net_get_ptype(). As an aside, the Rx and Tx offloads fields are distinct. In Rx we have the packet type that does not contain the length information, while in Tx we only have the lengths. I'm sure there will be some benefits to merge them, but it's another topic. About the function name, I feel "parse()" is a bit vague. What about something like rte_net_set_tx_offload(), rte_net_set_offload_lengths() or rte_net_set_tx_ol_len()? For the bulk API, marking invalid packets seems good, but I can't find a good place for the mark. Maybe setting m->tx_offload to INVALID (0xffffffff), or adding a specific flag. Any better idea is welcome ;) > > All drivers that don't have hardware support for getting l2/l3 and ptype > > information should be calling rte_net_get_ptype() already. > > Is it documented somewhere? I don't think it's mandatory. Each driver can announce its supported ptype through rte_eth_dev_get_supported_ptypes(). Olivier