All of lore.kernel.org
 help / color / mirror / Atom feed
From: "lihuisong (C)" <lihuisong@huawei.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>,
	Hemant Agrawal <hemant.agrawal@nxp.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: Thu, 23 Nov 2023 19:40:13 +0800	[thread overview]
Message-ID: <4ca421eb-3a0f-d629-801f-1b99a02a1387@huawei.com> (raw)
In-Reply-To: <d74aaaa7-1ccb-4a34-b7a7-6fcb647bea9f@amd.com>


在 2023/11/2 7:39, Ferruh Yigit 写道:
> On 10/20/2023 4:58 AM, lihuisong (C) wrote:
>> 在 2023/9/21 19:17, Hemant Agrawal 写道:
>>> 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.
>>>
>>> We added patch in ptpclient earlier to pass the timestamp offload,
>>> however later we also updated the driver to do it by default.
>>>
>>>
>> It is a little mess for PTP and RTE_LIBRTE_IEEE1588 to use.
>> Actually, whether PTP code is compiled should not depended on this macro
>> RTE_LIBRTE_IEEE1588.
>>
> There is already a patch by Thomas to remove RTE_LIBRTE_IEEE1588 [1],
> agree that this functionality needs some attention.
>
> Removing RTE_LIBRTE_IEEE1588 impact drivers, that is what holding us back.
+1 remove the compile macro RTE_LIBRTE_IEEE1588.
And hns3 had beed removed it.
>
>
> [1]
> https://patchwork.dpdk.org/project/dpdk/patch/20230203132810.14187-1-thomas@monjalon.net/
>
>> If there is a capability, it will be perfect, no matter whether it is
>> TIMESTAMP offload.
>> What do you think, Ferruh?
>>
> Difficulty is to know when to enable HW timestamp, and for some drivers
> this may change the descriptor format (to include timestamp), so driver
> should set correct datapath functions for this case.
Yes, to get Rx timestamp of PTP packet from descriptor for many NIC.
>
> We know when a HW timer is required, it is required for PTP protocol and
> required for TIMESTAMP offload.
TIMESTAMP offload may be unnecessary for some NIC which don't get Rx 
timestamp from descriptor(But, IMO, like this hardware is very rare.).
>
> What do you think to dynamically enable it for PTP when
> 'rte_eth_timesync_enable()' API called, and for TIMESTAMP offload when
> the offload is enabled.
Agree above.
At least, this can make sure all NIC can enable PTP feature.
> If this works, now new configuration item or offload is required, what
> do you think?
The new capability item is required to know if the port support PTP feature.
so application can enable/disable PTP based on this capability.
>
>>>>> 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(-)
>>>>>>>
>>>>>> .
> .

  reply	other threads:[~2023-11-23 11: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) [this message]
2023-11-01 23:39           ` Ferruh Yigit
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=4ca421eb-3a0f-d629-801f-1b99a02a1387@huawei.com \
    --to=lihuisong@huawei.com \
    --cc=G.Singh@nxp.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=hemant.agrawal@nxp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.