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 5C363A32A8 for ; Sat, 26 Oct 2019 18:45:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BA3FA1BF6D; Sat, 26 Oct 2019 18:45:42 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id CA17B1BF6D for ; Sat, 26 Oct 2019 18:45:41 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0B4BF220E7; Sat, 26 Oct 2019 12:45:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 26 Oct 2019 12:45:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=GV6gDIW+g/ZjwhUfLanrt35hqrh9lN6Zc23v4hxxPjo=; b=XhDTxq/Upy+q tvRzDBuVJg7vKrHLG9YJxP3WBBqdtc3SjzYxQstr+8cl8ySKjI+kDWobdNq+IqAE s/E3vmW6pOUfEKh1jwUSSxFpd05+XhENy6uubsOyhzsa5/21evQGhvkIrT3HqRrk KkRnGBzb8wyltHOxAKc0jlbPcswbL7w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=GV6gDIW+g/ZjwhUfLanrt35hqrh9lN6Zc23v4hxxP jo=; b=moEj0NEtHd2/wxxa+9y7jwi1X9FOnLmUnO8eZX2AMgxXBbzF3BU4Or21H DRDX5Wl6XYAj/g5ZFh3TYGxdrgciCpPUgQ4dqzl4/fV/GG8nYfu1H6chq8KPzqyr +ocqYYhhWdq3cEsCXz7VlMQ7lHfTcjME/ibtJKNbMadutWx4aCz4/203Usf9kMAr ZsiEsH2QpqXMDsG6iF0nbg01X7MoIzTTThqDIcr6gZQdlfkt4gmwhgQUvzSOjweX f+9X/YgGehfzbQSlYkl6aMhgCLHUaTQvGsK7pJn9jG1Jea/4FWpSZop0jkAFTpmF rUlGZe0e6Zzq61ejvsdLC8fWjB6pQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleehgddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2EEEE80059; Sat, 26 Oct 2019 12:45:38 -0400 (EDT) From: Thomas Monjalon To: Ray Kinsella , stephen@networkplumber.org, Haiyue Wang Cc: dev@dpdk.org, ferruh.yigit@intel.com, viacheslavo@mellanox.com, edwin.verplanke@intel.com Date: Sat, 26 Oct 2019 18:45:37 +0200 Message-ID: <8407813.BflZntU1Eb@xps> In-Reply-To: References: <1565665572-65495-1-git-send-email-haiyue.wang@intel.com> <20190812202436.662e6ca8@hermes.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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 automation. > > IMHO - this is much better implemented as a capability bitfield, that > can be queried. 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. And, more importantly, there is no need of automation or processing with this information.