From: Miroslav Lichvar <mlichvar@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
Richard Cochran <richardcochran@gmail.com>,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH v4 net-next 6/7] net: allow simultaneous SW and HW transmit timestamping
Date: Fri, 19 May 2017 12:00:40 +0200 [thread overview]
Message-ID: <20170519100040.GB21003@localhost> (raw)
In-Reply-To: <CAF=yD-KVwq+WXZNoZH+Vbs8-aMWF969AxzTqBZSKfFyDqszRNQ@mail.gmail.com>
On Thu, May 18, 2017 at 04:16:26PM -0400, Willem de Bruijn wrote:
> On Thu, May 18, 2017 at 9:06 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> > +/* On transmit, software and hardware timestamps are returned independently.
> > + * As the two skb clones share the hardware timestamp, which may be updated
> > + * before the software timestamp is received, a hardware TX timestamp may be
> > + * returned only if there is no software TX timestamp. A false software
> > + * timestamp made for SOCK_RCVTSTAMP when a real timestamp is missing must
> > + * be ignored.
>
> Please expand on why this case can be ignored. It is quite subtle. How about
> something like
>
> *
> * A false software timestamp is one made inside the __sock_recv_timestamp
> * call itself. These are generated whenever SO_TIMESTAMP(NS) is enabled
> * on the socket, even when the timestamp reported is for another option, such
> * as hardware tx timestamp.
> *
> * Ignore these when deciding whether a timestamp source is hw or sw.
> */
That seems a bit too verbose to me. :) Would the following work?
/* On transmit, software and hardware timestamps are returned independently.
* As the two skb clones share the hardware timestamp, which may be updated
* before the software timestamp is received, a hardware TX timestamp may be
* returned only if there is no software TX timestamp. Ignore false software
* timestamps, which may be made in the __sock_recv_timestamp() call when the
* option SO_TIMESTAMP(NS) is enabled on the socket, even when the skb has a
* hardware timestamp.
*/
> > +static bool skb_is_swtx_tstamp(const struct sk_buff *skb,
> > + const struct sock *sk, int false_tstamp)
> > +{
> > + if (false_tstamp && sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TX_SWHW)
>
> Also, why is it ignored only for the new mode?
Good point. That should not be there. The function can be now reduced
to a single line again. I originally tried a different approach,
disabling false timestamps in the new mode, but then I thought it's
better to not complicate it unnecessarily and keep it consistent.
--
Miroslav Lichvar
next prev parent reply other threads:[~2017-05-19 10:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 13:06 [PATCH v4 net-next 0/7] Extend socket timestamping API Miroslav Lichvar
2017-05-18 13:06 ` [PATCH v4 net-next 1/7] net: define receive timestamp filter for NTP Miroslav Lichvar
2017-05-18 13:06 ` [PATCH v4 net-next 2/7] net: ethernet: update drivers to handle HWTSTAMP_FILTER_NTP_ALL Miroslav Lichvar
2017-05-18 13:06 ` [PATCH v4 net-next 3/7] net: add function to retrieve original skb device using NAPI ID Miroslav Lichvar
2017-05-18 13:06 ` [PATCH v4 net-next 4/7] net: add new control message for incoming HW-timestamped packets Miroslav Lichvar
2017-05-18 13:06 ` [PATCH v4 net-next 5/7] net: fix documentation of struct scm_timestamping Miroslav Lichvar
2017-05-18 13:06 ` [PATCH v4 net-next 6/7] net: allow simultaneous SW and HW transmit timestamping Miroslav Lichvar
2017-05-18 20:16 ` Willem de Bruijn
2017-05-19 10:00 ` Miroslav Lichvar [this message]
2017-05-19 14:52 ` Willem de Bruijn
2017-05-18 13:06 ` [PATCH v4 net-next 7/7] net: ethernet: update drivers to make both SW and HW TX timestamps Miroslav Lichvar
2017-05-18 13:20 ` [PATCH v4 net-next 0/7] Extend socket timestamping API Miroslav Lichvar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170519100040.GB21003@localhost \
--to=mlichvar@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).