[Linuxptp-devel] [PATCH RFC 0/4] Time stamp asymmetry correction

[Richard Cochran]

Most (or all?) hardware provides time stamps that are offset from the
actual point at the reference plane. The amount of delay is asymmetrical
between ingress and egress, and depending on the particular technology,
MAC or PHY, and link speed, there can be jitter in the delay.

Sometimes the manufacturer specifies the amount of expected delay. This
patch series provides a way for the user to correct the delays based on
values from the data sheet or based on empirical data.

In theory one could place the sum of the correction factors into the
delayAsymmetry field. However, the standard specifies that the slave
applies this correction field, and never the master. Having these two
new correction fields allows each node to compensate for its own part
of the offset error.

This series was tested with an i210 paired with a dp83640 using a short
cable. These devices have their delay values listed in the data sheet.
PPS signals in both directions showed a remaining offset of about 120
nanoseconds, which matches the sum of uncertainties (40 and 80) given
for the i210 card at the 100 MBit link speed.

Comments are welcome.

Thanks,
Richard

Richard Cochran (4):
Introduce a helper function to identify valid (non-zero) time stamps.
Invoke the clock check even if the time stamp nanoseconds field is
zero.
config: Introduce options for correcting transmit and receive delays.
port: correct transmit and receive time stamps for their calibrated
delays.

config.c | 12 ++++++++++++
default.cfg | 2 ++
ds.h | 2 ++
gPTP.cfg | 2 ++
msg.c | 2 +-
msg.h | 10 ++++++++++
port.c | 35 ++++++++++++++++++++++++++++++++---
ptp4l.8 | 12 ++++++++++++
ptp4l.c | 2 ++
9 files changed, 75 insertions(+), 4 deletions(-)

[Richard Cochran]

Signed-off-by: Richard Cochran <***@gmail.com>
---
msg.c | 2 +-
msg.h | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/msg.c b/msg.c
index 7edbdd2..06a3812 100644
--- a/msg.c
+++ b/msg.c
@@ -468,5 +468,5 @@ int msg_sots_missing(struct ptp_message *m)
default:
return 0;
}
- return (!m->hwts.ts.tv_sec && !m->hwts.ts.tv_nsec) ? 1 : 0;
+ return msg_sots_valid(m) ? 0 : 1;
}
diff --git a/msg.h b/msg.h
index 3fa5833..12e6ce8 100644
--- a/msg.h
+++ b/msg.h
@@ -339,6 +339,16 @@ void msg_put(struct ptp_message *m);
int msg_sots_missing(struct ptp_message *m);

/**
+ * Test whether a message has a valid SO_TIMESTAMPING time stamp.
+ * @param m Message to test.
+ * @return One if the message has a valid time stamp, zero otherwise.
+ */
+static inline int msg_sots_valid(struct ptp_message *m)
+{
+ return (m->hwts.ts.tv_sec || m->hwts.ts.tv_nsec) ? 1 : 0;
+}
+
+/**
* Work around buggy 802.1AS switches.
*/
extern int assume_two_step;

[Richard Cochran]

Signed-off-by: Richard Cochran <***@gmail.com>
---
port.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/port.c b/port.c
index 475d3e4..25265f7 100644
--- a/port.c
+++ b/port.c
@@ -2188,7 +2188,7 @@ enum fsm_event port_event(struct port *p, int fd_index)
msg_put(msg);
return EV_NONE;
}
- if (msg->hwts.ts.tv_sec && msg->hwts.ts.tv_nsec) {
+ if (msg_sots_valid(msg)) {
clock_check_ts(p->clock, msg->hwts.ts);
}
if (port_ignore(p, msg)) {

[Richard Cochran]

Signed-off-by: Richard Cochran <***@gmail.com>
---
port.c | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/port.c b/port.c
index 25265f7..aa9354b 100644
--- a/port.c
+++ b/port.c
@@ -313,6 +313,22 @@ static void fc_prune(struct foreign_clock *fc)
}
}

