From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 69EA8459F6; Sun, 29 Sep 2024 03:31:38 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ECC7E4027F; Sun, 29 Sep 2024 03:31:37 +0200 (CEST) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id EDD484027D for ; Sun, 29 Sep 2024 03:31:35 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4XGRTS0CQxz1T85j; Sun, 29 Sep 2024 09:30:04 +0800 (CST) Received: from kwepemm600004.china.huawei.com (unknown [7.193.23.242]) by mail.maildlp.com (Postfix) with ESMTPS id B911018009B; Sun, 29 Sep 2024 09:31:33 +0800 (CST) Received: from [10.67.121.59] (10.67.121.59) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Sun, 29 Sep 2024 09:31:33 +0800 Message-ID: <72cc97a9-9b8c-4593-cd57-abbdf9156d46@huawei.com> Date: Sun, 29 Sep 2024 09:31:32 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [RFC] ethdev: introduce PTP device capability To: Ferruh Yigit CC: , Thomas Monjalon , Andrew Rybchenko References: <20240130035820.29713-1-lihuisong@huawei.com> <0f4dd7ef-2dd1-0565-c5f3-520581422eb5@huawei.com> <789124c2-e7a8-4409-97d7-958d6a750561@amd.com> From: "lihuisong (C)" In-Reply-To: <789124c2-e7a8-4409-97d7-958d6a750561@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.59] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600004.china.huawei.com (7.193.23.242) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 在 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 >>>> --- >>>>   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/ >>> >>> . > .