在 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-tho...@monjalon.net/
.
