From patchwork Tue Jan 30 03:58:19 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "lihuisong (C)" X-Patchwork-Id: 136210 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A86D443A05; Tue, 30 Jan 2024 04:59:08 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 80C954029A; Tue, 30 Jan 2024 04:59:08 +0100 (CET) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 9D9D440275 for ; Tue, 30 Jan 2024 04:59:07 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4TPBG95xsmzsWdP; Tue, 30 Jan 2024 11:57:53 +0800 (CST) Received: from kwepemm600004.china.huawei.com (unknown [7.193.23.242]) by mail.maildlp.com (Postfix) with ESMTPS id 2DE281400FF; Tue, 30 Jan 2024 11:59:04 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 30 Jan 2024 11:59:03 +0800 From: Huisong Li To: , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko CC: Subject: [RFC] ethdev: introduce PTP device capability Date: Tue, 30 Jan 2024 11:58:19 +0800 Message-ID: <20240130035820.29713-1-lihuisong@huawei.com> X-Mailer: git-send-email 2.33.0 MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) 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 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) /**@}*/ /*