05 Apr, 2016

1 commit


18 Jul, 2015

1 commit

  • This patch adds some clarification about the intended way to implement
    both SIOCSHWTSTAMP and ethtool's get_ts_info. The HWTSTAMP API has
    several Rx filters which are very specific, as well as more general
    filters. The specific filters really only exist to support some broken
    hardware which can't fully implement the generic filters. This patch
    adds clarification that it is okay to support the specific filters in
    SIOCSHWTSTAMP by upscaling them to the generic filters. In addition,
    update the header for ethtool_ts_info to specify that drivers ought to
    only report the filters they support without upscaling in this manner.

    Signed-off-by: Jacob Keller
    Acked-by: Richard Cochran
    Tested-by: Phil Schmitt
    Reviewed-by: Aaron Brown
    Signed-off-by: Jeff Kirsher

    Jacob Keller
     

03 Feb, 2015

1 commit

  • Add timestamping option SOF_TIMESTAMPING_OPT_TSONLY. For transmit
    timestamps, this loops timestamps on top of empty packets.

    Doing so reduces the pressure on SO_RCVBUF. Payload inspection and
    cmsg reception (aside from timestamps) are no longer possible. This
    works together with a follow on patch that allows administrators to
    only allow tx timestamping if it does not loop payload or metadata.

    Signed-off-by: Willem de Bruijn

    ----

    Changes (rfc -> v1)
    - add documentation
    - remove unnecessary skb->len test (thanks to Richard Cochran)
    Signed-off-by: David S. Miller

    Willem de Bruijn
     

09 Dec, 2014

