On Fri, 19 Jun 2020 at 15:36, Richard Cochran <richardcoch...@gmail.com> wrote:
>
> 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
Ok, and this patch does not have a place in linuxptp because?
Thanks,
-Vladimir
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
