[v10] examples/ptp: replace terms master and slave

Message ID 20240614154615.65507-1-stephen@networkplumber.org (mailing list archive)
State Accepted, archived
Delegated to: Ajit Khaparde
Headers
Series [v10] examples/ptp: replace terms master and slave |

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/intel-Functional success Functional PASS
ci/github-robot: build success github build: passed
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-abi-testing success Testing PASS
ci/iol-unit-amd64-testing success Testing PASS
ci/iol-unit-arm64-testing success Testing PASS
ci/iol-compile-amd64-testing success Testing PASS
ci/iol-sample-apps-testing success Testing PASS
ci/iol-compile-arm64-testing success Testing PASS

Commit Message

Stephen Hemminger June 14, 2024, 3:41 p.m. UTC
Remove one of the few remaining uses of master/slave.

The IEEE 1588 standard has been updated to remove the use
of master-slave terminology. Change the sample to Use the terms
recommended by IEEE 1588g-2022 amendment.

  In place of the term “master”, use the term “timeTransmitter”.
  In place of the term “slave”, use the term “timeReceiver”.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>

---
v10 - rebase to current version

 doc/guides/nics/bnxt.rst                   |  8 ++--
 doc/guides/sample_app_ug/img/ptpclient.svg |  4 +-
 doc/guides/sample_app_ug/intro.rst         |  4 +-
 doc/guides/sample_app_ug/ptpclient.rst     | 29 ++++++------
 examples/ptpclient/ptpclient.c             | 54 +++++++++++-----------
 5 files changed, 51 insertions(+), 48 deletions(-)
  

Comments

Stephen Hemminger Oct. 22, 2024, 4:39 p.m. UTC | #1
On Fri, 14 Jun 2024 08:41:07 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:

> Remove one of the few remaining uses of master/slave.
> 
> The IEEE 1588 standard has been updated to remove the use
> of master-slave terminology. Change the sample to Use the terms
> recommended by IEEE 1588g-2022 amendment.
> 
>   In place of the term “master”, use the term “timeTransmitter”.
>   In place of the term “slave”, use the term “timeReceiver”.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
> 
> ---
> v10 - rebase to current version
> 
>  doc/guides/nics/bnxt.rst                   |  8 ++--
>  doc/guides/sample_app_ug/img/ptpclient.svg |  4 +-
>  doc/guides/sample_app_ug/intro.rst         |  4 +-
>  doc/guides/sample_app_ug/ptpclient.rst     | 29 ++++++------
>  examples/ptpclient/ptpclient.c             | 54 +++++++++++-----------
>  5 files changed, 51 insertions(+), 48 deletions(-)

This patch seems to have been lost/ignored. Could it be merged for 24.11.

Note: checkpatch complaints here are incorrect. The patch is removing
terms master and slave, but checkpatch can't tell the difference.
  
Ajit Khaparde Oct. 22, 2024, 5:26 p.m. UTC | #2
On Tue, Oct 22, 2024 at 9:39 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Fri, 14 Jun 2024 08:41:07 -0700
> Stephen Hemminger <stephen@networkplumber.org> wrote:
>
> > Remove one of the few remaining uses of master/slave.
> >
> > The IEEE 1588 standard has been updated to remove the use
> > of master-slave terminology. Change the sample to Use the terms
> > recommended by IEEE 1588g-2022 amendment.
> >
> >   In place of the term “master”, use the term “timeTransmitter”.
> >   In place of the term “slave”, use the term “timeReceiver”.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
> >
> > ---
> > v10 - rebase to current version
> >
> >  doc/guides/nics/bnxt.rst                   |  8 ++--
> >  doc/guides/sample_app_ug/img/ptpclient.svg |  4 +-
> >  doc/guides/sample_app_ug/intro.rst         |  4 +-
> >  doc/guides/sample_app_ug/ptpclient.rst     | 29 ++++++------
> >  examples/ptpclient/ptpclient.c             | 54 +++++++++++-----------
> >  5 files changed, 51 insertions(+), 48 deletions(-)
>
> This patch seems to have been lost/ignored. Could it be merged for 24.11.
>
> Note: checkpatch complaints here are incorrect. The patch is removing
> terms master and slave, but checkpatch can't tell the difference.
I thought it would be picked by dpdk-next-net since it looked like a
tree-wide change.
Since its assigned to me, I will merge it in a day or so and let the
set take its course.

