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

[lihuisong (C)]

在 2024/1/29 19:16, Ferruh Yigit 写道:
> On 1/27/2024 1:52 AM, lihuisong (C) wrote:
>> 在 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.
>>
> Driver can hold a private data that records if PTP supported by the
> device or not, and according this value PTP dev_ops can return error or
> success.
>
> This may not be ideal but it lets user to know about the support status,
> can this work?
I don't think it is user friendly.
Users know which port supports the PTP feature only when the API fails 
to be invoked, right?
In addition, this is a common issue for all supported PTP device. So It 
is better to do this check in PMD.
>
>
>> In addition, many drivers use RTE_LIBRTE_IEEE1588 to control PTP code flow.
>> Whether the device supports PTP is irrelevant to this macro.
>>
> Yes, I guess because both features use same HW, there is confusion there.
>
>>> 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.
>>
> I was thinking for the case application distinguish if PTP related
> dev_ops set or not, but after your explanation I can see this won't help
> for your case.
> Because in your case PTP dev_ops implemented but some devices support it
> and some don't, and you are looking for a way to distinguish it.
Yes
>
>> 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.
>>
> As mentioned above 'rte_eth_dev_info' is overloaded, I am for being more
> cautious to expand it more.
> Also I think it is a wider discussion if we want a capability reporting
> in ethdev and where it should be.
How about we send a RFC patch which use rte_eth_dev_info.dev_capa to 
report PTP offload and start to disscuss this issue?
And add Thomas's patch [1] and this patch.

[1]https://patchwork.dpdk.org/project/dpdk/patch/20230203132810.14187-1-thomas@monjalon.net/

>
> .