* [RFC] ethdev: introduce PTP device capability @ 2024-01-30 3:58 Huisong Li 2024-09-22 22:23 ` Ferruh Yigit 0 siblings, 1 reply; 6+ messages in thread From: Huisong Li @ 2024-01-30 3:58 UTC (permalink / raw) To: dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko; +Cc: ferruh.yigit Currently, the PTP feature is a little messy and has some issue. 1> There is different implementation for PTP. This feature of some hardware depends on the Rx HW timestamp offload, and use this offload to detect if enable PTP feature. Others can enable PTP feature with only ethdev ops. 2> For some drivers, enabling PTP feature also depends on the macro RTE_LIBRTE_IEEE1588. Actually, whether device support, enable or disable this feature should not be determined at compilation time. This has been discussed in thread [1]. 3> The user haven't a good way to distinguish which port supports the PTP feature in the case that a couple of device belong to the same driver. And PTP related API in ethdev layer doesn't do check for PTP capability. This has been mentioned and discussed in thread [2]. In the thread [1], there is a conclusion that remove the compiling macro RTE_LIBRTE_IEEE1588. And in the thread [2], there is a common opinion that the RTE_ETH_RX_OFFLOAD_TIMESTAMP cannot be used as the PTP capability. For the above issuse, this patch introduces a PTP capability in rte_eth_dev_info.dev_capa to report PTP capability. Welcome to jumping into discussion. [1] https://patchwork.dpdk.org/project/dpdk/patch/20230203132810.14187-1-thomas@monjalon.net/ [2] https://inbox.dpdk.org/dev/20230817084226.55327-1-lihuisong@huawei.com/ Signed-off-by: Huisong Li <lihuisong@huawei.com> --- lib/ethdev/rte_ethdev.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index efa4f12b2a..4c8bd691bd 100644 --- a/lib/ethdev/rte_ethdev.h +++ b/lib/ethdev/rte_ethdev.h @@ -1613,6 +1613,12 @@ struct rte_eth_conf { #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3) /** Device supports keeping shared flow objects across restart. */ #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4) +/** + * Device supports PTP feature. + * For some hardware, this feature also need to set the offload + * RTE_ETH_RX_OFFLOAD_TIMESTAMP, please check rte_eth_dev_info.rx_offload_capa. + */ +#define RTE_ETH_DEV_CAPA_PTP RTE_BIT64(5) /**@}*/ /* -- 2.30.0 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] ethdev: introduce PTP device capability 2024-01-30 3:58 [RFC] ethdev: introduce PTP device capability Huisong Li @ 2024-09-22 22:23 ` Ferruh Yigit 2024-09-24 7:24 ` lihuisong (C) 0 siblings, 1 reply; 6+ messages in thread From: Ferruh Yigit @ 2024-09-22 22:23 UTC (permalink / raw) To: Huisong Li, dev, Thomas Monjalon, Andrew Rybchenko On 1/30/2024 3:58 AM, Huisong Li wrote: > Currently, the PTP feature is a little messy and has some issue. > 1> There is different implementation for PTP. This feature of some > hardware depends on the Rx HW timestamp offload, and use this > offload to detect if enable PTP feature. Others can enable PTP > feature with only ethdev ops. > 2> For some drivers, enabling PTP feature also depends on the macro > RTE_LIBRTE_IEEE1588. Actually, whether device support, enable > or disable this feature should not be determined at compilation > time. This has been discussed in thread [1]. > 3> The user haven't a good way to distinguish which port supports > the PTP feature in the case that a couple of device belong to the > same driver. And PTP related API in ethdev layer doesn't do check > for PTP capability. This has been mentioned and discussed in > thread [2]. > > In the thread [1], there is a conclusion that remove the compiling > macro RTE_LIBRTE_IEEE1588. And in the thread [2], there is a common > opinion that the RTE_ETH_RX_OFFLOAD_TIMESTAMP cannot be used as the > PTP capability. > > For the above issuse, this patch introduces a PTP capability in > rte_eth_dev_info.dev_capa to report PTP capability. > > Welcome to jumping into discussion. > > [1] https://patchwork.dpdk.org/project/dpdk/patch/20230203132810.14187-1-thomas@monjalon.net/ > [2] https://inbox.dpdk.org/dev/20230817084226.55327-1-lihuisong@huawei.com/ > > Signed-off-by: Huisong Li <lihuisong@huawei.com> > --- > lib/ethdev/rte_ethdev.h | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h > index efa4f12b2a..4c8bd691bd 100644 > --- a/lib/ethdev/rte_ethdev.h > +++ b/lib/ethdev/rte_ethdev.h > @@ -1613,6 +1613,12 @@ struct rte_eth_conf { > #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3) > /** Device supports keeping shared flow objects across restart. */ > #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4) > +/** > + * Device supports PTP feature. > + * For some hardware, this feature also need to set the offload > + * RTE_ETH_RX_OFFLOAD_TIMESTAMP, please check rte_eth_dev_info.rx_offload_capa. > + */ > +#define RTE_ETH_DEV_CAPA_PTP RTE_BIT64(5) > /**@}*/ > > /* Hi Huisong, Thanks for the effort, as you mentioned PTP feature can be improved and there is a target to remove RTE_LIBRTE_IEEE1588 build time macro. As far as I remember, one of the main reasons of the RTE_LIBRTE_IEEE1588 macro is some HW has resource restrictions, when RTE_LIBRTE_IEEE1588 is enabled some other features, like vector datapath, are not usable, that is why this is a build time selection. And related to the PTP capability, can you please give some more information, what does device having PTP capability exactly means. PTP is protocol and it is implemented in userspace daemon. I guess even NIC does not support timestamp offloading, by using time information from SW it can still implement PTP, right? Is PTP offload means, offloading some part of the protocol communication withing the device? Btw, the relevant RTE_ETH_RX_OFFLOAD_TIMESTAMP offload is, a little more generic HW capability that HW can add timestamp to Rx/Tx packets, which can be used for custom diagnostics. HW supporting this offload means that HW has some specific clock HW in it. Both having RTE_ETH_RX_OFFLOAD_TIMESTAMP and RTE_ETH_DEV_CAPA_PTP capability can be confusing, lets clarify it more. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] ethdev: introduce PTP device capability 2024-09-22 22:23 ` Ferruh Yigit @ 2024-09-24 7:24 ` lihuisong (C) 2024-09-25 20:42 ` Ferruh Yigit 0 siblings, 1 reply; 6+ messages in thread From: lihuisong (C) @ 2024-09-24 7:24 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev, Thomas Monjalon, Andrew Rybchenko Hi Ferruh, 在 2024/9/23 6:23, Ferruh Yigit 写道: > On 1/30/2024 3:58 AM, Huisong Li wrote: >> Currently, the PTP feature is a little messy and has some issue. >> 1> There is different implementation for PTP. This feature of some >> hardware depends on the Rx HW timestamp offload, and use this >> offload to detect if enable PTP feature. Others can enable PTP >> feature with only ethdev ops. >> 2> For some drivers, enabling PTP feature also depends on the macro >> RTE_LIBRTE_IEEE1588. Actually, whether device support, enable >> or disable this feature should not be determined at compilation >> time. This has been discussed in thread [1]. >> 3> The user haven't a good way to distinguish which port supports >> the PTP feature in the case that a couple of device belong to the >> same driver. And PTP related API in ethdev layer doesn't do check >> for PTP capability. This has been mentioned and discussed in >> thread [2]. >> >> In the thread [1], there is a conclusion that remove the compiling >> macro RTE_LIBRTE_IEEE1588. And in the thread [2], there is a common >> opinion that the RTE_ETH_RX_OFFLOAD_TIMESTAMP cannot be used as the >> PTP capability. >> >> For the above issuse, this patch introduces a PTP capability in >> rte_eth_dev_info.dev_capa to report PTP capability. >> >> Welcome to jumping into discussion. >> >> [1] https://patchwork.dpdk.org/project/dpdk/patch/20230203132810.14187-1-thomas@monjalon.net/ >> [2] https://inbox.dpdk.org/dev/20230817084226.55327-1-lihuisong@huawei.com/ >> >> Signed-off-by: Huisong Li <lihuisong@huawei.com> >> --- >> lib/ethdev/rte_ethdev.h | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h >> index efa4f12b2a..4c8bd691bd 100644 >> --- a/lib/ethdev/rte_ethdev.h >> +++ b/lib/ethdev/rte_ethdev.h >> @@ -1613,6 +1613,12 @@ struct rte_eth_conf { >> #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3) >> /** Device supports keeping shared flow objects across restart. */ >> #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4) >> +/** >> + * Device supports PTP feature. >> + * For some hardware, this feature also need to set the offload >> + * RTE_ETH_RX_OFFLOAD_TIMESTAMP, please check rte_eth_dev_info.rx_offload_capa. >> + */ >> +#define RTE_ETH_DEV_CAPA_PTP RTE_BIT64(5) >> /**@}*/ >> >> /* > Hi Huisong, > > Thanks for the effort, as you mentioned PTP feature can be improved and > there is a target to remove RTE_LIBRTE_IEEE1588 build time macro. > > As far as I remember, one of the main reasons of the RTE_LIBRTE_IEEE1588 > macro is some HW has resource restrictions, when RTE_LIBRTE_IEEE1588 is > enabled some other features, like vector datapath, are not usable, that > is why this is a build time selection. I think the main reason that driver don't support PTP feature in vector datapath is for performance. This can be controled by releated dev_ops API or TIMESTAMP offload and no need to use RTE_LIBRTE_IEEE1588 macro, like hns3. > > And related to the PTP capability, can you please give some more > information, what does device having PTP capability exactly means. Just the device having PTP capability can be used to enable PTP feature. > > PTP is protocol and it is implemented in userspace daemon. I guess even > NIC does not support timestamp offloading, by using time information > from SW it can still implement PTP, right? AFAIS, PTP feature implement requires the collaboration of HW and SW, as describted by the releated dev_ops API. > Is PTP offload means, offloading some part of the protocol communication > withing the device? Normally, a feature offload means this feature is done in hardware and the software doesn't need to something for this. I reviewed our discussion in [1], we all think it's unreasonable to name it "PTP offload". > > Btw, the relevant RTE_ETH_RX_OFFLOAD_TIMESTAMP offload is, a little more > generic HW capability that HW can add timestamp to Rx/Tx packets, which > can be used for custom diagnostics. HW supporting this offload means > that HW has some specific clock HW in it. Yes. > > Both having RTE_ETH_RX_OFFLOAD_TIMESTAMP and RTE_ETH_DEV_CAPA_PTP > capability can be confusing, lets clarify it more. Let me try to clearify them: 1) RTE_ETH_DEV_CAPA_PTP just means the ethdev support PTP capability because of application no way to know if the device support PTP feature. 2) As you said above, setting RTE_ETH_RX_OFFLOAD_TIMESTAMP offload is not necessary for PTP feature, but also may be for custom diagnostics. Some NICs enable PTP feature using only the rte_eth_timesync_xxx API, and many NICs also need this offload to fill timestamp in mbuf to cooperate with the implementation of PTP feature. > [1] https://inbox.dpdk.org/dev/20230817084226.55327-1-lihuisong@huawei.com/ > > > . ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] ethdev: introduce PTP device capability 2024-09-24 7:24 ` lihuisong (C) @ 2024-09-25 20:42 ` Ferruh Yigit 2024-09-29 1:31 ` lihuisong (C) 0 siblings, 1 reply; 6+ messages in thread From: Ferruh Yigit @ 2024-09-25 20:42 UTC (permalink / raw) To: lihuisong (C); +Cc: dev, Thomas Monjalon, Andrew Rybchenko On 9/24/2024 8:24 AM, lihuisong (C) wrote: > Hi Ferruh, > > > 在 2024/9/23 6:23, Ferruh Yigit 写道: >> On 1/30/2024 3:58 AM, Huisong Li wrote: >>> Currently, the PTP feature is a little messy and has some issue. >>> 1> There is different implementation for PTP. This feature of some >>> hardware depends on the Rx HW timestamp offload, and use this >>> offload to detect if enable PTP feature. Others can enable PTP >>> feature with only ethdev ops. >>> 2> For some drivers, enabling PTP feature also depends on the macro >>> RTE_LIBRTE_IEEE1588. Actually, whether device support, enable >>> or disable this feature should not be determined at compilation >>> time. This has been discussed in thread [1]. >>> 3> The user haven't a good way to distinguish which port supports >>> the PTP feature in the case that a couple of device belong to the >>> same driver. And PTP related API in ethdev layer doesn't do check >>> for PTP capability. This has been mentioned and discussed in >>> thread [2]. >>> >>> In the thread [1], there is a conclusion that remove the compiling >>> macro RTE_LIBRTE_IEEE1588. And in the thread [2], there is a common >>> opinion that the RTE_ETH_RX_OFFLOAD_TIMESTAMP cannot be used as the >>> PTP capability. >>> >>> For the above issuse, this patch introduces a PTP capability in >>> rte_eth_dev_info.dev_capa to report PTP capability. >>> >>> Welcome to jumping into discussion. >>> >>> [1] https://patchwork.dpdk.org/project/dpdk/ >>> patch/20230203132810.14187-1-thomas@monjalon.net/ >>> [2] https://inbox.dpdk.org/dev/20230817084226.55327-1- >>> lihuisong@huawei.com/ >>> >>> Signed-off-by: Huisong Li <lihuisong@huawei.com> >>> --- >>> lib/ethdev/rte_ethdev.h | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h >>> index efa4f12b2a..4c8bd691bd 100644 >>> --- a/lib/ethdev/rte_ethdev.h >>> +++ b/lib/ethdev/rte_ethdev.h >>> @@ -1613,6 +1613,12 @@ struct rte_eth_conf { >>> #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3) >>> /** Device supports keeping shared flow objects across restart. */ >>> #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4) >>> +/** >>> + * Device supports PTP feature. >>> + * For some hardware, this feature also need to set the offload >>> + * RTE_ETH_RX_OFFLOAD_TIMESTAMP, please check >>> rte_eth_dev_info.rx_offload_capa. >>> + */ >>> +#define RTE_ETH_DEV_CAPA_PTP RTE_BIT64(5) >>> /**@}*/ >>> /* >> Hi Huisong, >> >> Thanks for the effort, as you mentioned PTP feature can be improved and >> there is a target to remove RTE_LIBRTE_IEEE1588 build time macro. >> >> As far as I remember, one of the main reasons of the RTE_LIBRTE_IEEE1588 >> macro is some HW has resource restrictions, when RTE_LIBRTE_IEEE1588 is >> enabled some other features, like vector datapath, are not usable, that >> is why this is a build time selection. > I think the main reason that driver don't support PTP feature in vector > datapath is for performance. > This can be controled by releated dev_ops API or TIMESTAMP offload and > no need to use RTE_LIBRTE_IEEE1588 macro, like hns3. >> >> And related to the PTP capability, can you please give some more >> information, what does device having PTP capability exactly means. > Just the device having PTP capability can be used to enable PTP feature. > Hi Huisong, I am asking for your support but not able to get detailed information is not helping to progress the patch. If application implements PTP protocol, we already have APIs for application to read time from NIC, or to adjust NIC clock, etc..: 'rte_eth_timesync_read_time()' 'rte_eth_timesync_adjust_time()' ... Application can check if these APIs are supported by the device to deduce if PTP can be supported by device or not, why this is not sufficient? If application PTP implementation requires HW timestamp offload, availability of this offload also can be checked. I think for most of the cases, with combination of above two, application can decide if it can support PTP with given device or not. What else is missing so that application needs this additional capability flag from NIC? >> >> PTP is protocol and it is implemented in userspace daemon. I guess even >> NIC does not support timestamp offloading, by using time information >> from SW it can still implement PTP, right? > > AFAIS, PTP feature implement requires the collaboration of HW and SW, as > describted by the releated dev_ops API. > >> Is PTP offload means, offloading some part of the protocol communication >> withing the device? > Normally, a feature offload means this feature is done in hardware and > the software doesn't need to something for this. > I reviewed our discussion in [1], we all think it's unreasonable to name > it "PTP offload". > >> >> Btw, the relevant RTE_ETH_RX_OFFLOAD_TIMESTAMP offload is, a little more >> generic HW capability that HW can add timestamp to Rx/Tx packets, which >> can be used for custom diagnostics. HW supporting this offload means >> that HW has some specific clock HW in it. > Yes. >> >> Both having RTE_ETH_RX_OFFLOAD_TIMESTAMP and RTE_ETH_DEV_CAPA_PTP >> capability can be confusing, lets clarify it more. > > Let me try to clearify them: > 1) RTE_ETH_DEV_CAPA_PTP just means the ethdev support PTP capability > because of application no way to know if the device support PTP feature. > 2) As you said above, setting RTE_ETH_RX_OFFLOAD_TIMESTAMP offload is > not necessary for PTP feature, but also may be for custom diagnostics. > Some NICs enable PTP feature using only the rte_eth_timesync_xxx API, > and many NICs also need this offload to fill timestamp in mbuf to > cooperate with the implementation of PTP feature. > >> > [1] https://inbox.dpdk.org/dev/20230817084226.55327-1-lihuisong@huawei.com/ >> >> >> . ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] ethdev: introduce PTP device capability 2024-09-25 20:42 ` Ferruh Yigit @ 2024-09-29 1:31 ` lihuisong (C) 2024-09-29 18:55 ` Ferruh Yigit 0 siblings, 1 reply; 6+ messages in thread From: lihuisong (C) @ 2024-09-29 1:31 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev, Thomas Monjalon, Andrew Rybchenko 在 2024/9/26 4:42, Ferruh Yigit 写道: > On 9/24/2024 8:24 AM, lihuisong (C) wrote: >> Hi Ferruh, >> >> >> 在 2024/9/23 6:23, Ferruh Yigit 写道: >>> On 1/30/2024 3:58 AM, Huisong Li wrote: >>>> Currently, the PTP feature is a little messy and has some issue. >>>> 1> There is different implementation for PTP. This feature of some >>>> hardware depends on the Rx HW timestamp offload, and use this >>>> offload to detect if enable PTP feature. Others can enable PTP >>>> feature with only ethdev ops. >>>> 2> For some drivers, enabling PTP feature also depends on the macro >>>> RTE_LIBRTE_IEEE1588. Actually, whether device support, enable >>>> or disable this feature should not be determined at compilation >>>> time. This has been discussed in thread [1]. >>>> 3> The user haven't a good way to distinguish which port supports >>>> the PTP feature in the case that a couple of device belong to the >>>> same driver. And PTP related API in ethdev layer doesn't do check >>>> for PTP capability. This has been mentioned and discussed in >>>> thread [2]. >>>> >>>> In the thread [1], there is a conclusion that remove the compiling >>>> macro RTE_LIBRTE_IEEE1588. And in the thread [2], there is a common >>>> opinion that the RTE_ETH_RX_OFFLOAD_TIMESTAMP cannot be used as the >>>> PTP capability. >>>> >>>> For the above issuse, this patch introduces a PTP capability in >>>> rte_eth_dev_info.dev_capa to report PTP capability. >>>> >>>> Welcome to jumping into discussion. >>>> >>>> [1] https://patchwork.dpdk.org/project/dpdk/ >>>> patch/20230203132810.14187-1-thomas@monjalon.net/ >>>> [2] https://inbox.dpdk.org/dev/20230817084226.55327-1- >>>> lihuisong@huawei.com/ >>>> >>>> Signed-off-by: Huisong Li <lihuisong@huawei.com> >>>> --- >>>> lib/ethdev/rte_ethdev.h | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h >>>> index efa4f12b2a..4c8bd691bd 100644 >>>> --- a/lib/ethdev/rte_ethdev.h >>>> +++ b/lib/ethdev/rte_ethdev.h >>>> @@ -1613,6 +1613,12 @@ struct rte_eth_conf { >>>> #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3) >>>> /** Device supports keeping shared flow objects across restart. */ >>>> #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4) >>>> +/** >>>> + * Device supports PTP feature. >>>> + * For some hardware, this feature also need to set the offload >>>> + * RTE_ETH_RX_OFFLOAD_TIMESTAMP, please check >>>> rte_eth_dev_info.rx_offload_capa. >>>> + */ >>>> +#define RTE_ETH_DEV_CAPA_PTP RTE_BIT64(5) >>>> /**@}*/ >>>> /* >>> Hi Huisong, >>> >>> Thanks for the effort, as you mentioned PTP feature can be improved and >>> there is a target to remove RTE_LIBRTE_IEEE1588 build time macro. >>> >>> As far as I remember, one of the main reasons of the RTE_LIBRTE_IEEE1588 >>> macro is some HW has resource restrictions, when RTE_LIBRTE_IEEE1588 is >>> enabled some other features, like vector datapath, are not usable, that >>> is why this is a build time selection. >> I think the main reason that driver don't support PTP feature in vector >> datapath is for performance. >> This can be controled by releated dev_ops API or TIMESTAMP offload and >> no need to use RTE_LIBRTE_IEEE1588 macro, like hns3. >>> And related to the PTP capability, can you please give some more >>> information, what does device having PTP capability exactly means. >> Just the device having PTP capability can be used to enable PTP feature. >> > Hi Huisong, > > I am asking for your support but not able to get detailed information is > not helping to progress the patch. > > If application implements PTP protocol, we already have APIs for > application to read time from NIC, or to adjust NIC clock, etc..: > 'rte_eth_timesync_read_time()' > 'rte_eth_timesync_adjust_time()' > ... > > Application can check if these APIs are supported by the device to > deduce if PTP can be supported by device or not, why this is not sufficient? I'm going to look at these rte_eth_timesync_xx API again. Driver will return -ENOTSUP if the deivce doesn't support PTP feature. And the rte_eth_timesync_enable is called first, application know if the device support this feature when receive this error code. That is to say, application has to try to call these API first for this PTP capability of a certain device. All is ok to me even though it seems like not friendly to application. > > If application PTP implementation requires HW timestamp offload, > availability of this offload also can be checked. Yes > > I think for most of the cases, with combination of above two, > application can decide if it can support PTP with given device or not. If driver also requires HW timestamp offload for PTP, this can be tell to user in driver. > > What else is missing so that application needs this additional > capability flag from NIC? Previously, I thought that a driver supports multiple devices on a platform, but only one device support PTP. In this case, application can't know which device support PTP. But from now on, each device know if they support PTP feature and driver can return -ENOTSUP when this device doesn't support this feature. From this point, I think the additional capability flag is not necessary. But I still agree that remove the macro RTE_LIBRTE_IEEE1588. 😁 > >>> PTP is protocol and it is implemented in userspace daemon. I guess even >>> NIC does not support timestamp offloading, by using time information >>> from SW it can still implement PTP, right? >> AFAIS, PTP feature implement requires the collaboration of HW and SW, as >> describted by the releated dev_ops API. >> >>> Is PTP offload means, offloading some part of the protocol communication >>> withing the device? >> Normally, a feature offload means this feature is done in hardware and >> the software doesn't need to something for this. >> I reviewed our discussion in [1], we all think it's unreasonable to name >> it "PTP offload". >> >>> Btw, the relevant RTE_ETH_RX_OFFLOAD_TIMESTAMP offload is, a little more >>> generic HW capability that HW can add timestamp to Rx/Tx packets, which >>> can be used for custom diagnostics. HW supporting this offload means >>> that HW has some specific clock HW in it. >> Yes. >>> Both having RTE_ETH_RX_OFFLOAD_TIMESTAMP and RTE_ETH_DEV_CAPA_PTP >>> capability can be confusing, lets clarify it more. >> Let me try to clearify them: >> 1) RTE_ETH_DEV_CAPA_PTP just means the ethdev support PTP capability >> because of application no way to know if the device support PTP feature. >> 2) As you said above, setting RTE_ETH_RX_OFFLOAD_TIMESTAMP offload is >> not necessary for PTP feature, but also may be for custom diagnostics. >> Some NICs enable PTP feature using only the rte_eth_timesync_xxx API, >> and many NICs also need this offload to fill timestamp in mbuf to >> cooperate with the implementation of PTP feature. >> >> [1] https://inbox.dpdk.org/dev/20230817084226.55327-1-lihuisong@huawei.com/ >>> >>> . > . ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] ethdev: introduce PTP device capability 2024-09-29 1:31 ` lihuisong (C) @ 2024-09-29 18:55 ` Ferruh Yigit 0 siblings, 0 replies; 6+ messages in thread From: Ferruh Yigit @ 2024-09-29 18:55 UTC (permalink / raw) To: lihuisong (C); +Cc: dev, Thomas Monjalon, Andrew Rybchenko On 9/29/2024 2:31 AM, lihuisong (C) wrote: > > 在 2024/9/26 4:42, Ferruh Yigit 写道: >> On 9/24/2024 8:24 AM, lihuisong (C) wrote: >>> Hi Ferruh, >>> >>> >>> 在 2024/9/23 6:23, Ferruh Yigit 写道: >>>> On 1/30/2024 3:58 AM, Huisong Li wrote: >>>>> Currently, the PTP feature is a little messy and has some issue. >>>>> 1> There is different implementation for PTP. This feature of some >>>>> hardware depends on the Rx HW timestamp offload, and use this >>>>> offload to detect if enable PTP feature. Others can enable PTP >>>>> feature with only ethdev ops. >>>>> 2> For some drivers, enabling PTP feature also depends on the macro >>>>> RTE_LIBRTE_IEEE1588. Actually, whether device support, enable >>>>> or disable this feature should not be determined at compilation >>>>> time. This has been discussed in thread [1]. >>>>> 3> The user haven't a good way to distinguish which port supports >>>>> the PTP feature in the case that a couple of device belong to the >>>>> same driver. And PTP related API in ethdev layer doesn't do check >>>>> for PTP capability. This has been mentioned and discussed in >>>>> thread [2]. >>>>> >>>>> In the thread [1], there is a conclusion that remove the compiling >>>>> macro RTE_LIBRTE_IEEE1588. And in the thread [2], there is a common >>>>> opinion that the RTE_ETH_RX_OFFLOAD_TIMESTAMP cannot be used as the >>>>> PTP capability. >>>>> >>>>> For the above issuse, this patch introduces a PTP capability in >>>>> rte_eth_dev_info.dev_capa to report PTP capability. >>>>> >>>>> Welcome to jumping into discussion. >>>>> >>>>> [1] https://patchwork.dpdk.org/project/dpdk/ >>>>> patch/20230203132810.14187-1-thomas@monjalon.net/ >>>>> [2] https://inbox.dpdk.org/dev/20230817084226.55327-1- >>>>> lihuisong@huawei.com/ >>>>> >>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com> >>>>> --- >>>>> lib/ethdev/rte_ethdev.h | 6 ++++++ >>>>> 1 file changed, 6 insertions(+) >>>>> >>>>> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h >>>>> index efa4f12b2a..4c8bd691bd 100644 >>>>> --- a/lib/ethdev/rte_ethdev.h >>>>> +++ b/lib/ethdev/rte_ethdev.h >>>>> @@ -1613,6 +1613,12 @@ struct rte_eth_conf { >>>>> #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3) >>>>> /** Device supports keeping shared flow objects across restart. */ >>>>> #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4) >>>>> +/** >>>>> + * Device supports PTP feature. >>>>> + * For some hardware, this feature also need to set the offload >>>>> + * RTE_ETH_RX_OFFLOAD_TIMESTAMP, please check >>>>> rte_eth_dev_info.rx_offload_capa. >>>>> + */ >>>>> +#define RTE_ETH_DEV_CAPA_PTP RTE_BIT64(5) >>>>> /**@}*/ >>>>> /* >>>> Hi Huisong, >>>> >>>> Thanks for the effort, as you mentioned PTP feature can be improved and >>>> there is a target to remove RTE_LIBRTE_IEEE1588 build time macro. >>>> >>>> As far as I remember, one of the main reasons of the >>>> RTE_LIBRTE_IEEE1588 >>>> macro is some HW has resource restrictions, when RTE_LIBRTE_IEEE1588 is >>>> enabled some other features, like vector datapath, are not usable, that >>>> is why this is a build time selection. >>> I think the main reason that driver don't support PTP feature in vector >>> datapath is for performance. >>> This can be controled by releated dev_ops API or TIMESTAMP offload and >>> no need to use RTE_LIBRTE_IEEE1588 macro, like hns3. >>>> And related to the PTP capability, can you please give some more >>>> information, what does device having PTP capability exactly means. >>> Just the device having PTP capability can be used to enable PTP feature. >>> >> Hi Huisong, >> >> I am asking for your support but not able to get detailed information is >> not helping to progress the patch. >> >> If application implements PTP protocol, we already have APIs for >> application to read time from NIC, or to adjust NIC clock, etc..: >> 'rte_eth_timesync_read_time()' >> 'rte_eth_timesync_adjust_time()' >> ... >> >> Application can check if these APIs are supported by the device to >> deduce if PTP can be supported by device or not, why this is not >> sufficient? > > I'm going to look at these rte_eth_timesync_xx API again. Driver will > return -ENOTSUP if the deivce doesn't support PTP feature. > And the rte_eth_timesync_enable is called first, application know if the > device support this feature when receive this error code. > That is to say, application has to try to call these API first for this > PTP capability of a certain device. > All is ok to me even though it seems like not friendly to application. > Yes, please look at them, we can discuss later if something is missed, or an API like 'rte_eth_timesync_enable()' can be sufficient to detect PTP support. Agree that checking if an API failed is not most friendly way to application, but I think we have this an many other dev_ops, as we don't have a capability flag per each dev_ops. >> >> If application PTP implementation requires HW timestamp offload, >> availability of this offload also can be checked. > Yes >> >> I think for most of the cases, with combination of above two, >> application can decide if it can support PTP with given device or not. > > If driver also requires HW timestamp offload for PTP, this can be tell > to user in driver. > We don't need a specific flag for PTP for this, if HW requires timestamp offload support for PTP, it can check timestamp offlaod to decide to use PTP of not. Perhaps this usage was confusing us that drivers checking timestamp offload for PTP support. >> >> What else is missing so that application needs this additional >> capability flag from NIC? > Previously, I thought that a driver supports multiple devices on a > platform, but only one device support PTP. > In this case, application can't know which device support PTP. > But from now on, each device know if they support PTP feature and driver > can return -ENOTSUP when this device doesn't support this feature. > From this point, I think the additional capability flag is not necessary. > > But I still agree that remove the macro RTE_LIBRTE_IEEE1588. 😁 > Agree, Let me bring this topic in release status meeting, if we can remove the flag in this release, and still give enough time to drivers to fix their drivers before end of the release. >> >>>> PTP is protocol and it is implemented in userspace daemon. I guess even >>>> NIC does not support timestamp offloading, by using time information >>>> from SW it can still implement PTP, right? >>> AFAIS, PTP feature implement requires the collaboration of HW and SW, as >>> describted by the releated dev_ops API. >>> >>>> Is PTP offload means, offloading some part of the protocol >>>> communication >>>> withing the device? >>> Normally, a feature offload means this feature is done in hardware and >>> the software doesn't need to something for this. >>> I reviewed our discussion in [1], we all think it's unreasonable to name >>> it "PTP offload". >>> >>>> Btw, the relevant RTE_ETH_RX_OFFLOAD_TIMESTAMP offload is, a little >>>> more >>>> generic HW capability that HW can add timestamp to Rx/Tx packets, which >>>> can be used for custom diagnostics. HW supporting this offload means >>>> that HW has some specific clock HW in it. >>> Yes. >>>> Both having RTE_ETH_RX_OFFLOAD_TIMESTAMP and RTE_ETH_DEV_CAPA_PTP >>>> capability can be confusing, lets clarify it more. >>> Let me try to clearify them: >>> 1) RTE_ETH_DEV_CAPA_PTP just means the ethdev support PTP capability >>> because of application no way to know if the device support PTP feature. >>> 2) As you said above, setting RTE_ETH_RX_OFFLOAD_TIMESTAMP offload is >>> not necessary for PTP feature, but also may be for custom diagnostics. >>> Some NICs enable PTP feature using only the rte_eth_timesync_xxx >>> API, >>> and many NICs also need this offload to fill timestamp in mbuf to >>> cooperate with the implementation of PTP feature. >>> >>> [1] https://inbox.dpdk.org/dev/20230817084226.55327-1- >>> lihuisong@huawei.com/ >>>> >>>> . >> . ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-09-29 18:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-01-30 3:58 [RFC] ethdev: introduce PTP device capability Huisong Li 2024-09-22 22:23 ` Ferruh Yigit 2024-09-24 7:24 ` lihuisong (C) 2024-09-25 20:42 ` Ferruh Yigit 2024-09-29 1:31 ` lihuisong (C) 2024-09-29 18:55 ` Ferruh Yigit
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).