+static void ts_add(struct timespec *ts, int ns)
+{
+ if (!ns) {
+ return;
+ }
+ ts->tv_nsec += ns;
+ while (ts->tv_nsec < 0) {
+ ts->tv_nsec += (long) NS_PER_SEC;
+ ts->tv_sec--;
+ }
+ while (ts->tv_nsec >= (long) NS_PER_SEC) {
+ ts->tv_nsec -= (long) NS_PER_SEC;
+ ts->tv_sec++;
+ }
+}
+
static void ts_to_timestamp(struct timespec *src, struct Timestamp *dst)
{
dst->seconds_lsb = src->tv_sec;
@@ -492,7 +508,13 @@ static int peer_prepare_and_send(struct port *p, struct ptp_message *msg,
return -1;
}
cnt = transport_peer(p->trp, &p->fda, event, msg);
- return cnt <= 0 ? -1 : 0;
+ if (cnt <= 0) {
+ return -1;
+ }
+ if (msg_sots_valid(msg)) {
+ ts_add(&msg->hwts.ts, p->pod.tx_timestamp_offset);
+ }
+ return 0;
}

static int port_capable(struct port *p)
@@ -2189,6 +2211,7 @@ enum fsm_event port_event(struct port *p, int fd_index)
return EV_NONE;
}
if (msg_sots_valid(msg)) {
+ ts_add(&msg->hwts.ts, -p->pod.rx_timestamp_offset);
clock_check_ts(p->clock, msg->hwts.ts);
}
if (port_ignore(p, msg)) {
@@ -2258,7 +2281,13 @@ int port_prepare_and_send(struct port *p, struct ptp_message *msg, int event)
if (msg_pre_send(msg))
return -1;
cnt = transport_send(p->trp, &p->fda, event, msg);
- return cnt <= 0 ? -1 : 0;
+ if (cnt <= 0) {
+ return -1;
+ }
+ if (msg_sots_valid(msg)) {
+ ts_add(&msg->hwts.ts, p->pod.tx_timestamp_offset);
+ }
+ return 0;
}

struct PortIdentity port_identity(struct port *p)

[Keller, Jacob E]

Excellent series.

I know that some of the Intel hardware has measurable delays, and we were thinking of whether it was better to hack the driver for this delay, but being able to do it generically here is a good way to avoid having to modify the driver for this.

Thanks,
Jake

-----Original Message-----
Sent: Saturday, December 06, 2014 1:59 PM
Subject: [Linuxptp-devel] [PATCH RFC 4/4] port: correct transmit and
receive time stamps for their calibrated delays.
---
port.c | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/port.c b/port.c
index 25265f7..aa9354b 100644
--- a/port.c
+++ b/port.c
@@ -313,6 +313,22 @@ static void fc_prune(struct foreign_clock *fc)
}
}
+static void ts_add(struct timespec *ts, int ns)
+{
+ if (!ns) {
+ return;
+ }
+ ts->tv_nsec += ns;
+ while (ts->tv_nsec < 0) {
+ ts->tv_nsec += (long) NS_PER_SEC;
+ ts->tv_sec--;
+ }
+ while (ts->tv_nsec >= (long) NS_PER_SEC) {
+ ts->tv_nsec -= (long) NS_PER_SEC;
+ ts->tv_sec++;
+ }
+}
+
static void ts_to_timestamp(struct timespec *src, struct Timestamp *dst)
{
dst->seconds_lsb = src->tv_sec;
@@ -492,7 +508,13 @@ static int peer_prepare_and_send(struct port *p,
struct ptp_message *msg,
return -1;
}
cnt = transport_peer(p->trp, &p->fda, event, msg);
- return cnt <= 0 ? -1 : 0;
+ if (cnt <= 0) {
+ return -1;
+ }
+ if (msg_sots_valid(msg)) {
+ ts_add(&msg->hwts.ts, p->pod.tx_timestamp_offset);
+ }
+ return 0;
}
static int port_capable(struct port *p)
@@ -2189,6 +2211,7 @@ enum fsm_event port_event(struct port *p, int fd_index)
return EV_NONE;
}
if (msg_sots_valid(msg)) {
+ ts_add(&msg->hwts.ts, -p->pod.rx_timestamp_offset);
clock_check_ts(p->clock, msg->hwts.ts);
}
if (port_ignore(p, msg)) {
@@ -2258,7 +2281,13 @@ int port_prepare_and_send(struct port *p,
struct ptp_message *msg, int event)
if (msg_pre_send(msg))
return -1;
cnt = transport_send(p->trp, &p->fda, event, msg);
- return cnt <= 0 ? -1 : 0;
+ if (cnt <= 0) {
+ return -1;
+ }
+ if (msg_sots_valid(msg)) {
+ ts_add(&msg->hwts.ts, p->pod.tx_timestamp_offset);
+ }
+ return 0;
}
struct PortIdentity port_identity(struct port *p)
--
1.7.10.4
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.
clktrk
_______________________________________________
Linuxptp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Richard Cochran]

