On Fri, Jun 19, 2020 at 03:26:48PM +0300, Vladimir Oltean wrote:
> if (flags == MSG_ERRQUEUE) {
> struct pollfd pfd = { fd, sk_events, 0 };
> res = poll(&pfd, 1, sk_tx_timeout);
> if (res < 1) {
> pr_err(res ? "poll for tx timestamp failed: %m" :
> "timed out while polling for tx timestamp");
> pr_err("increasing tx_timestamp_timeout may correct "
> "this issue, but it is likely caused by a driver bug");
> return -errno;
>
> What business has ptp4l to say that TX timestamps not being delivered
> within 1 ms to the application are indicative of a driver bug? You and
> I know full well that there's a lot of hardware which simply can't
> deliver timestamps that fast, and that there's nothing wrong with it.
Correct, and the timeout is configurable beyond the 1 ms default.
> No need to shame here, really.
This is printing a helpful message to let the user set an appropriate
timeout value for their system.
> Why would the network stack need additional validation via software
> timestamps? I mean, it's not ptp4l's fault that timestamps were not
> delivered in the right order. I thought the linuxptp suite is trying
> to be helpful instead of pedantic, I'm starting to change my opinion.
You are certainly entitled to your opinions!
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
