Messages in this thread | | | Date | Wed, 26 Jul 2023 08:43:22 -0700 | From | Richard Cochran <> | Subject | Re: [PATCH v2] net: stmmac: correct MAC propagation delay |
| |
On Wed, Jul 26, 2023 at 08:10:35AM +0200, Johannes Zink wrote:
> Also on a side-note, "driver nonsense" sounds a bit harsh from someone > always insisting that one should not compensate for bad drivers in the > userspace stack and instead fixing driver and hardware issues in the kernel, > don't you think?
Everything has its place.
The proper place to account for delay asymmetries is in the user space configuration, for example in linuxptp you have
delayAsymmetry The time difference in nanoseconds of the transmit and receive paths. This value should be positive when the server-to-client propagation time is longer and negative when the client-to- server time is longer. The default is 0 nanoseconds.
egressLatency Specifies the difference in nanoseconds between the actual transmission time at the reference plane and the reported trans‐ mit time stamp. This value will be added to egress time stamps obtained from the hardware. The default is 0.
ingressLatency Specifies the difference in nanoseconds between the reported re‐ ceive 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.
Trying to hard code those into the driver? Good luck getting that right for everyone.
BTW this driver is actually for an IP core used in many, many SoCs.
How many _other_ SoCs did you test your patch on?
Thanks, Richard
| |