Signed-off-by: Richard Cochran <***@gmail.com>
---
config.c | 12 ++++++++++++
default.cfg | 2 ++
ds.h | 2 ++
gPTP.cfg | 2 ++
ptp4l.8 | 12 ++++++++++++
ptp4l.c | 2 ++
6 files changed, 32 insertions(+)

diff --git a/config.c b/config.c
index d5fa378..f9efca0 100644
--- a/config.c
+++ b/config.c
@@ -132,6 +132,18 @@ static enum parser_result parse_pod_setting(const char *option,
return r;
pod->min_neighbor_prop_delay = val;

+ } else if (!strcmp(option, "tx_timestamp_offset")) {
+ r = get_ranged_int(value, &val, INT_MIN, INT_MAX);
+ if (r != PARSED_OK)
+ return r;
+ pod->tx_timestamp_offset = val;
+
+ } else if (!strcmp(option, "rx_timestamp_offset")) {
+ r = get_ranged_int(value, &val, INT_MIN, INT_MAX);
+ if (r != PARSED_OK)
+ return r;
+ pod->rx_timestamp_offset = val;
+
} else if (!strcmp(option, "fault_badpeernet_interval")) {
pod->flt_interval_pertype[FT_BAD_PEER_NETWORK].type = FTMO_LINEAR_SECONDS;
if (!strcasecmp("ASAP", value)) {
diff --git a/default.cfg b/default.cfg
index 9e794ba..840a545 100644
--- a/default.cfg
+++ b/default.cfg
@@ -70,6 +70,8 @@ delay_mechanism E2E
time_stamping hardware
delay_filter moving_median
delay_filter_length 10
+tx_timestamp_offset 0
+rx_timestamp_offset 0
#
# Clock description
#
diff --git a/ds.h b/ds.h
index ea25fbb..00260ed 100644
--- a/ds.h
+++ b/ds.h
@@ -137,6 +137,8 @@ struct port_defaults {
struct fault_interval flt_interval_pertype[FT_CNT];
UInteger32 neighborPropDelayThresh; /*nanoseconds*/
int min_neighbor_prop_delay; /*nanoseconds*/
+ int tx_timestamp_offset; /*nanoseconds*/
+ int rx_timestamp_offset; /*nanoseconds*/
};

#endif
diff --git a/gPTP.cfg b/gPTP.cfg
index e15a05a..0e155a0 100644
--- a/gPTP.cfg
+++ b/gPTP.cfg
@@ -69,3 +69,5 @@ delay_mechanism P2P
time_stamping hardware
delay_filter moving_median
delay_filter_length 10
+tx_timestamp_offset 0
+rx_timestamp_offset 0
diff --git a/ptp4l.8 b/ptp4l.8
index 687beb6..7dd579b 100644
--- a/ptp4l.8
+++ b/ptp4l.8
@@ -205,6 +205,18 @@ The default is moving_median.
.B delay_filter_length
The length of the delay filter in samples.
The default is 10.
+.TP
+.B tx_timestamp_offset
+Specifies the difference in nanoseconds between the actual transmission
+time at the reference plane and the reported transmit time stamp. This
+value will be added to egress time stamps obtained from the hardware.
+The default is 0.
+.TP
+.B rx_timestamp_offset
+Specifies the difference in nanoseconds between the reported receive
+time stamp and the actual reception time at reference plane. This value
+will be subtracted from ingress time stamps obtained from the hardware.
+The default is 0.

.SH PROGRAM AND CLOCK OPTIONS

diff --git a/ptp4l.c b/ptp4l.c
index 83824f7..c18406f 100644
--- a/ptp4l.c
+++ b/ptp4l.c
@@ -92,6 +92,8 @@ static struct config cfg_settings = {
/* Default to very a large neighborPropDelay threshold */
.neighborPropDelayThresh = 20000000,
.min_neighbor_prop_delay = -20000000,
+ .tx_timestamp_offset = 0,
+ .rx_timestamp_offset = 0,
},

.timestamping = TS_HARDWARE,

[Delio Brignoli]

Hello Richard,

We implemented this correction in our driver using a private IOCTL and it would have been nice to have used some standardised interface instead. However, I think timestamp correction belongs in the PHY’s driver (or whatever is doing the times-tamping). Data sheets report expected delays so defaults can be automatic and the corrections can be changed automatically according to link-speed for instance. There should also be a standardised mechanism to update correction offsets at runtime as a fallback mechanism when defaults are not good enough.

Having said that, having TX/RX timestamps correction also in linuxptp is a good idea! My comments:
(1) In some cases is not acceptable to restart linuxptp, so being able to change the correction at runtime would be useful. This could be added later.
(2) For some reason I would prefer (but not strongly) adding a signed correction offset in both the egress and ingress directions instead of adding in one direction and subtracting in the other.

Thanks
--
Delio

Post by Richard Cochran
Most (or all?) hardware provides time stamps that are offset from the
actual point at the reference plane. The amount of delay is asymmetrical
between ingress and egress, and depending on the particular technology,
MAC or PHY, and link speed, there can be jitter in the delay.
Sometimes the manufacturer specifies the amount of expected delay. This
patch series provides a way for the user to correct the delays based on
values from the data sheet or based on empirical data.
In theory one could place the sum of the correction factors into the
delayAsymmetry field. However, the standard specifies that the slave
applies this correction field, and never the master. Having these two
new correction fields allows each node to compensate for its own part
of the offset error.
This series was tested with an i210 paired with a dp83640 using a short
cable. These devices have their delay values listed in the data sheet.
PPS signals in both directions showed a remaining offset of about 120
nanoseconds, which matches the sum of uncertainties (40 and 80) given
for the i210 card at the 100 MBit link speed.
Comments are welcome.
Thanks,
Richard
Introduce a helper function to identify valid (non-zero) time stamps.
Invoke the clock check even if the time stamp nanoseconds field is
zero.
config: Introduce options for correcting transmit and receive delays.
port: correct transmit and receive time stamps for their calibrated
delays.
config.c | 12 ++++++++++++
default.cfg | 2 ++
ds.h | 2 ++
gPTP.cfg | 2 ++
msg.c | 2 +-
msg.h | 10 ++++++++++
port.c | 35 ++++++++++++++++++++++++++++++++---
ptp4l.8 | 12 ++++++++++++
ptp4l.c | 2 ++
9 files changed, 75 insertions(+), 4 deletions(-)
--
1.7.10.4
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Linuxptp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Richard Cochran]

Delio,

Thanks for the feedback...

Post by Delio Brignoli
We implemented this correction in our driver using a private IOCTL
and it would have been nice to have used some standardised interface
instead. However, I think timestamp correction belongs in the PHY’s
driver (or whatever is doing the times-tamping). Data sheets report
expected delays so defaults can be automatic and the corrections can
be changed automatically according to link-speed for instance.

I agree that the drivers should ideally correct this. However, there
are many issues to tackle, including lack of vendor documentation,
incorrect vendor documentation, MAC time stamping drivers not knowing
the PHY delay or even the PHY type, and so on.

Because providing corrections in-kernel will be spotty at best, maybe
it better just to say, Linux drivers do *not* correct these delays. At
leas that makes things consistent. Otherwise end users will have to
comb through the kernel source in order to figure out whether the
corrections in the data sheet are implemented or not.

Post by Delio Brignoli
There
should also be a standardised mechanism to update correction offsets
at runtime as a fallback mechanism when defaults are not good
enough.

Do you mean a standard method in the kernel for drivers to use?
Right, so no matter what the kernel does, we will always need to be
able to correct mistakes in data sheets, drivers, or simply to handle
different kernel versions (should drivers suddenly start correcting the
delays).

Post by Delio Brignoli
(1) In some cases is not acceptable to restart linuxptp, so being
able to change the correction at runtime would be useful. This could
be added later.

Yes.

Post by Delio Brignoli
(2) For some reason I would prefer (but not strongly) adding a
signed correction offset in both the egress and ingress directions
instead of adding in one direction and subtracting in the other.

So far, the data sheets I have seen give these corrections as positive
numbers for both egress and ingress delays. The idea was to allow the
user to simply enter the values from the data sheet into the
configuration file.

Thanks,
Richard

[Delio Brignoli]

Hi Richard,

On 08 Dec 2014, at 13:33, Richard Cochran <***@gmail.com> wrote:
[…]

Post by Richard Cochran
Because providing corrections in-kernel will be spotty at best, maybe
it better just to say, Linux drivers do *not* correct these delays. At
leas that makes things consistent. Otherwise end users will have to
comb through the kernel source in order to figure out whether the
corrections in the data sheet are implemented or not.

Post by Delio Brignoli
There
should also be a standardised mechanism to update correction offsets
at runtime as a fallback mechanism when defaults are not good
enough.

Do you mean a standard method in the kernel for drivers to use?

Yes, I was thinking it would allow to query if the driver supports this feature and get/set current offsets.
This way user-mode applications would know if the driver already corrects timestamps (and by how much) and decide if it should apply its own corrections or not. I see your point but that kind of argument could be applied to most opt-in driver features. No extra work would be required for drivers which do not opt-in.

Regardless of where the correction is applied there should be a way to query/set the currently applied offsets at runtime. I’d think the obvious choice for linuxptp would be an implementation specific management interface message.

Post by Richard Cochran

Post by Delio Brignoli
(2) For some reason I would prefer (but not strongly) adding a
signed correction offset in both the egress and ingress directions
instead of adding in one direction and subtracting in the other.

So far, the data sheets I have seen give these corrections as positive
numbers for both egress and ingress delays. The idea was to allow the
user to simply enter the values from the data sheet into the
configuration file.

ACK, good point.

Post by Richard Cochran
Thanks,
Richard

[Richard Cochran]

Post by Delio Brignoli
Regardless of where the correction is applied there should be a way
to query/set the currently applied offsets at runtime. I’d think the
obvious choice for linuxptp would be an implementation specific
management interface message.

Yes, I agree.

As you said, this can be added later on...

Post by Delio Brignoli

Post by Richard Cochran

Post by Delio Brignoli
(2) For some reason I would prefer (but not strongly) adding a
signed correction offset in both the egress and ingress directions
instead of adding in one direction and subtracting in the other.

So far, the data sheets I have seen give these corrections as positive
numbers for both egress and ingress delays. The idea was to allow the
user to simply enter the values from the data sheet into the
configuration file.

ACK, good point.

Someone pointed out to me off-list that these corrections are
standardized, and they are *not* part of the delayAsymmetry field.

In 802.1AS they are defined in Section 8.4.3 as "egressLatency" and
"ingressLatency", and 1588 uses an almost identical definition.

I will respin this series to make the configuration options have the
same names as in the standards.

Thanks,
Richard

[Jiri Benc]

Post by Delio Brignoli
Yes, I was thinking it would allow to query if the driver supports this
feature and get/set current offsets.

I agree. That way, with correctly implemented drivers the user will
get the right correction for free but will be still able to overrule
the values.

What I'm thinking of is having an ethtool operation to get/set
ingress/egress correction. This will be handled in the kernel (i.e. not
propagated to the drivers to prevent misuse). The driver provides
initial correction values (or zero if they're unknown) but user space
is free to alter them or reset them to the initial values. It is
obviously per-interface setting.

A nice bonus is this will work with all program using the time stamping
interface, not just linuxptp.

This is compatible with Richard's patchset, only the config options
would call the ethtool op instead of doing the correction in ptp4l.

Jiri

[Delio Brignoli]

Hello Jiri,

Post by Jiri Benc

Post by Delio Brignoli
Yes, I was thinking it would allow to query if the driver supports this
feature and get/set current offsets.

I agree. That way, with correctly implemented drivers the user will
get the right correction for free but will be still able to overrule
the values.

[…]

Post by Jiri Benc
This is compatible with Richard's patchset, only the config options
would call the ethtool op instead of doing the correction in ptp4l.

I just wanted to point out that, in the scenario above, correctly implemented drivers and user mode applications should also track link state changes (link speed mostly, but other factors could affect latency) and update corrections accordingly. Drivers should probably be given a chance to update the correction before user-mode is notified or you’d end up with driver defaults overriding user-mode settings.

Regards
--
Delio

[Jiri Benc]

Post by Delio Brignoli
I just wanted to point out that, in the scenario above, correctly
implemented drivers and user mode applications should also track link
state changes (link speed mostly, but other factors could affect
latency) and update corrections accordingly. Drivers should probably be
given a chance to update the correction before user-mode is notified or
you’d end up with driver defaults overriding user-mode settings.

You're right, that complicates things and means we'll need user space
to be involved in the decision anyway. And when the user space needs to
listen for link changes and act on them, there's no reason to put
complicated logic into the kernel. Seems that an interface to query
the driver for the current suggested correction is enough and the
actual addition/subtraction should be indeed done in ptp4l. It also
seems that ptp4l will need to listen for link change events.

Jiri

[Richard Cochran]

Post by Jiri Benc
actual addition/subtraction should be indeed done in ptp4l. It also
seems that ptp4l will need to listen for link change events.

Or this can be done by a helper program.

Thanks,
Richard

[Keller, Jacob E]

-----Original Message-----
Sent: Wednesday, December 10, 2014 7:54 AM
To: Jiri Benc
Subject: Re: [Linuxptp-devel] [PATCH RFC 0/4] Time stamp asymmetry
correction

Post by Jiri Benc
actual addition/subtraction should be indeed done in ptp4l. It also
seems that ptp4l will need to listen for link change events.

Or this can be done by a helper program.
Thanks,
Richard
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and
Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/os
tg.clktrk

A helper program which queries link speed changes, (or any other possible changes which affect latency) and uses an ethtool (or ptp maybe?) ioctl to get the suggested latency with "0" being the default for unimplemented.

Then it can suggest the value and user can override it if necessary.

This seems like the simplest solution.

Thanks,
Jake

[Keller, Jacob E]

-----Original Message-----
Sent: Wednesday, December 10, 2014 12:11 AM
To: Delio Brignoli
Subject: Re: [Linuxptp-devel] [PATCH RFC 0/4] Time stamp asymmetry
correction

Post by Delio Brignoli
Yes, I was thinking it would allow to query if the driver supports this
feature and get/set current offsets.

I agree. That way, with correctly implemented drivers the user will
get the right correction for free but will be still able to overrule
the values.
What I'm thinking of is having an ethtool operation to get/set
ingress/egress correction. This will be handled in the kernel (i.e. not
propagated to the drivers to prevent misuse). The driver provides
initial correction values (or zero if they're unknown) but user space
is free to alter them or reset them to the initial values. It is
obviously per-interface setting.
A nice bonus is this will work with all program using the time stamping
interface, not just linuxptp.
This is compatible with Richard's patchset, only the config options
would call the ethtool op instead of doing the correction in ptp4l.
Jiri
--

I really like this idea. Done in the kernel, but allow driver to initiate correct values if necessary. It does need to support link speeds somehow so that change in link speed gets the correct values.

Not 100% sure the best way to handle link speeds, but definitely would be better to do this in kernel.

Regards,
Jake