From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 1EE191B505 for ; Tue, 8 Jan 2019 03:35:10 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2019 18:35:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,452,1539673200"; d="scan'208";a="112940654" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga007.fm.intel.com with ESMTP; 07 Jan 2019 18:35:09 -0800 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 7 Jan 2019 18:35:09 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 7 Jan 2019 18:35:08 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.63]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.196]) with mapi id 14.03.0415.000; Tue, 8 Jan 2019 10:35:07 +0800 From: "Hu, Jiayu" To: Stephen Hemminger CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] doc: add GRO API requirement in prog_guide Thread-Index: AQHUlom/EdJjZXdTCUuOuzpKSlAbQ6WfFi+AgAWjUrA= Date: Tue, 8 Jan 2019 02:35:06 +0000 Message-ID: References: <1545107119-85376-1-git-send-email-jiayu.hu@intel.com> <20190104113545.7d31a819@hermes.lan> In-Reply-To: <20190104113545.7d31a819@hermes.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGMyNzYzODktN2YxZS00ODg4LWE4NzQtMjBiM2YyNGRjODg1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTGZxV0ErUHZ1NFBzejR0TkFKZlNVQ0ZXdGVzdHdmZUNoQnBSYWFncFwvcHVQU0FOTHp0eVRNajBcL2p2c3o3ZTlQIn0= x-ctpclassification: CTP_NT x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] doc: add GRO API requirement in prog_guide 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: Tue, 08 Jan 2019 02:35:11 -0000 Hi Stephen, > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Saturday, January 5, 2019 3:36 AM > To: Hu, Jiayu > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] doc: add GRO API requirement in > prog_guide >=20 > On Tue, 18 Dec 2018 12:25:19 +0800 > Jiayu Hu wrote: >=20 > > +.. note:: > > + To use the GRO library, applications must guarantee that > > + MBUF->l2_len/l3_len/l4_len/outer_l2_len/outer_l3_len and > > + MBUF->pkt_len/data_len of input packets are set to correct > > + values. > > + >=20 > This statement seems confusing to me since > this is Generic Receive Offload, and receive buffers come from > the poll mode driver. >=20 > Aren't you saying that the PMD must set the correct values. > If this is correct, then any PMD not doing so is buggy. > And should be reported and fixed. If it is really buggy PMD's > then the statement in the programmers guide is not the place to handle > this kind of issue. Better to just shame the buggy drivers in the > release notes for that NIC. IMO, since GRO is a library, all input packets are from user applications. So I want to tell them that GRO relies on MBUF->l2_len/... to parse packets. If they want correct reassembly results, all those fields of= MBUF should be set correctly. If the packets are received by buggy PMDs and user applications directly pass them to GRO, GRO results are unknown. If the packets are received from correct PMDs, but user applications modify MBUF and make MBUF->l2_len/... incorrect, GRO results are still unknown. This statement is more like a programmer note. If you think it is confusing= , how do you think this one: GRO library uses MBUF->l2_len/... to parse packet headers. If the input pac= kets have incorrect values of MBUF->l2_len/.., GRO reassembly results are unknow= n. Thanks, Jiayu