2 commits

  • Documentation:
    expand explanation of timestamp counter

    Test:
    new: flag -I requests and prints PKTINFO
    new: flag -x prints payload (possibly truncated)
    fix: remove pretty print that breaks common flag '-l 1'

    Signed-off-by: Willem de Bruijn
    Signed-off-by: David S. Miller

    Willem de Bruijn
     
  • Allow reading of timestamps and cmsg at the same time on all relevant
    socket families. One use is to correlate timestamps with egress
    device, by asking for cmsg IP_PKTINFO.

    on AF_INET sockets, call the relevant function (ip_cmsg_recv). To
    avoid changing legacy expectations, only do so if the caller sets a
    new timestamping flag SOF_TIMESTAMPING_OPT_CMSG.

    on AF_INET6 sockets, IPV6_PKTINFO and all other recv cmsg are already
    returned for all origins. only change is to set ifindex, which is
    not initialized for all error origins.

    In both cases, only generate the pktinfo message if an ifindex is
    known. This is not the case for ACK timestamps.

    The difference between the protocol families is probably a historical
    accident as a result of the different conditions for generating cmsg
    in the relevant ip(v6)_recv_error function:

    ipv4: if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP) {
    ipv6: if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL) {

    At one time, this was the same test bar for the ICMP/ICMP6
    distinction. This is no longer true.

    Signed-off-by: Willem de Bruijn

    ----

    Changes
    v1 -> v2
    large rewrite
    - integrate with existing pktinfo cmsg generation code
    - on ipv4: only send with new flag, to maintain legacy behavior
    - on ipv6: send at most a single pktinfo cmsg
    - on ipv6: initialize fields if not yet initialized

    The recv cmsg interfaces are also relevant to the discussion of
    whether looping packet headers is problematic. For v6, cmsgs that
    identify many headers are already returned. This patch expands
    that to v4. If it sounds reasonable, I will follow with patches

    1. request timestamps without payload with SOF_TIMESTAMPING_OPT_TSONLY
    (http://patchwork.ozlabs.org/patch/366967/)
    2. sysctl to conditionally drop all timestamps that have payload or
    cmsg from users without CAP_NET_RAW.
    Signed-off-by: David S. Miller

    Willem de Bruijn
     

26 Nov, 2014

1 commit


02 Sep, 2014

1 commit

  • Expand Documentation/networking/timestamping.txt with new
    interfaces and bytestream timestamping. Also minor
    cleanup of the other text.

    Import txtimestamp.c test of the new features.

    Signed-off-by: Willem de Bruijn
    Signed-off-by: David S. Miller

    Willem de Bruijn
     

30 Jul, 2014

1 commit

  • The SO_TIMESTAMPING API defines three types of timestamps: software,
    hardware in raw format (hwtstamp) and hardware converted to system
    format (syststamp). The last has been deprecated in favor of combining
    hwtstamp with a PTP clock driver. There are no active users in the
    kernel.

    The option was device driver dependent. If set, but without hardware
    support, the correct behavior is to return zero in the relevant field
    in the SCM_TIMESTAMPING ancillary message. Without device drivers
    implementing the option, this field is effectively always zero.

    Remove the internal plumbing to dissuage new drivers from implementing
    the feature. Keep the SOF_TIMESTAMPING_SYS_HARDWARE flag, however, to
    avoid breaking existing applications that request the timestamp.

    Signed-off-by: Willem de Bruijn
    Signed-off-by: David S. Miller

    Willem de Bruijn
     

16 Jul, 2014

1 commit

  • The SO_TIMESTAMPING API defines option SOF_TIMESTAMPING_SYS_HW.
    This feature is deprecated. It should not be implemented by new
    device drivers. Existing drivers do not implement it, either --
    with one exception.

    Driver developers are encouraged to expose the NIC hw clock as a
    PTP HW clock source, instead, and synchronize system time to the
    HW source.

    The control flag cannot be removed due to being part of the ABI, nor
    can the structure scm_timestamping that is returned. Due to the one
    legacy driver, the internal datapath and structure are not removed.

    This patch only clearly marks the interface as deprecated. Device
    drivers should always return a syststamp value of zero.

    Signed-off-by: Willem de Bruijn

    ----

    We can consider adding a WARN_ON_ONCE in__sock_recv_timestamp
    if non-zero syststamp is encountered
    Acked-by: Richard Cochran
    Signed-off-by: David S. Miller

    Willem de Bruijn
     

19 Mar, 2014

1 commit

  • Since cd4d8fdad1f1 ("net: kernel panic in dev_hard_start_xmit:
    remove faulty software TX time stamping") dev_hard_start_xmit()
    will not provide software timestamps. It's a responsibility of
    the drivers to call skb_tx_timestamp() at the right time.

    Cc: linux-doc@vger.kernel.org
    Signed-off-by: Jakub Kicinski
    Signed-off-by: David S. Miller

    Jakub Kicinski
     

07 Mar, 2014

1 commit

  • The original documentation was very unclear.

    The code fix is presumably related to the formerly unclear
    documentation: SOCK_TIMESTAMPING_RX_SOFTWARE has no effect on
    __sock_recv_timestamp's behavior, so calling __sock_recv_ts_and_drops
    from sock_recv_ts_and_drops if only SOCK_TIMESTAMPING_RX_SOFTWARE is
    set is pointless. This should have no user-observable effect.

    Signed-off-by: Andy Lutomirski
    Acked-by: Richard Cochran
    Signed-off-by: David S. Miller

    Andrew Lutomirski
     

20 Nov, 2013

1 commit


19 Aug, 2010

1 commit

  • This patch removes the abstraction introduced by the union skb_shared_tx in
    the shared skb data.

    The access of the different union elements at several places led to some
    confusion about accessing the shared tx_flags e.g. in skb_orphan_try().

    http://marc.info/?l=linux-netdev&m=128084897415886&w=2

    Signed-off-by: Oliver Hartkopp
    Signed-off-by: David S. Miller

    Oliver Hartkopp
     

08 Apr, 2010

1 commit


16 Feb, 2009

2 commits

  • Instructions for time stamping outgoing packets are take from the
    socket layer and later copied into the new skb.

    Signed-off-by: Patrick Ohly
    Signed-off-by: David S. Miller

    Patrick Ohly
     
  • User space can request hardware and/or software time stamping.
    Reporting of the result(s) via a new control message is enabled
    separately for each field in the message because some of the
    fields may require additional computation and thus cause overhead.
    User space can tell the different kinds of time stamps apart
    and choose what suits its needs.

    When a TX timestamp operation is requested, the TX skb will be cloned
    and the clone will be time stamped (in hardware or software) and added
    to the socket error queue of the skb, if the skb has a socket
    associated with it.

    The actual TX timestamp will reach userspace as a RX timestamp on the
    cloned packet. If timestamping is requested and no timestamping is
    done in the device driver (potentially this may use hardware
    timestamping), it will be done in software after the device's
    start_hard_xmit routine.

    Signed-off-by: Patrick Ohly
    Signed-off-by: David S. Miller

    Patrick Ohly