From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4FF75A2F67 for ; Sun, 27 Oct 2019 05:10:47 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7D4E41BF44; Sun, 27 Oct 2019 05:10:46 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 2ABD11BF42 for ; Sun, 27 Oct 2019 05:10:43 +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 fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2019 21:10:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,234,1569308400"; d="scan'208";a="373918057" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga005.jf.intel.com with ESMTP; 26 Oct 2019 21:10:42 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sat, 26 Oct 2019 21:10:41 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sat, 26 Oct 2019 21:10:41 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.176]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.165]) with mapi id 14.03.0439.000; Sun, 27 Oct 2019 12:10:39 +0800 From: "Wang, Haiyue" To: Thomas Monjalon , Ray Kinsella , "stephen@networkplumber.org" CC: "dev@dpdk.org" , "Yigit, Ferruh" , "viacheslavo@mellanox.com" , "Verplanke, Edwin" Thread-Topic: [dpdk-dev] [RFC v2 1/3] ethdev: add the API for getting trace information Thread-Index: AQHVUYTDT/0YGy+MOU67JpkccwCfnab35B0AgACeXoCAdI31gIABQdGg Date: Sun, 27 Oct 2019 04:10:39 +0000 Message-ID: References: <1565665572-65495-1-git-send-email-haiyue.wang@intel.com> <20190812202436.662e6ca8@hermes.lan> <8407813.BflZntU1Eb@xps> In-Reply-To: <8407813.BflZntU1Eb@xps> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGJkZjkxZTUtOWRiZC00MzAxLThiZGUtOGJhNDk1OTZmNTg3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoib0daWXVqTitZaFdOV0JFbTkwWTVnNExkWkRKUXBTTW9ucFwvak5UbFdmd3h4N2RKakhDWmswM1VXRVFXRVZrZVcifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action 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] [RFC v2 1/3] ethdev: add the API for getting trace information 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Sunday, October 27, 2019 00:46 > To: Ray Kinsella ; stephen@networkplumber.org; Wang, Haiyu= e > Cc: dev@dpdk.org; Yigit, Ferruh ; viacheslavo@mel= lanox.com; Verplanke, Edwin > > Subject: Re: [dpdk-dev] [RFC v2 1/3] ethdev: add the API for getting trac= e information >=20 > 13/08/2019 14:51, Ray Kinsella: > > On 13/08/2019 04:24, Stephen Hemminger wrote: > > > On Tue, 13 Aug 2019 11:06:10 +0800 > > > Haiyue Wang wrote: > > > > > >> Enhance the PMD to support retrieving trace information like > > >> Rx/Tx burst selection etc. > > >> > > >> Signed-off-by: Haiyue Wang > [...] > > >> int > > >> +rte_eth_trace_info_get(uint16_t port_id, uint16_t queue_id, > > >> + enum rte_eth_trace type, char *buf, int sz) > [...] > > > The bigger problem is that this information is like a log message > > > and unstructured, which makes it device specific and useless for auto= mation. > > > > IMHO - this is much better implemented as a capability bitfield, that > > can be queried. >=20 > Now I see where this idea comes from. > Ray, Stephen, structuring shuch information is really a bad idea. > The Rx/Tx functions are not like capabilities, they are full of smart > tricks written by brillant engineers. Please do not try to put ideas > in some categories. We will have more and more new types of optimization > and ideas when the hardware will evolve. >=20 > And, more importantly, there is no need of automation or processing > with this information. >=20 The real requirement is from VPP CLI practice in production: http://www.jimmdenton.com/vpp-1810-mellanox/ tx burst function: xxx rx burst function: xxx Their implementation requires *non static* rx/tx burst. Yes, MLX uses an template compile for extreme performance. ---- * @param olx * Configured offloads mask, presents the bits of MLX5_TXOFF_CONFIG_xxx * values. Should be static to take compile time static configuration * advantages. * * @return * Number of packets successfully transmitted (<=3D pkts_n). */ static __rte_always_inline uint16_t mlx5_tx_burst_tmpl(struct mlx5_txq_data *restrict txq, struct rte_mbuf **restrict pkts, uint16_t pkts_n, unsigned int olx) ---- What we design is from another kind of thinking from CPU's point view: commit 2e542da709371ee51d61d74c9a1b357ad34ae13e Author: David Christensen Date: Fri Aug 16 12:56:04 2019 -0500 net/mlx5: add Altivec Rx Added mlx5_rxtx_vec_altivec.h which supports vectorized RX using Altivec vector code. Modified associated build files to use the new code. Signed-off-by: David Christensen Acked-by: Viacheslav Ovsiienko Tested-by: Raslan Darawsheh