Re: [Linuxptp-devel] [PATCH] Add support for DELAY_REQ and SYNC packets rx_filter
>
>
>> Device driver can only get info about the current PTP port state
>> from ptp4l, because it doesn’t have direct access to it.
>>
>
> And this helps?
>
Yes, with dynamically switching RX filters I was able to change my Ethernet
controller state from Master to Slave and vice versa.
I meant a little different in my description, but I'll consider your
recommendations and update the description.
Do you suggest using HWTSTAMP_FILTER_PTP_V1?
> Or only HWTSTAMP_FILTER_PTP_V2?
>
I suggest using only HWTSTAMP_FILTER_PTP_V2 filters. I'll also mention it
in the description.
On Tue, 14 Nov 2023 at 23:21, Erez wrote:
>
>
> On Tue, 14 Nov 2023 at 23:21, Erez wrote:
>
>
> On Mon, 13 Nov 2023 at 18:49, IlorDash wrote:
>
>> From: Ilya Orazov
>>
>> Added adv_rx_filter config that allows to send SIOCSHWTSTAMP ioctl with
>> HWTSTAMP_FILTER_PTP_XXX_SYNC or HWTSTAMP_FILTER_PTP_XXX_DELAY_REQ
>> rx filters based on whether the Device is Slave or Master respectively.
>> This Feature is added for all transport levels.
>
>
>> I’m using Ethernet controller with PTP support, which requires to
>> determine which PTP packet on Rx it must timestamp: SYNC or DELAY_REQ
>> packets based on whether the device is Slave or Masterrespectively.
>
> Unfortunately, I’ve found out that ptp4l can’t send SIOCSHWTSTAMP ioctl
>> with HWTSTAMP_FILTER_PTP_XXX_SYNC or HWTSTAMP_FILTER_PTP_XXX_DELAY_REQ
>> rx filters, and sends only EVENT rx filters to device driver.
>>
>
> This is by design, not a mistake.
> Most controllers allow timestamp all RX packets.
> Users usually limit, to save resources.
>
> You can set the values using the 'hwstamp_ctl' tool.
>
> The reason to add this functionality to ptp4l is to allow dynamic change
> from
> master to slave.
>
> Please update the description to explain properly.
>
>
>
>> Device driver can only get info about the current PTP port state
>> from ptp4l, because it doesn’t have direct access to it.
>>
>
> And this helps?
>
>
>> I assumed, if these filters are defined in Kernel, they might be used in
>>
>
> No need to fix the kernel.
>
>
>> ptp4l utility to fix this. So I added adv_rx_filter config that allows
>> to send SIOCSHWTSTAMP ioctl with HWTSTAMP_FILTER_PTP_XXX_SYNC or
>> HWTSTAMP_FILTER_PTP_XXX_DELAY_REQ rx filters for all transport levels.
>>
>
> This new feature does make sense.
> But no need to talk on "Unfortunately" or "fix the kernel".
> Just add explanation on why you can *NOT* use RX timestamp on all PTP
> packets.
> And explanation on the new feature.
>
>
>>
>> Signed-off-by: Ilya Orazov
>> ---
>> config.c| 1 +
>> port.c | 17 ++
>> ptp4l.8 | 8 +++
>> ptp4l.c | 1 +
>> raw.c | 13 +++
>> sk.c| 56 -
>> sk.h| 15
>> transport.c | 7 ++
>> transport.h | 5
>> transport_private.h | 3 +++
>> udp.c | 14
>> udp6.c | 14
>> 12 files changed, 148 insertions(+), 6 deletions(-)
>>
>> diff --git a/config.c b/config.c
>> index b104f1b..642b78c 100644
>> --- a/config.c
>> +++ b/config.c
>> @@ -268,6 +268,7 @@ struct config_item config_tab[] = {
>> PORT_ITEM_INT("G.8275.portDS.localPriority", 128, 1, UINT8_MAX),
>> GLOB_ITEM_INT("gmCapable", 1, 0, 1),
>> GLOB_ITEM_ENU("hwts_filter", HWTS_FILTER_NORMAL, hwts_filter_enu),
>> + GLOB_ITEM_INT("adv_rx_filter", 0, 0, 1),
>> PORT_ITEM_INT("hybrid_e2e", 0, 0, 1),
>> PORT_ITEM_INT("ignore_source_id", 0, 0, 1),
>> PORT_ITEM_INT("ignore_transport_specific", 0, 0, 1),
>> diff --git a/port.c b/port.c
>> index 5803cd3..2376925 100644
>> --- a/port.c
>> +++ b/port.c
>> @@ -3526,6 +3526,23 @@ int port_state_update(struct port *p, enum
>> fsm_event event, int mdiff)
>> p->unicast_state_dirty = true;
>> }
>> if (next != p->state) {
>> + if (sk_adv_rx_filter == 1) {
>> + pr_debug("port state update prev %d next %d",
>> p->state,
>> +next);
>> +
>> + if ((next == PS_MASTER) || (next ==
>> PS_GRAND_MASTER))
>> + transport_update_rx_filter(p->trp,
>> p->iface,
>> + >fda,
>> +
>> p->timestamping,
>> + true);
>> +
>> + if (next == PS_UNCALIBRATED)
>> + transport_update_rx_filter(p->trp,
>> p->iface,
>> + >fda,
>> +
>> p->timestamping,
>> + false);
>> + }
>> +
>> port_show_transition(p, next, event);
>> p->state = next;
>> port_notify_event(p, NOTIFY_PORT_STATE);
>> diff
Re: [Linuxptp-devel] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote: > @@ -1129,6 +1130,27 @@ static int port_management_fill_response(struct port > *target, > memcpy(pwr, >pwr, sizeof(*pwr)); > datalen = sizeof(*pwr); > break; > + case MID_CMLDS_INFO_NP: > + cmlds = (struct cmlds_info_np *)tlv->data; > + /* IEEE1588-2019 16.6.3.2 h) 1) && nrate.ratio_valid because > + * we have no extra field to convey that separately. > + */ > + cmlds->serviceMeasurementValid = > + target->peer_portid_valid && !target->pdr_missing && > + !target->multiple_pdr_detected && > + target->nrate.ratio_valid; > + cmlds->meanLinkDelay = target->peerMeanPathDelay; > + cmlds->scaledNeighborRateRatio = > + (Integer32) (target->nrate.ratio * POW2_41 - POW2_41); > + /* 16.6.3.2: "Upon receipt of a request for information, the > + * Common Mean Link Delay Service may in addition return the > + * raw measurement data gathered by the service for use in > + * estimating the and ." > + */ > + cmlds->egress_ts = tmv_to_nanoseconds(target->peer_delay_t1); > + cmlds->rx_ts = tmv_to_nanoseconds(target->peer_delay_t2); Please drop these two fields. They don't provide any benefit. If the clients don't trust the CMLDS values, then they are free to measure the p2p delay themselves! Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
> @@ -490,6 +491,15 @@ static int mgt_post_recv(struct management_tlv *m,
> uint16_t data_len,
> if (data_len != 0)
> goto bad_length;
> break;
> + case MID_CMLDS_INFO_NP:
> + if (data_len < sizeof(struct cmlds_info_np))
> + goto bad_length;
> + cmlds = (struct cmlds_info_np *)m->data;
> + net2host64_unaligned(>meanLinkDelay);
> + NTOHL(cmlds->scaledNeighborRateRatio);
> + net2host64_unaligned(>egress_ts);
> + net2host64_unaligned(>rx_ts);
> + break;
Place after MID_POWER_PROFILE_SETTINGS_NP please.
> }
> if (extra_len) {
> if (extra_len % 2)
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 3/9] Add DM_COMMON_P2P
On Mon, May 15, 2023 at 06:26:06PM -0400, Kishen Maloor wrote:
> This change adds COMMON_P2P (IEEE 802.1AS-2020, clause 14.8.5) to the
> enumeration of delay mechanisms and incorporates it into existing code
> paths pertaining to DM_P2P to (where appropriate) maintain parity with
> DM_P2P.
>
> Co-authored-by: Andrew Zaborowski
> Signed-off-by: Kishen Maloor
> ---
> config.c | 1 +
> dm.h | 3 +++
> port.c | 15 +--
> unicast_client.c | 10 +++---
> 4 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/config.c b/config.c
> index 3e7587ba81ab..0482554feb28 100644
> --- a/config.c
> +++ b/config.c
> @@ -173,6 +173,7 @@ static struct config_enum delay_mech_enu[] = {
> { "Auto", DM_AUTO },
> { "E2E", DM_E2E },
> { "P2P", DM_P2P },
> + { "COMMON_P2P", DM_COMMON_P2P },
Preserve alphabetical order please.
> { "NONE", DM_NO_MECHANISM },
> { NULL, 0 },
> };
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 6/9] Add plumbing for interacting with the CMLDS
On Mon, May 15, 2023 at 06:26:09PM -0400, Kishen Maloor wrote: > This change furnishes the plumbing for interacting with CMLDS > Link Ports (i.e. ports with "run_cmlds=1"). > > It adds internal functions for PTP Ports which employ the > COMMON_P2P delay mechanism to issue requests to a CMLDS Link Port at > MID_CMLDS_INFO_NP and handle the response. This is too complicated. Let's keep it simple. I'd like to have this: 1. provide the new TLV via the PUSH mechanism. 2. let clients using DM_COMMON_P2P subscribe to the new TLV. 3. let the client update their peer delay values based on an incoming TLV. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] CMLDS Patches
On Mon, Aug 21, 2023 at 10:44:27AM +0200, Walfred Tedeschi wrote: > On 11.08.23 19:13, Richard Cochran wrote: > > The CMLDS series will require careful review. My superficial review > > gave me the impression that the approach was too complex. > Do you have an indication on how it could be simplified? I commented on the v2 patch series just now. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
> @@ -473,6 +476,14 @@ struct msg_interface_rate_tlv {
> UInteger16numberOfBitsAfterTimestamp;
> } PACKED;
>
> +struct cmlds_info_np {
> + Integer8 serviceMeasurementValid;
> + TimeInterval meanLinkDelay;
> + Integer32scaledNeighborRateRatio;
> + Integer64egress_ts;
> + Integer64rx_ts;
> +} PACKED;
This layout is very poor for packed formats -- think about alignment!
Please order the fields according to size, from largest to smallest.
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 2/9] Add configuration options for CMLDS
On Mon, May 15, 2023 at 06:26:05PM -0400, Kishen Maloor wrote: > 'cmlds_clockIdentity': This global setting assigns a CMLDS > clockIdentity to be used by a ptp4l instance on a PTP node that exposes > CMLDS over one or more links. Don't really need this. I know it is specified in 1588, but it is never exposed in any way, and so please omit it. > 'run_cmlds': This per-port setting (0/1) declares that a port > will perform the role of a CMLDS Link Port (IEEE 1588, clause 16.6.1) > and execute CMLDS Pdelay transactions to conduct link > delay measurements and further convey those measurements to other > PTP instances on its node via MID_CMLDS_INFO_NP. Said another way, > this port will expose CMLDS. This isn't needed. Just let every every ptp4l instance publish the TLV for each port not using DM_COMMON_P2P via its UDS port. This should be automatic. > 'cmlds_portNumber': This per-port setting in a PTP instance > specifies the CMLDS Link Port portNumber. Again this is useless. Please drop it. > 'cmlds_uds_address': This per-port setting in ptp4l instances specifies > the 'uds_address' of a ptp4l instance on the PTP node that exposes the > CMLDS. A port which employs the COMMON_P2P delay mechanism would > communicate with the CMLDS over the UDS. This option is needed. But you need one more option: the port index of the ptp4l instance which reports the TLV. Maybe something like "cmlds_port_index" ? Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 5/9] Add port_cmlds_ignore()
On Mon, May 15, 2023 at 06:26:08PM -0400, Kishen Maloor wrote: > port_cmlds_ignore() assesses incoming messages per the following > policy: > > * All messages that bear the CMLDS sdoid/domainNumber are directed > to a CMLDS Link Port context and processed by this function. All other > messages go through the regular flow (i.e. port_ignore() and beyond) > based on the the ptp4l instance configuration. > > * PDELAY_REQ, PDELAY_RESP, PDELAY_RESP_FOLLOW_UP and management > messages for MID_CMLDS_INFO_NP are the only expected message types > at a CMLDS Link Port. All other received messages at a CMLDS Link Port > (i.e., bearing the CMLDS sdoid/domainNumber) are ignored. This patch should be dropped as well. Who cares whether the peer even implements cmlds? We just want to measure the peer delay once, and share it locally. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 6/9] Add plumbing for interacting with the CMLDS
On Wed, Nov 15, 2023 at 09:05:45PM -0800, Richard Cochran wrote: > I'd like to have this: > > 1. provide the new TLV via the PUSH mechanism. > > 2. let clients using DM_COMMON_P2P subscribe to the new TLV. > > 3. let the client update their peer delay values based on an incoming TLV. For clients to do this, maybe the cleanest way is to add a new UDS client FD into the 'struct fdarray' (see fd.h) Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 4/9] Update the PdelayReq/Res flows for CMLDS Link Ports
On Wed, Nov 15, 2023 at 08:58:58PM -0800, Richard Cochran wrote: > The text of 1588 strongly suggests that the CMLDS service be stand > alone daemon. However, we can provide the same functionality without > the extra complexity, by simply letting ptp4l serve the measured peer > delay to any local client. And, if you _really_ want to have a stand alone CMLDS server with its own clockIdentity etc, then that is easy: ptp4l \ --clientOnly=1 \ --clockIdentity=10.2000.30 \ --domainNumber=0 \ --free_running=1 \ --delay_mechanism=P2P \ -i eth0 Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
On Wed, Nov 15, 2023 at 09:45:52PM -0800, Richard Cochran wrote:
> On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
>
> > @@ -473,6 +476,14 @@ struct msg_interface_rate_tlv {
> > UInteger16numberOfBitsAfterTimestamp;
> > } PACKED;
> >
> > +struct cmlds_info_np {
> > + Integer8 serviceMeasurementValid;
> > + TimeInterval meanLinkDelay;
> > + Integer32scaledNeighborRateRatio;
>
> I think you need one more field, like "source_port_index"
>
> If a client subscribes to TLVs from multiple ports, then it needs a
> way to tell which is which.
Or maybe the subscription will cause the CMLDS server to forward all
p2p delay measurements from all p2p ports.
Still the TLVs needs to include the port index.
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 9/9] Make allowedLostResponses configurable
On Mon, May 15, 2023 at 06:26:12PM -0400, Kishen Maloor wrote: > This change adds 'allowedLostResponses' as a per-port parameter > with a default value of 3 (per IEEE 802.1AS-2011, clause 11.5.3). > (Note that this matches the value of the previously #define'd > ALLOWED_LOST_RESPONSES, so this change does not alter any prevailing > behavior) This is not really in scope for the CMDLS feature. Did you see this recent post? 08.Nov'23 Chwee-Lin Choon [Linuxptp-devel] [PATCH 0/2] Enhanced Handling of Multiple Pdelay Responses 08.Nov'23 Chwee-Lin Choon ├─>[Linuxptp-devel] [PATCH 1/2] Make allowedLostResponses configurable 08.Nov'23 Chwee-Lin Choon └─>[Linuxptp-devel] [PATCH 2/2] port: Fix multiple pdelay response handling Please review it, as it also implements allowedLostResponses. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v4 0/4] add get_pins_cfg command to display pin functions
On Mon, Jun 26, 2023 at 12:03:29PM -0700, Jacob Keller wrote: > Extend phc_ctl with a new get_pins_cfg command which calls the > PTP_PIN_GETFUNC ioctl on a PHC clock and prints the pin configuration for > each pin. > > Changes since v3: > * remove use of PTP_PIN_SETFUNC2 and PTP_PIN_GETFUNC2 at Erez's request > * avoid converting PTP_PF_NONE in pin_func_string() > * check clkid >= 0 instead of clkid == CLOCK_REALTIME > * add a patch to do the same clkid check in do_caps() Jacob, Sorry for the delay. I wanted to merge this series, but there is a conflict. Can you fix it up in a v5? Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote: > @@ -651,6 +652,18 @@ static void pmc_show(struct ptp_message *msg, FILE *fp) > fprintf(fp, "LOG_MIN_PDELAY_REQ_INTERVAL " > IFMT "logMinPdelayReqInterval %hhd", mtd->val); > break; > + case MID_CMLDS_INFO_NP: > + cmlds = (struct cmlds_info_np *) mgt->data; > + fprintf(fp, "CMLDS INFO " > + IFMT "serviceMeasurementValid %i" > + IFMT "meanLinkDelay %" PRId64 > + IFMT "scaledNeighborRateRatio %" PRId32 > + IFMT "egress_ts %" PRId64 > + IFMT "rx_ts %" PRId64, > + cmlds->serviceMeasurementValid, cmlds->meanLinkDelay, > + cmlds->scaledNeighborRateRatio, > + cmlds->egress_ts, cmlds->rx_ts); > + break; Nit: please place this after MID_POWER_PROFILE_SETTINGS_NP rather than tacking on the end of the switch/case. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 4/9] Update the PdelayReq/Res flows for CMLDS Link Ports
On Mon, May 15, 2023 at 06:26:07PM -0400, Kishen Maloor wrote: > For ports that are configured with "run_cmlds=1", i.e. CMLDS Link > Ports, this change updates port_pdelay_request(), process_pdelay_req() and > port_peer_delay() to utilize the CMLDS sdoid/domainNumber/portId > along code paths where necessary. It also ensures that > neighborRateRatio is calculated on CMLDS Link Ports and is available > to users of MID_CMLDS_INFO_NP. Further, process_pdelay_request() > enforces two-step Pdelay when responding as CMLDS. > These changes are in accordance to the requirements outlined in > IEEE 1588, clause 16.6.3. > > In addition, CMLDS Link Ports respond with instance-specific peer delay > messages to PdelayReqs with an sdoid/domainNumber that match their ptp4l > instance configuration. This aims to address the requirement outlined > above NOTE 3 in IEEE 802.1AS-2020, clause 11.2.17.1. > > Note that all these changes take effect only in ports with a > "run_cmlds=1" setting. Default behavior applies otherwise. This patch can be dropped. The text of 1588 strongly suggests that the CMLDS service be stand alone daemon. However, we can provide the same functionality without the extra complexity, by simply letting ptp4l serve the measured peer delay to any local client. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 7/9] Implement the COMMON_P2P delay mechanism
On Mon, May 15, 2023 at 06:26:10PM -0400, Kishen Maloor wrote: > From: Andrew Zaborowski > > This change implements the COMMON_P2P DM by issuing a request > to the CMLDS for CommonMeanLinkDelayInformation upon expiry of > the delay timer and handles the response to assimilate the > received meanPathDelay and NRR. Cleints using COMMON_P2P don't need to do anything in the delay timer. Just use the latest pushed TLV from the server. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 4/9] Update the PdelayReq/Res flows for CMLDS Link Ports
On Mon, May 15, 2023 at 06:26:07PM -0400, Kishen Maloor wrote: > For ports that are configured with "run_cmlds=1", i.e. CMLDS Link > Ports, this change updates port_pdelay_request(), process_pdelay_req() and > port_peer_delay() to utilize the CMLDS sdoid/domainNumber/portId > along code paths where necessary. We already have options to configure those attributes. The use can simply configure the port that will do the p2p measurement accordingly. > It also ensures that > neighborRateRatio is calculated on CMLDS Link Ports and is available > to users of MID_CMLDS_INFO_NP. Further, process_pdelay_request() > enforces two-step Pdelay when responding as CMLDS. Again, we already have a way to configure this. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
On Mon, May 15, 2023 at 06:26:04PM -0400, Kishen Maloor wrote:
> @@ -473,6 +476,14 @@ struct msg_interface_rate_tlv {
> UInteger16numberOfBitsAfterTimestamp;
> } PACKED;
>
> +struct cmlds_info_np {
> + Integer8 serviceMeasurementValid;
> + TimeInterval meanLinkDelay;
> + Integer32scaledNeighborRateRatio;
I think you need one more field, like "source_port_index"
If a client subscribes to TLVs from multiple ports, then it needs a
way to tell which is which.
> + Integer64egress_ts;
> + Integer64rx_ts;
> +} PACKED;
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
