From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Hemant Agrawal <hemant.agrawal@nxp.com>,
"lihuisong (C)" <lihuisong@huawei.com>,
"dev@dpdk.org" <dev@dpdk.org>, Gagandeep Singh <G.Singh@nxp.com>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
"liuyonglong@huawei.com" <liuyonglong@huawei.com>
Subject: Re: [PATCH v3 0/2] ethdev: add the check for PTP capability
Date: Wed, 1 Nov 2023 23:39:42 +0000 [thread overview]
Message-ID: <8bac319f-6abd-450d-a103-f8c4db753eb8@amd.com> (raw)
In-Reply-To: <DB9PR04MB93321BAF2A97E5DDE3EBC9D689F8A@DB9PR04MB9332.eurprd04.prod.outlook.com>
On 9/21/2023 12:17 PM, Hemant Agrawal wrote:
> HI Ferruh,
>
>> 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"?
>>
>>>>
>>>> PTP is a protocol for time sync.
>>>> Rx TIMESTAMP offload is to ask HW to add timestamp to mbuf.
>>> Yes.
>>> But a lot of PMDs actually depand on HW to report Rx timestamp
>>> releated information because of reading Rx timestamp of PTP SYNC
>>> packet in read_rx_timestamp API.
>>>
>>
>> HW support may be required for PTP but this doesn't mean timestamp
>> offload is used.
>
>>
>>>>
>>>>> And then about four years later, ptpclient enable Rx timestamp
>>>>> offload because some PMDs require this offload to enable. Please see
>>>>> commit 7a04a4f67dca ("examples/ptpclient: enable Rx timestamp
>> offload").
>>>>>
>>>> dpaa2 seems using TIMESTAMP offload and PTP together, hence they
>>>> updated ptpclient sample to set TIMESTAMP offload.
>
> [Hemant] In case of dpaa2, we need to enable HW timestamp for PTP. In the current dpaa2 driver
> If the code is compiled with, RTE_LIBRTE_IEEE1588, we are enabling the HW timestamp
> Otherwise, we are only enabling it when the TIMESTAMP offload is selected.
>
I think this is reasonable, HW timestamp enabled only when required.
> We added patch in ptpclient earlier to pass the timestamp offload, however later we also updated the driver to do it by default.
>
This part I am not sure,
so application request TIMESTAMP offload enable HW timestamp to use it
for PTP.
There are already 'rte_eth_timesync_enable()' and
'rte_eth_timesync_disable()' functions, and ptpclient sample already
uses them, why now utilize these APIs to enable HW timestamp, or other
related configuration?
>
>>> There are many PMDs doing like this, such as ice, igc, cnxk, dpaa2,
>>> hns3 and so on.
>>>
>>
>> Can you please point the ice & igc code, cc'ing their maintainers, we can look
>> together?
>>
>>
>>>>
>>>> We need to clarify dpaa2 usage.
>>>>
>>>>> By all the records, this is more like a process of perfecting PTP
>>>>> feature.
>>>>> Not all network adaptors support PTP feature. So adding the check
>>>>> for PTP capability in ethdev layer is necessary.
>>>>>
>>>> Nope, as PTP (IEEE1588/802.1AS) implemented as dev_ops, and ops
>>>> already checked, so no additional check is needed.
>>> But only having dev_ops about PTP doesn't satisfy the use of this feature.
>>> For example,
>>> there are serveal network ports belonged to a driver on one OS, and
>>> only one port support PTP function.
>>> So driver needs one *PTP* offload.
>>>>
>>>> We just need to clarify TIMESTAMP offload and PTP usage and find out
>>>> what is causing confusion.
>>> Yes it is a little bit confusion.
>>> There are two kinds of implementation:
>>> A： ixgbe and txgbe (it seems that their HW is similar) don't need
>>> TIMESTAMP offload，and only use dev_ops to finish PTP feature.
>>> B: saving "Rx timestamp related information" from Rx description when
>>> receive PTP SYNC packet and
>>> report it in read_rx_timestamp API.
>>> For case B, most of driver use TIMESTAMP offload to decide if driver
>>> save "Rx timestamp related information.
>>> What do you think about this, Ferruh?
>>>> I would be great if you can help on clarification, and update
>>>> documentation or API comments, or what ever required, for this.
>>> ok
>>>>
>>>>> ---
>>>>> v3:
>>>>> - patch [2/3] for hns3 has been applied and so remove it.
>>>>> - ops pointer check is closer to usage.
>>>>>
>>>>> Huisong Li (2):
>>>>> examples/ptpclient: add the check for PTP capability
>>>>> ethdev: add the check for the valitity of timestamp offload
>>>>>
>>>>> examples/ptpclient/ptpclient.c | 5 +++
>>>>> lib/ethdev/rte_ethdev.c | 57
>>>>> +++++++++++++++++++++++++++++++++-
>>>>> 2 files changed, 61 insertions(+), 1 deletion(-)
>>>>>
>>>> .
>
next prev parent reply other threads:[~2023-11-01 23:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 13:39 [PATCH 0/3] some bugfixes for PTP Dongdong Liu
2022-06-28 13:39 ` [PATCH 1/3] examples/ptpclient: add the check for PTP capability Dongdong Liu
2022-06-28 13:39 ` [PATCH 2/3] net/hns3: fix fail to receive PTP packet Dongdong Liu
2022-06-28 13:39 ` [PATCH 3/3] ethdev: add the check for the valitity of timestamp offload Dongdong Liu
2022-07-02 8:17 ` [PATCH v2 0/3] some bugfixes for PTP Dongdong Liu
2022-07-02 8:17 ` [PATCH v2 1/3] examples/ptpclient: add the check for PTP capability Dongdong Liu
2022-07-02 8:17 ` [PATCH v2 2/3] net/hns3: fix fail to receive PTP packet Dongdong Liu
2022-07-02 8:17 ` [PATCH v2 3/3] ethdev: add the check for the valitity of timestamp offload Dongdong Liu
2022-07-06 14:57 ` Andrew Rybchenko
2022-07-07 2:05 ` lihuisong (C)
2023-08-17 8:42 ` [PATCH v3 0/2] ethdev: add the check for PTP capability Huisong Li
2023-08-17 8:42 ` [PATCH v3 1/2] examples/ptpclient: " Huisong Li
2023-09-15 17:29 ` Ferruh Yigit
2023-09-21 9:18 ` lihuisong (C)
2023-09-21 11:02 ` Ferruh Yigit
2023-09-21 11:22 ` Hemant Agrawal
2023-10-20 4:05 ` lihuisong (C)
2023-09-21 11:36 ` lihuisong (C)
2023-08-17 8:42 ` [PATCH v3 2/2] ethdev: add the check for the valitity of timestamp offload Huisong Li
2023-09-15 17:46 ` [PATCH v3 0/2] ethdev: add the check for PTP capability Ferruh Yigit
2023-09-21 10:02 ` lihuisong (C)
2023-09-21 11:06 ` Ferruh Yigit
2023-09-21 11:17 ` Hemant Agrawal
2023-10-20 3:58 ` lihuisong (C)
2023-11-01 23:39 ` Ferruh Yigit
2023-11-23 11:40 ` lihuisong (C)
2023-11-01 23:39 ` Ferruh Yigit [this message]
2023-09-21 11:59 ` lihuisong (C)
2023-11-01 23:39 ` Ferruh Yigit
2023-11-23 11:56 ` lihuisong (C)
2024-01-11 6:25 ` lihuisong (C)
2024-01-26 16:54 ` Ferruh Yigit
2024-01-27 1:52 ` lihuisong (C)
2024-01-29 11:16 ` Ferruh Yigit
2024-01-29 13:58 ` lihuisong (C)
2024-01-29 15:00 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8bac319f-6abd-450d-a103-f8c4db753eb8@amd.com \
--to=ferruh.yigit@amd.com \
--cc=G.Singh@nxp.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=lihuisong@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).