Thanks
  
Ajit Khaparde Oct. 24, 2024, 2:06 a.m. UTC | #3
On Tue, Oct 22, 2024 at 10:26 AM Ajit Khaparde
<ajit.khaparde@broadcom.com> wrote:
>
> On Tue, Oct 22, 2024 at 9:39 AM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Fri, 14 Jun 2024 08:41:07 -0700
> > Stephen Hemminger <stephen@networkplumber.org> wrote:
> >
> > > Remove one of the few remaining uses of master/slave.
> > >
> > > The IEEE 1588 standard has been updated to remove the use
> > > of master-slave terminology. Change the sample to Use the terms
> > > recommended by IEEE 1588g-2022 amendment.
> > >
> > >   In place of the term “master”, use the term “timeTransmitter”.
> > >   In place of the term “slave”, use the term “timeReceiver”.
> > >
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Patch applied to dpdk-next-net-brcm for-next-net branch.

> > >
> > > ---
> > > v10 - rebase to current version
> > >
> > >  doc/guides/nics/bnxt.rst                   |  8 ++--
> > >  doc/guides/sample_app_ug/img/ptpclient.svg |  4 +-
> > >  doc/guides/sample_app_ug/intro.rst         |  4 +-
> > >  doc/guides/sample_app_ug/ptpclient.rst     | 29 ++++++------
> > >  examples/ptpclient/ptpclient.c             | 54 +++++++++++-----------
> > >  5 files changed, 51 insertions(+), 48 deletions(-)
> >
> > This patch seems to have been lost/ignored. Could it be merged for 24.11.
> >
> > Note: checkpatch complaints here are incorrect. The patch is removing
> > terms master and slave, but checkpatch can't tell the difference.
> I thought it would be picked by dpdk-next-net since it looked like a
> tree-wide change.
> Since its assigned to me, I will merge it in a day or so and let the
> set take its course.
>
> Thanks
  
Thomas Monjalon Nov. 13, 2024, 5:33 p.m. UTC | #4
24/10/2024 04:06, Ajit Khaparde:
> On Tue, Oct 22, 2024 at 10:26 AM Ajit Khaparde
> <ajit.khaparde@broadcom.com> wrote:
> >
> > On Tue, Oct 22, 2024 at 9:39 AM Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > >
> > > On Fri, 14 Jun 2024 08:41:07 -0700
> > > Stephen Hemminger <stephen@networkplumber.org> wrote:
> > >
> > > > Remove one of the few remaining uses of master/slave.
> > > >
> > > > The IEEE 1588 standard has been updated to remove the use
> > > > of master-slave terminology. Change the sample to Use the terms
> > > > recommended by IEEE 1588g-2022 amendment.
> > > >
> > > >   In place of the term “master”, use the term “timeTransmitter”.
> > > >   In place of the term “slave”, use the term “timeReceiver”.
> > > >
> > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > > Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
> Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Patch applied to dpdk-next-net-brcm for-next-net branch.

Merged in main with some rebase effort because of a new feature merged.
I have decided to avoid camelCase and inserted a space or a hyphen
depending on being in doc or code, in order to be consistent with our guidelines.


> > > This patch seems to have been lost/ignored. Could it be merged for 24.11.
> > >
> > > Note: checkpatch complaints here are incorrect. The patch is removing
> > > terms master and slave, but checkpatch can't tell the difference.
> > I thought it would be picked by dpdk-next-net since it looked like a
> > tree-wide change.
> > Since its assigned to me, I will merge it in a day or so and let the
> > set take its course.

I don't know why it was assigned to you.
You could have re-assigned it to me.
  
