From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH 1/3] rte_ethdev: Add API function to read dev clock Date: Wed, 2 Jan 2019 17:44:39 +0000 Message-ID: References: <3811860b2a7b4bd2be2e9d3fd7de23c0@exdb05.ug.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "bruce.richardson@intel.com" , "john.mcnamara@intel.com" , Thomas Monjalon , Andrew Rybchenko , Yongseok Koh , Alejandro Lucero , Konstantin Ananyev To: Shahaf Shuler , Tom Barbette , "dev@dpdk.org" Return-path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 80C151B129 for ; Wed, 2 Jan 2019 18:44:44 +0100 (CET) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 12/23/2018 6:06 AM, Shahaf Shuler wrote: > Ferruh, > > I share the same thoughts as Tom here. > >   > >>Ferruh Yigit wrote : > >>> Is this a common enough feature to include into ethdev abstraction layer? Or a > >>> feature for a single vendor? > >>  > >>I found reference to mbuf’s timestamp field only in MLX5. I think it is the > only one to support timestamp offloading. This new API is only useful to make > sense out of the timestamp value. And without this patch, timestamp offloading > is completely useless… Why timestamp offloading become useless? When timestamp offloading enabled, device fills 'mbuf.timestamp' and you can use it. For your case this timestamp for mlx is device clock and you are adding this API to be able to convert device clock to real time, this is not something enables the timestamp offload. Technically driver can set the 'mbuf.timestamp' with the real clock right, if it is required? Or this can be defined by a devarg? Also this relates to how other HW vendors implemented this, if it is common approach to fill the timestamp with the device clock and there is way to clock reference from device, this may make sense. If other vendors already providing the real time on timestamp, this needs to be handled in mlx driver. That is why it is good to know what other vendors need / use this? > >>  > >>What would be the other way ? Define something in mlx5 header and ask clients > to check for the driver and call the specific API ? > >>  > >>I see reference to timestamp offloading in Netronome Agilio, CC-ing > maintainers. Is timestamp offloading a feature you could potentially provide ? > Would it be host time reference or a value that need conversion with an API like > this? > >   > > I don’t think that the number of vendors which implement the feature at current > time is the qualifier for a feature to enter. Rather we should consider how > generic it is and its need in the world of networking (since it is ethdev). > > IMO, It is perfectly reasonable to expose a generic channel to read the device > clock, same as reading device register (which exists). > The concern is ethdev bloats with single vendor specific APIs. In the past we moved some of the ethdev APIs as PMD specific APIs to PMDs. It is not nice to have "PMD specific APIs" but that was the trade off for more usable ethdev API. And according techboard discussion [1] for new API(): " If the API is about HW abstraction, at least one driver should be implemented. Preferably two. " I am questioning if is there possible second one, and how is their implementation is like. [1] https://mails.dpdk.org/archives/dev/2018-November/118697.html