[PATCH v3 0/2] ethdev: add the check for PTP capability

[lihuisong (C)]

在 2024/1/27 0:54, Ferruh Yigit 写道:
> On 1/11/2024 6:25 AM, lihuisong (C) wrote:
>> Hi Ferruh,
>>
>> 在 2023/11/23 19:56, lihuisong (C) 写道:
>>> 在 2023/11/2 7:39, Ferruh Yigit 写道:
>>>> timesync_read_rx_timestamp
>>>> On 9/21/2023 12:59 PM, lihuisong (C) wrote:
>>>>> add ice & igc maintainers
>>>>>
>>>>> 在 2023/9/21 19:06, Ferruh Yigit 写道:
>>>>>> On 9/21/2023 11:02 AM, lihuisong (C) wrote:
>>>>>>> Hi Ferruh,
>>>>>>>
>>>>>>> Sorry for my delay reply because of taking a look at all PMDs
>>>>>>> implementation.
>>>>>>>
>>>>>>>
>>>>>>> 在 2023/9/16 1:46, Ferruh Yigit 写道:
>>>>>>>> On 8/17/2023 9:42 AM, Huisong Li wrote:
>>>>>>>>>     From the first version of ptpclient, it seems that this example
>>>>>>>>> assume that
>>>>>>>>> the PMDs support the PTP feature and enable PTP by default.
>>>>>>>>> Please see
>>>>>>>>> commit ab129e9065a5 ("examples/ptpclient: add minimal PTP client")
>>>>>>>>> which are introduced in 2015.
>>>>>>>>>
>>>>>>>>> And two years later, Rx HW timestamp offload was introduced to
>>>>>>>>> enable or
>>>>>>>>> disable PTP feature in HW via rte_eth_rxmode. Please see
>>>>>>>>> commit 42ffc45aa340 ("ethdev: add Rx HW timestamp capability").
>>>>>>>>>
>>>>>>>> Hi Huisong,
>>>>>>>>
>>>>>>>> As far as I know this offload is not for PTP.
>>>>>>>> PTP and TIMESTAMP are different.
>>>>>>> If TIMESTAMP offload cannot stand for PTP, we may need to add one new
>>>>>>> offlaod for PTP.
>>>>>>>
>>>>>> Can you please detail what is "PTP offload"?
>>>>>>
>>>>> It indicates whether the device supports PTP or enable  PTP feature.
>>>>>
>>>> We have 'rte_eth_timesync_enable()' and 'rte_eth_timesync_disable()'
>>>> APIs to control PTP support.
>>> No, this is just to control it.
>>> we still need to like a device capablity to report application if the
>>> port support to call this API, right?
>>>> But when mention from "offload", it is something device itself does.
>>>>
>>>> PTP is a protocol (IEEE 1588), and used to synchronize clocks.
>>>> What I get is protocol can be parsed by networking stack and it can be
>>>> used by application to synchronize clock.
>>>>
>>>> When you are refer to "PTP offload", does it mean device (NIC)
>>>> understands the protocol and parse it to synchronize device clock with
>>>> other devices?
>>> Good point. PTP offload is unreasonable.
>>> But the capablity is required indeed.
>>> What do you think of introducing a RTE_ETH_DEV_PTP in
>>> dev->data->dev_flags for PTP feature?
>> Can you take a look at this discussion line again?
>>
>> Let's introduce a  RTE_ETH_DEV_PTP in dev->data->dev_flags to reveal if
>> the device support PTP feature.
>>
Hi Ferruh,

Thanks for taking your time to reply.

> Hi Huisong,
>
> First let me try to summarize the discussion since it has been some time.
>
> HW timer block can be used for Rx timestamp offload
> (RTE_ETH_RX_OFFLOAD_TIMESTAMP) and/or PTP support, but they are two
> different things.
>
> This patch uses 'RTE_ETH_RX_OFFLOAD_TIMESTAMP' capability for PTP
> support, which is wrong.
>
correct.
>
> After we agreed on above, your next question is to use 'dev_flag' to
> report PTP capability.
>
> First, can you please describe what is the motivation to learn if HW
> supports PTP or now, what is the benefit of knowing this.
There are a couple of device which have the same driver on a platform or OS.
But just allow one device to support or be responsible for PTP feature.
The firmware will report a capability to tell the device if it is 
support PTP.
But, currently, driver doesn't know how to report user which device 
support PTP feature.

In addition, many drivers use RTE_LIBRTE_IEEE1588 to control PTP code flow.
Whether the device supports PTP is irrelevant to this macro.
>
> If we agree that there is a need to know the PTP capability, question is
> where to report this capability.
>
> Suggested 'dev_flags' is used for various things, some are internal
> flags and some are status, I don't think overloading this variable is
> not good idea.
Yes, we need to consider  carefully.
>
> Other option is an update 'rte_eth_dev_info_get()' for it but it has the
> same problem, this function is already overloaded with many different
> things.
>
> We can have an API just to get PTP capability, but this will require a
> new dev_ops, this can be an option but my concern is having a capability
> dev_ops for each feature create a mess in dev_ops.
>
> Perhaps we can have single get_capability() API, and it gets features as
> flags to return if that feature is supported or not, but this requires a
> wider discussion.
>
> Instead can we deduce the capability from PTP relevant dev_ops, if they
> are implemented we can say it is supported? This doesn't require new
> support.
Thank you mentioning so many ways.
For the end of advice, I don't think it is appropriate.
Because we have to modify dynamically the pointer address of all PTP 
APIs in dev_ops on the above case.

How about we use rte_eth_dev_info.dev_capa to report PTP offload?
This is specifically used to report "Non-offload capabilities" according 
to its document.


>
> .