Stephen Hemminger Nov. 13, 2024, 5:52 p.m. UTC | #5
On Wed, 13 Nov 2024 18:33:15 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> 24/10/2024 04:06, Ajit Khaparde:
> > On Tue, Oct 22, 2024 at 10:26 AM Ajit Khaparde
> > <ajit.khaparde@broadcom.com> wrote:  
> > >
> > > On Tue, Oct 22, 2024 at 9:39 AM Stephen Hemminger
> > > <stephen@networkplumber.org> wrote:  
> > > >
> > > > On Fri, 14 Jun 2024 08:41:07 -0700
> > > > Stephen Hemminger <stephen@networkplumber.org> wrote:
> > > >  
> > > > > Remove one of the few remaining uses of master/slave.
> > > > >
> > > > > The IEEE 1588 standard has been updated to remove the use
> > > > > of master-slave terminology. Change the sample to Use the terms
> > > > > recommended by IEEE 1588g-2022 amendment.
> > > > >
> > > > >   In place of the term “master”, use the term “timeTransmitter”.
> > > > >   In place of the term “slave”, use the term “timeReceiver”.
> > > > >
> > > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > > > Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>  
> > Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> > Patch applied to dpdk-next-net-brcm for-next-net branch.  
> 
> Merged in main with some rebase effort because of a new feature merged.
> I have decided to avoid camelCase and inserted a space or a hyphen
> depending on being in doc or code, in order to be consistent with our guidelines.

Ok my choice of camelCase was based on terms in current PTP spec.
  
Thomas Monjalon Nov. 13, 2024, 7:11 p.m. UTC | #6
13/11/2024 18:52, Stephen Hemminger:
> On Wed, 13 Nov 2024 18:33:15 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > 24/10/2024 04:06, Ajit Khaparde:
> > > On Tue, Oct 22, 2024 at 10:26 AM Ajit Khaparde
> > > <ajit.khaparde@broadcom.com> wrote:  
> > > >
> > > > On Tue, Oct 22, 2024 at 9:39 AM Stephen Hemminger
> > > > <stephen@networkplumber.org> wrote:  
> > > > >
> > > > > On Fri, 14 Jun 2024 08:41:07 -0700
> > > > > Stephen Hemminger <stephen@networkplumber.org> wrote:
> > > > >  
> > > > > > Remove one of the few remaining uses of master/slave.
> > > > > >
> > > > > > The IEEE 1588 standard has been updated to remove the use
> > > > > > of master-slave terminology. Change the sample to Use the terms
> > > > > > recommended by IEEE 1588g-2022 amendment.
> > > > > >
> > > > > >   In place of the term “master”, use the term “timeTransmitter”.
> > > > > >   In place of the term “slave”, use the term “timeReceiver”.
> > > > > >
> > > > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > > > > Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>  
> > > Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> > > Patch applied to dpdk-next-net-brcm for-next-net branch.  
> > 
> > Merged in main with some rebase effort because of a new feature merged.
> > I have decided to avoid camelCase and inserted a space or a hyphen
> > depending on being in doc or code, in order to be consistent with our guidelines.
> 
> Ok my choice of camelCase was based on terms in current PTP spec.

Yes I got it, but I think we can deviate a little for consistency.
  

Patch

diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index 6db880d632..8b9fcd2558 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -538,10 +538,12 @@  Time Synchronization
 ~~~~~~~~~~~~~~~~~~~~
 
 System operators may run a PTP (Precision Time Protocol) client application to
-synchronize the time on the NIC (and optionally, on the system) to a PTP master.
+synchronize the time on the NIC (and optionally, on the system) to a
+PTP timeTransmitter.
 
-The BNXT PMD supports a PTP client application to communicate with a PTP master
-clock using DPDK IEEE1588 APIs. Note that the PTP client application needs to
+The BNXT PMD supports a PTP client application to communicate with a
+PTP timeTransmitter using DPDK IEEE1588 APIs.
+Note that the PTP client application needs to
 run on PF and vector mode needs to be disabled.
 
 .. code-block:: console
diff --git a/doc/guides/sample_app_ug/img/ptpclient.svg b/doc/guides/sample_app_ug/img/ptpclient.svg
index fd78ef839b..41869bc4c9 100644
--- a/doc/guides/sample_app_ug/img/ptpclient.svg
+++ b/doc/guides/sample_app_ug/img/ptpclient.svg
@@ -488,7 +488,7 @@ 
          sodipodi:role="line"
          id="tspan7096"
          x="38.764343"
-         y="590.47479">master</tspan></text>
+         y="590.47479">timeTransmitter</tspan></text>
     <text
        xml:space="preserve"
        style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:47.51625061px;line-height:100%;font-family:sans-serif;-inkscape-font-specification:'sans-serif, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
@@ -510,7 +510,7 @@ 
          sodipodi:role="line"
          id="tspan7104"
          x="271.23392"
