DPDK patches and discussions
 help / color / mirror / Atom feed
From: Huisong Li <lihuisong@huawei.com>
To: <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@amd.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: <ferruh.yigit@intel.com>
Subject: [RFC] ethdev: introduce PTP device capability
Date: Tue, 30 Jan 2024 11:58:19 +0800	[thread overview]
Message-ID: <20240130035820.29713-1-lihuisong@huawei.com> (raw)

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


                 reply	other threads:[~2024-01-30  3:59 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20240130035820.29713-1-lihuisong@huawei.com \
    --to=lihuisong@huawei.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=ferruh.yigit@intel.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).