netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Network Development <netdev@vger.kernel.org>
Subject: Re: What is SOF_TIMESTAMPING_RX_HARDWARE?
Date: Tue, 4 Mar 2014 18:38:05 +0100	[thread overview]
Message-ID: <20140304173804.GA4279@netboy> (raw)
In-Reply-To: <CALCETrWa5NcTD+fAz1-Xf4hJPoQ=cG6Z44WMUukaWxe=kGB3kQ@mail.gmail.com>

On Tue, Mar 04, 2014 at 09:21:47AM -0800, Andy Lutomirski wrote:
> SOF_TIMESTAMPING_RX_HARDWARE:  return the original, unmodified time stamp
>                                as generated by the hardware
> SOF_TIMESTAMPING_RX_SOFTWARE:  if SOF_TIMESTAMPING_RX_HARDWARE is off or
>                                fails, then do it in software
> SOF_TIMESTAMPING_RAW_HARDWARE: return original raw hardware time stamp
> SOF_TIMESTAMPING_SYS_HARDWARE: return hardware time stamp transformed to
>                                the system time base
> 
> which is somewhere between useless and incorrect.

Right, especially since there is no fallback to SW time stamping on
receive. Every incoming skb gets a SW time stamp.

> I'd write a patch to get rid of SOCK_TIMESTAMPING_RX_HARDWARE, etc,
> but that might break a program that sets the flag in setsockopt and
> expects it to be returned by getsockopt.

There are programs setting this socket option. I am afraid that you
will not be able to remove this, otherwise you will break them.

> In theory, the driver could stop reporting timestamps if
> SOF_TIMESTAMPING_RAW_HARDWARE: and SOF_TIMESTAMPING_SYS_HARDWARE
> aren't set.  I don't see why SOF_TIMESTAMPING_RX_HARDWARE would make
> any sense in this context.

The lack of SOF_TIMESTAMPING_RX_HARDWARE would prevent the driver from
taking the HW time stamps, but the driver knows nothing about the
awaiting sockets. Possibly the kernel could tell drivers when this
flag is present on any socket that might be associated with a
particular interface, but I doubt that would buy us anything. So the
API makes some kind of sense in theory, but it practice the networking
stack just ignores this option.

Thanks,
Richard

  reply	other threads:[~2014-03-04 17:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-04  2:20 What is SOF_TIMESTAMPING_RX_HARDWARE? Andy Lutomirski
2014-03-04 10:10 ` Richard Cochran
2014-03-04 17:21   ` Andy Lutomirski
2014-03-04 17:38     ` Richard Cochran [this message]
2014-03-04 17:42     ` Richard Cochran
2014-03-04 17:45       ` Andy Lutomirski

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=20140304173804.GA4279@netboy \
    --to=richardcochran@gmail.com \
    --cc=luto@amacapital.net \
    --cc=netdev@vger.kernel.org \
    /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).