-         y="593.71478">slave</tspan></text>
+         y="593.71478">timeReceiver</tspan></text>
     <text
        xml:space="preserve"
        style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:20.3917141px;line-height:125%;font-family:sans-serif;-inkscape-font-specification:'sans-serif, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#800080;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst
index e765f1fd6b..5453df5766 100644
--- a/doc/guides/sample_app_ug/intro.rst
+++ b/doc/guides/sample_app_ug/intro.rst
@@ -85,8 +85,8 @@  examples are highlighted below.
 * :doc:`Precision Time Protocol (PTP) client<ptpclient>`: The PTP
   client is another minimal implementation of a real world application.
   In this case the application is a PTP client that communicates with a PTP
-  master clock to synchronize time on a Network Interface Card (NIC) using the
-  IEEE1588 protocol.
+  timeTransmitter to synchronize time on a Network Interface Card (NIC)
+  using the IEEE1588 protocol.
 
 * :doc:`Quality of Service (QoS) Scheduler<qos_scheduler>`: The QoS
   Scheduler application demonstrates the use of DPDK to provide QoS scheduling.
diff --git a/doc/guides/sample_app_ug/ptpclient.rst b/doc/guides/sample_app_ug/ptpclient.rst
index d47e942738..242c9628ea 100644
--- a/doc/guides/sample_app_ug/ptpclient.rst
+++ b/doc/guides/sample_app_ug/ptpclient.rst
@@ -5,8 +5,9 @@  PTP Client Sample Application
 =============================
 
 The PTP (Precision Time Protocol) client sample application is a simple
-example of using the DPDK IEEE1588 API to communicate with a PTP master clock
-to synchronize the time on the NIC and, optionally, on the Linux system.
+example of using the DPDK IEEE1588 API to communicate with a PTP
+timeTransmitter to synchronize the time on the NIC and, optionally,
+on the Linux system.
 
 Note, PTP is a time syncing protocol and cannot be used within DPDK as a
 time-stamping mechanism. See the following for an explanation of the protocol:
@@ -21,10 +22,10 @@  The PTP sample application is intended as a simple reference implementation of
 a PTP client using the DPDK IEEE1588 API.
 In order to keep the application simple the following assumptions are made:
 
-* The first discovered master is the main for the session.
+* The first discovered timeTransmitter is the main for the session.
 * Only L2 PTP packets are supported.
 * Only the PTP v2 protocol is supported.
-* Only the slave clock is implemented.
+* Only the timeReceiver clock is implemented.
 
 
 How the Application Works
@@ -38,12 +39,12 @@  How the Application Works
 
 The PTP synchronization in the sample application works as follows:
 
-* Master sends *Sync* message - the slave saves it as T2.
-* Master sends *Follow Up* message and sends time of T1.
-* Slave sends *Delay Request* frame to PTP Master and stores T3.
-* Master sends *Delay Response* T4 time which is time of received T3.
+* TimeTransmitter sends *Sync* message - the TimeReceiver saves it as T2.
+* TimeTransmitter sends *Follow Up* message and sends time of T1.
+* TimeReceiver sends *Delay Request* frame to PTP TimeTransmitter and stores T3.
+* TimeTransmitter sends *Delay Response* T4 time which is time of received T3.
 
-The adjustment for slave can be represented as:
+The adjustment for timeReceiver can be represented as:
 
    adj = -[(T2-T1)-(T4 - T3)]/2
 
@@ -71,8 +72,8 @@  Refer to *DPDK Getting Started Guide* for general information on running
 applications and the Environment Abstraction Layer (EAL) options.
 
 * ``-p portmask``: Hexadecimal portmask.
-* ``-T 0``: Update only the PTP slave clock.
-* ``-T 1``: Update the PTP slave clock and synchronize the Linux Kernel to the PTP clock.
+* ``-T 0``: Update only the PTP timeReceiver clock.
+* ``-T 1``: Update the PTP timeReceiver clock and synchronize the Linux Kernel to the PTP clock.
 
 
 Code Explanation
@@ -178,7 +179,7 @@  The forwarding loop can be interrupted and the application closed using
 PTP parsing
 ~~~~~~~~~~~
 
-The ``parse_ptp_frames()`` function processes PTP packets, implementing slave
+The ``parse_ptp_frames()`` function processes PTP packets, implementing timeReceiver
 PTP IEEE1588 L2 functionality.
 
 .. literalinclude:: ../../../examples/ptpclient/ptpclient.c
