From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id AC43C1B94B for ; Fri, 11 Jan 2019 10:49:39 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2019 01:49:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,465,1539673200"; d="scan'208";a="290739792" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga005.jf.intel.com with ESMTP; 11 Jan 2019 01:49:36 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.116]) by IRSMSX153.ger.corp.intel.com ([169.254.9.115]) with mapi id 14.03.0415.000; Fri, 11 Jan 2019 09:49:08 +0000 From: "Ananyev, Konstantin" To: Olivier Matz , Andrew Rybchenko CC: Stephen Hemminger , Rami Rosen , Thomas Monjalon , =?iso-8859-1?Q?Morten_Br=F8rup?= , "dev@dpdk.org" , "Yigit, Ferruh" Thread-Topic: [dpdk-dev] [RFC] function to parse packet headers Thread-Index: AdSncfX4daYkfyreRIS2nCcHGdzslwAHBykAAClcwwAAEOYbAAACSs8AADB+wQAAEDZsgAABYg2AAAHevqA= Date: Fri, 11 Jan 2019 09:49:07 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258010D902799@irsmsx105.ger.corp.intel.com> References: <98CBD80474FA8B44BF855DF32C47DC35B425B1@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35B425B8@smartserver.smartshare.dk> <3446539.r5cUhzCBca@xps> <20190110161158.0177a203@hermes.lan> <73285400-c67b-48cf-88be-b20bb05b5484@solarflare.com> <20190111083547.btj6omdj7pp4aeqa@platinum> In-Reply-To: <20190111083547.btj6omdj7pp4aeqa@platinum> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZGUzZjg4ZjQtZTEyYS00ZjUzLTk4ZDUtZmFjN2NhYjQ2NjFmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidEI0NzNxUGx5QzBzbUNkalE1dHBRZ2U2enV1XC9laGV3SzVmaUNOS25xamtmNkNNeEZ1SHBjek42S0VFcnBJWEMifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 09:49:40 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz > Sent: Friday, January 11, 2019 8:36 AM > To: Andrew Rybchenko > Cc: Stephen Hemminger ; Rami Rosen ; Thomas Monjalon > ; Morten Br=F8rup ; dev@dp= dk.org; Yigit, Ferruh > Subject: Re: [dpdk-dev] [RFC] function to parse packet headers >=20 > Hi, >=20 > 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 writin= g a > > > > separate function. > > > > This seems also a good alternative. > > > > +1 >=20 > 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(). >=20 > As an aside, the Rx and Tx offloads fields are distinct. In Rx we have th= e > 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. >=20 > About the function name, I feel "parse()" is a bit vague. What about some= thing > like rte_net_set_tx_offload(), rte_net_set_offload_lengths() or > rte_net_set_tx_ol_len()? >=20 > 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 ;) We probably can reset ptype to UKNOWN in that case, but my prefrence would be just group inavlid/unknown packets in some way (put them beyond good ones, move into different array, etc.) >=20 > > > All drivers that don't have hardware support for getting l2/l3 and pt= ype > > > information should be calling rte_net_get_ptype() already. > > > > Is it documented somewhere? >=20 > I don't think it's mandatory. Each driver can announce its supported ptyp= e > through rte_eth_dev_get_supported_ptypes(). + 1 It shouldn't be mandatory for PMD to do that. Konstantin