Re: [dpdk-dev] [PATCH 1/3] rte_ethdev: Add API function to read dev clock

[Ferruh Yigit <ferruh.yigit@intel.com>]

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