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?
> 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.
> 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.