@@ -187,11 +188,11 @@  PTP IEEE1588 L2 functionality.
     :end-before:  >8 End of function processes PTP packets.
 
 There are 3 types of packets on the RX path which we must parse to create a minimal
-implementation of the PTP slave client:
+implementation of the PTP timeReceiver client:
 
 * SYNC packet.
 * FOLLOW UP packet
 * DELAY RESPONSE packet.
 
 When we parse the *FOLLOW UP* packet we also create and send a *DELAY_REQUEST* packet.
-Also when we parse the *DELAY RESPONSE* packet, and all conditions are met we adjust the PTP slave clock.
+Also when we parse the *DELAY RESPONSE* packet, and all conditions are met we adjust the PTP timeReceiver clock.
diff --git a/examples/ptpclient/ptpclient.c b/examples/ptpclient/ptpclient.c
index afb61bba51..889a8c075b 100644
--- a/examples/ptpclient/ptpclient.c
+++ b/examples/ptpclient/ptpclient.c
@@ -119,14 +119,14 @@  struct ptp_message {
 	} __rte_packed;
 };
 
-struct ptpv2_data_slave_ordinary {
+struct ptpv2_timeReceiver_ordinary {
 	struct rte_mbuf *m;
 	struct timespec tstamp1;
 	struct timespec tstamp2;
 	struct timespec tstamp3;
 	struct timespec tstamp4;
 	struct clock_id client_clock_id;
-	struct clock_id master_clock_id;
+	struct clock_id transmitter_clock_id;
 	struct timeval new_adj;
 	int64_t delta;
 	uint16_t portid;
@@ -137,7 +137,7 @@  struct ptpv2_data_slave_ordinary {
 	uint16_t current_ptp_port;
 };
 
-static struct ptpv2_data_slave_ordinary ptp_data;
+static struct ptpv2_timeReceiver_ordinary ptp_data;
 
 static inline uint64_t timespec64_to_ns(const struct timespec *ts)
 {
@@ -266,38 +266,38 @@  port_init(uint16_t port, struct rte_mempool *mbuf_pool)
 }
 
 static void
-print_clock_info(struct ptpv2_data_slave_ordinary *ptp_data)
+print_clock_info(struct ptpv2_timeReceiver_ordinary *ptp_data)
 {
 	int64_t nsec;
 	struct timespec net_time, sys_time;
 
-	printf("Master Clock id: %02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x",
-		ptp_data->master_clock_id.id[0],
-		ptp_data->master_clock_id.id[1],
-		ptp_data->master_clock_id.id[2],
-		ptp_data->master_clock_id.id[3],
-		ptp_data->master_clock_id.id[4],
-		ptp_data->master_clock_id.id[5],
-		ptp_data->master_clock_id.id[6],
-		ptp_data->master_clock_id.id[7]);
-
-	printf("\nT2 - Slave  Clock.  %lds %ldns",
+	printf("TimeTransmitter Clock id: %02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x",
+		ptp_data->transmitter_clock_id.id[0],
+		ptp_data->transmitter_clock_id.id[1],
+		ptp_data->transmitter_clock_id.id[2],
+		ptp_data->transmitter_clock_id.id[3],
+		ptp_data->transmitter_clock_id.id[4],
+		ptp_data->transmitter_clock_id.id[5],
+		ptp_data->transmitter_clock_id.id[6],
+		ptp_data->transmitter_clock_id.id[7]);
+
+	printf("\nT2 - TimeReceiver  Clock.  %lds %ldns",
 			(ptp_data->tstamp2.tv_sec),
 			(ptp_data->tstamp2.tv_nsec));
 
-	printf("\nT1 - Master Clock.  %lds %ldns ",
+	printf("\nT1 - TimeTransmitter Clock.  %lds %ldns ",
 			ptp_data->tstamp1.tv_sec,
 			(ptp_data->tstamp1.tv_nsec));
 
-	printf("\nT3 - Slave  Clock.  %lds %ldns",
+	printf("\nT3 - TimeReceiver  Clock.  %lds %ldns",
 			ptp_data->tstamp3.tv_sec,
 			(ptp_data->tstamp3.tv_nsec));
 
-	printf("\nT4 - Master Clock.  %lds %ldns ",
+	printf("\nT4 - TimeTransmitter Clock.  %lds %ldns ",
 			ptp_data->tstamp4.tv_sec,
 			(ptp_data->tstamp4.tv_nsec));
 
-	printf("\nDelta between master and slave clocks:%"PRId64"ns\n",
+	printf("\nDelta between timeTransmitter and timeReceiver clocks:%"PRId64"ns\n",
 			ptp_data->delta);
 
 	clock_gettime(CLOCK_REALTIME, &sys_time);
@@ -331,7 +331,7 @@  print_clock_info(struct ptpv2_data_slave_ordinary *ptp_data)
 }
 
 static int64_t
-delta_eval(struct ptpv2_data_slave_ordinary *ptp_data)
+delta_eval(struct ptpv2_timeReceiver_ordinary *ptp_data)
 {
 	int64_t delta;
 	uint64_t t1 = 0;
@@ -353,7 +353,7 @@  delta_eval(struct ptpv2_data_slave_ordinary *ptp_data)
  * Parse the PTP SYNC message.
  */
 static void
-parse_sync(struct ptpv2_data_slave_ordinary *ptp_data, uint16_t rx_tstamp_idx)
+parse_sync(struct ptpv2_timeReceiver_ordinary *ptp_data, uint16_t rx_tstamp_idx)
 {
 	struct ptp_header *ptp_hdr;
 
@@ -362,7 +362,7 @@  parse_sync(struct ptpv2_data_slave_ordinary *ptp_data, uint16_t rx_tstamp_idx)
 	ptp_data->seqID_SYNC = rte_be_to_cpu_16(ptp_hdr->seq_id);
 
 	if (ptp_data->ptpset == 0) {
-		rte_memcpy(&ptp_data->master_clock_id,
+		rte_memcpy(&ptp_data->transmitter_clock_id,
 				&ptp_hdr->source_port_id.clock_id,
 				sizeof(struct clock_id));
 		ptp_data->ptpset = 1;
@@ -383,7 +383,7 @@  parse_sync(struct ptpv2_data_slave_ordinary *ptp_data, uint16_t rx_tstamp_idx)
  * Parse the PTP FOLLOWUP message and send DELAY_REQ to the main clock.
  */
 static void
-parse_fup(struct ptpv2_data_slave_ordinary *ptp_data)
+parse_fup(struct ptpv2_timeReceiver_ordinary *ptp_data)
 {
 	struct rte_ether_hdr *eth_hdr;
 	struct rte_ether_addr eth_addr;
@@ -402,7 +402,7 @@  parse_fup(struct ptpv2_data_slave_ordinary *ptp_data)
 	eth_hdr = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
 	ptp_hdr = rte_pktmbuf_mtod_offset(m, struct ptp_header *,
 					  sizeof(struct rte_ether_hdr));
-	if (memcmp(&ptp_data->master_clock_id,
+	if (memcmp(&ptp_data->transmitter_clock_id,
 			&ptp_hdr->source_port_id.clock_id,
 			sizeof(struct clock_id)) != 0)
 		return;
@@ -533,7 +533,7 @@  update_kernel_time(void)
  * Parse the DELAY_RESP message.
  */
 static void
-parse_drsp(struct ptpv2_data_slave_ordinary *ptp_data)
+parse_drsp(struct ptpv2_timeReceiver_ordinary *ptp_data)
 {
 	struct rte_mbuf *m = ptp_data->m;
 	struct ptp_message *ptp_msg;
@@ -571,7 +571,7 @@  parse_drsp(struct ptpv2_data_slave_ordinary *ptp_data)
 	}
 }
 
-/* This function processes PTP packets, implementing slave PTP IEEE1588 L2
+/* This function processes PTP packets, implementing timeReceiver PTP IEEE1588 L2
  * functionality.
  */
 
@@ -763,7 +763,7 @@  main(int argc, char *argv[])
 		rte_exit(EXIT_FAILURE, "Error with EAL initialization\n");
 	/* >8 End of initialization of EAL. */
 
-	memset(&ptp_data, '\0', sizeof(struct ptpv2_data_slave_ordinary));
+	memset(&ptp_data, 0, sizeof(struct ptpv2_timeReceiver_ordinary));
 
 	/* Parse specific arguments. 8< */
 	argc -= ret;