From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 72E7C1B462 for ; Sat, 16 Feb 2019 13:50:35 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2019 04:50:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,376,1544515200"; d="scan'208";a="116713787" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga006.jf.intel.com with ESMTP; 16 Feb 2019 04:50:32 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.72]) by IRSMSX103.ger.corp.intel.com ([169.254.3.199]) with mapi id 14.03.0415.000; Sat, 16 Feb 2019 12:50:31 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon CC: David Marchand , "Richardson, Bruce" , "dev@dpdk.org" , "Lu, Wenzhuo" , "Wu, Jingjing" , "Iremonger, Bernard" , Maxime Coquelin , "Yigit, Ferruh" , "Andrew Rybchenko" , "Wiles, Keith" Thread-Topic: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats Thread-Index: AQHUxVy+ySl801avPkWKPTgCEmdwhaXhMQuwgAAQbICAARtegA== Date: Sat, 16 Feb 2019 12:50:30 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258012413A7C2@irsmsx105.ger.corp.intel.com> References: <1550158972-21895-1-git-send-email-david.marchand@redhat.com> <2601191342CEEE43887BDE71AB977258012413A4D8@irsmsx105.ger.corp.intel.com> <6177115.1iB7W0vHcD@xps> In-Reply-To: <6177115.1iB7W0vHcD@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGQ3OGRkZGQtMzVkMS00ZThmLTliMTctMWRhMDBmNDkxMWNkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNlVzREZBQStROEp0VGlpb3ExSHdXS0I2dE1hV2ZRVDJSWjRCdzZLTzNvN1Y1VHBNQ29ERHFaM2JVRTY2UjZQRCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats 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: Sat, 16 Feb 2019 12:50:36 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Friday, February 15, 2019 7:39 PM > To: Ananyev, Konstantin > Cc: David Marchand ; Richardson, Bruce ; dev@dpdk.org; Lu, Wenzhuo > ; Wu, Jingjing ; Iremonger, = Bernard ; Maxime Coquelin > ; Yigit, Ferruh ; Andrew Ryb= chenko ; Wiles, Keith > > Subject: Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit err= ors stats >=20 > 15/02/2019 19:42, Ananyev, Konstantin: > > >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of David Marchand > > >>> I am also for option 2 especially because of this. > > >>> A driver that refuses a packet for reason X (which is a limitation,= or an > > >>> incorrect config or whatever that is not a transient condition) but= gives > > >>> it back to the application is a bad driver. > > > > >>Why? What.s wrong to leave it to the upper layer to decide what to > > >>do with the packets that can't be sent (by one reason or another)? > > > > >How does the upper layer know if this is a transient state or somethin= g that can't be resolved? > > > > Via rte_errno, for example. >=20 > rte_errno is not a result per packet. Surely it is not. But tx_burst() can return after first failure. > I think it is better to "eat" the packet > as it is done for those transmitted to the HW. Probably extra clarification is needed here. Right now tx_burst (at least for PMDs I am aware about) doesn't do any checking that: - packet is correct and can be handled (this is responsibility of tx_prepare) - HW/PMD SW state is in valid and properly configured =20 (link is up, queue is configured, HW initialized properly). All that really tx_burst() care about -there is enough free TX descriptors to fill. When that happens - tx_burst() returns=20 straightway. So what particular error conditions are you talking about, and when you think we have to 'eat' the packets? Konstantin =20