Re: [Linuxptp-devel] [PATCH v2 1/3] ptp4l: call recvmsg() with the MSG_DONTWAIT flag

[Vladimir O. <ol...@gm...>]

On Fri, 19 Jun 2020 at 15:36, Richard Cochran <ric...@gm...> 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