<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/uapi/linux/net_tstamp.h, branch v6.12.80</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-09-10T23:55:23+00:00</updated>
<entry>
<title>net-timestamp: introduce SOF_TIMESTAMPING_OPT_RX_FILTER flag</title>
<updated>2024-09-10T23:55:23+00:00</updated>
<author>
<name>Jason Xing</name>
<email>kernelxing@tencent.com</email>
</author>
<published>2024-09-09T01:56:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=be8e9eb3750639aa5cffb3f764ca080caed41bd0'/>
<id>urn:sha1:be8e9eb3750639aa5cffb3f764ca080caed41bd0</id>
<content type='text'>
introduce a new flag SOF_TIMESTAMPING_OPT_RX_FILTER in the receive
path. User can set it with SOF_TIMESTAMPING_SOFTWARE to filter
out rx software timestamp report, especially after a process turns on
netstamp_needed_key which can time stamp every incoming skb.

Previously, we found out if an application starts first which turns on
netstamp_needed_key, then another one only passing SOF_TIMESTAMPING_SOFTWARE
could also get rx timestamp. Now we handle this case by introducing this
new flag without breaking users.

Quoting Willem to explain why we need the flag:
"why a process would want to request software timestamp reporting, but
not receive software timestamp generation. The only use I see is when
the application does request
SOF_TIMESTAMPING_SOFTWARE | SOF_TIMESTAMPING_TX_SOFTWARE."

Similarly, this new flag could also be used for hardware case where we
can set it with SOF_TIMESTAMPING_RAW_HARDWARE, then we won't receive
hardware receive timestamp.

Another thing about errqueue in this patch I have a few words to say:
In this case, we need to handle the egress path carefully, or else
reporting the tx timestamp will fail. Egress path and ingress path will
finally call sock_recv_timestamp(). We have to distinguish them.
Errqueue is a good indicator to reflect the flow direction.

Suggested-by: Willem de Bruijn &lt;willemb@google.com&gt;
Signed-off-by: Jason Xing &lt;kernelxing@tencent.com&gt;
Reviewed-by: Willem de Bruijn &lt;willemb@google.com&gt;
Link: https://patch.msgid.link/20240909015612.3856-2-kerneljasonxing@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net_tstamp: add SOF_TIMESTAMPING_OPT_ID_TCP</title>
<updated>2022-12-09T03:49:21+00:00</updated>
<author>
<name>Willem de Bruijn</name>
<email>willemb@google.com</email>
</author>
<published>2022-12-07T14:37:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b534dc46c8ae0165b1b2509be24dbea4fa9c4011'/>
<id>urn:sha1:b534dc46c8ae0165b1b2509be24dbea4fa9c4011</id>
<content type='text'>
Add an option to initialize SOF_TIMESTAMPING_OPT_ID for TCP from
write_seq sockets instead of snd_una.

This should have been the behavior from the start. Because processes
may now exist that rely on the established behavior, do not change
behavior of the existing option, but add the right behavior with a new
flag. It is encouraged to always set SOF_TIMESTAMPING_OPT_ID_TCP on
stream sockets along with the existing SOF_TIMESTAMPING_OPT_ID.

Intuitively the contract is that the counter is zero after the
setsockopt, so that the next write N results in a notification for
the last byte N - 1.

On idle sockets snd_una == write_seq and this holds for both. But on
sockets with data in transmission, snd_una records the unacked offset
in the stream. This depends on the ACK response from the peer. A
process cannot learn this in a race free manner (ioctl SIOCOUTQ is one
racy approach).

write_seq records the offset at the last byte written by the process.
This is a better starting point. It matches the intuitive contract in
all circumstances, unaffected by external behavior.

The new timestamp flag necessitates increasing sk_tsflags to 32 bits.
Move the field in struct sock to avoid growing the socket (for some
common CONFIG variants). The UAPI interface so_timestamping.flags is
already int, so 32 bits wide.

Reported-by: Sotirios Delimanolis &lt;sotodel@meta.com&gt;
Signed-off-by: Willem de Bruijn &lt;willemb@google.com&gt;
Link: https://lore.kernel.org/r/20221207143701.29861-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net_tstamp: define new flag HWTSTAMP_FLAG_BONDED_PHC_INDEX</title>
<updated>2021-12-29T20:31:36+00:00</updated>
<author>
<name>Hangbin Liu</name>
<email>liuhangbin@gmail.com</email>
</author>
<published>2021-12-29T08:09:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1bb412d46ca9df90a3fe4b704f5385f03621455d'/>
<id>urn:sha1:1bb412d46ca9df90a3fe4b704f5385f03621455d</id>
<content type='text'>
As we defined the new hwtstamp_config flag HWTSTAMP_FLAG_BONDED_PHC_INDEX
as enum, it's not easy for userspace program to check if the flag is
supported when build.

Let's define the new flag so user space could build it on old kernel with
ifdef check.

Fixes: 9c9211a3fc7a ("net_tstamp: add new flag HWTSTAMP_FLAG_BONDED_PHC_INDEX")
Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Acked-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net_tstamp: add new flag HWTSTAMP_FLAG_BONDED_PHC_INDEX</title>
<updated>2021-12-14T12:28:24+00:00</updated>
<author>
<name>Hangbin Liu</name>
<email>liuhangbin@gmail.com</email>
</author>
<published>2021-12-10T08:59:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9c9211a3fc7aa41b2952765b62000443b3bb6f23'/>
<id>urn:sha1:9c9211a3fc7aa41b2952765b62000443b3bb6f23</id>
<content type='text'>
Since commit 94dd016ae538 ("bond: pass get_ts_info and SIOC[SG]HWTSTAMP
ioctl to active device") the user could get bond active interface's
PHC index directly. But when there is a failover, the bond active
interface will change, thus the PHC index is also changed. This may
break the user's program if they did not update the PHC timely.

This patch adds a new hwtstamp_config flag HWTSTAMP_FLAG_BONDED_PHC_INDEX.
When the user wants to get the bond active interface's PHC, they need to
add this flag and be aware the PHC index may be changed.

With the new flag. All flag checks in current drivers are removed. Only
the checking in net_hwtstamp_validate() is kept.

Suggested-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: sock: extend SO_TIMESTAMPING for PHC binding</title>
<updated>2021-07-01T20:08:18+00:00</updated>
<author>
<name>Yangbo Lu</name>
<email>yangbo.lu@nxp.com</email>
</author>
<published>2021-06-30T08:11:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d463126e23f112629edb01594141ca437a92a108'/>
<id>urn:sha1:d463126e23f112629edb01594141ca437a92a108</id>
<content type='text'>
Since PTP virtual clock support is added, there can be
several PTP virtual clocks based on one PTP physical
clock for timestamping.

This patch is to extend SO_TIMESTAMPING API to support
PHC (PTP Hardware Clock) binding by adding a new flag
SOF_TIMESTAMPING_BIND_PHC. When PTP virtual clocks are
in use, user space can configure to bind one for
timestamping, but PTP physical clock is not supported
and not needed to bind.

This patch is preparation for timestamp conversion from
raw timestamp to a specific PTP virtual clock time in
core net.

Signed-off-by: Yangbo Lu &lt;yangbo.lu@nxp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ethtool: add timestamping related string sets</title>
<updated>2020-03-30T05:32:36+00:00</updated>
<author>
<name>Michal Kubecek</name>
<email>mkubecek@suse.cz</email>
</author>
<published>2020-03-27T23:01:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f76510b458a52023e96b3a700a97ffb526de17dc'/>
<id>urn:sha1:f76510b458a52023e96b3a700a97ffb526de17dc</id>
<content type='text'>
Add three string sets related to timestamping information:

  ETH_SS_SOF_TIMESTAMPING: SOF_TIMESTAMPING_* flags
  ETH_SS_TS_TX_TYPES:      timestamping Tx types
  ETH_SS_TS_RX_FILTERS:    timestamping Rx filters

These will be used for TIMESTAMP_GET request.

v2: avoid compiler warning ("enumeration value not handled in switch")
    in net_hwtstamp_validate()

v3: omit dash in Tx type names ("one-step-*" -&gt; "onestep-*"), suggested by
    Richard Cochran

Signed-off-by: Michal Kubecek &lt;mkubecek@suse.cz&gt;
Acked-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Introduce peer to peer one step PTP time stamping.</title>
<updated>2019-12-26T03:51:34+00:00</updated>
<author>
<name>Richard Cochran</name>
<email>richardcochran@gmail.com</email>
</author>
<published>2019-12-26T02:16:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b6fd7b96366769651ab23988607ce9c5c9042cdb'/>
<id>urn:sha1:b6fd7b96366769651ab23988607ce9c5c9042cdb</id>
<content type='text'>
The 1588 standard defines one step operation for both Sync and
PDelay_Resp messages.  Up until now, hardware with P2P one step has
been rare, and kernel support was lacking.  This patch adds support of
the mode in anticipation of new hardware developments.

Signed-off-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Use __kernel_clockid_t in uapi net_stamp.h</title>
<updated>2018-12-18T23:59:29+00:00</updated>
<author>
<name>Davide Caratti</name>
<email>dcaratti@redhat.com</email>
</author>
<published>2018-12-17T10:26:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e2c4cf7f98a519eb4d95532bfa06bcaf3562fed5'/>
<id>urn:sha1:e2c4cf7f98a519eb4d95532bfa06bcaf3562fed5</id>
<content type='text'>
Herton reports the following error when building a userspace program that
includes net_stamp.h:

 In file included from foo.c:2:
 /usr/include/linux/net_tstamp.h:158:2: error: unknown type name
 ‘clockid_t’
   clockid_t clockid; /* reference clockid */
   ^~~~~~~~~

Fix it by using __kernel_clockid_t in place of clockid_t.

Fixes: 80b14dee2bea ("net: Add a new socket option for a future transmit time.")
Cc: Timothy Redaelli &lt;tredaelli@redhat.com&gt;
Reported-by: Herton R. Krzesinski &lt;herton@redhat.com&gt;
Signed-off-by: Davide Caratti &lt;dcaratti@redhat.com&gt;
Tested-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Use __u32 in uapi net_stamp.h</title>
<updated>2018-07-09T23:31:28+00:00</updated>
<author>
<name>Jesus Sanchez-Palencia</name>
<email>jesus.sanchez-palencia@intel.com</email>
</author>
<published>2018-07-09T23:20:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=52b509218f0ab5946f9cbaf5501d88f69333f0e3'/>
<id>urn:sha1:52b509218f0ab5946f9cbaf5501d88f69333f0e3</id>
<content type='text'>
We are not supposed to use u32 in uapi, so change the flags member of
struct sock_txtime from u32 to __u32 instead.

Fixes: 80b14dee2bea ("net: Add a new socket option for a future transmit time")
Reported-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Jesus Sanchez-Palencia &lt;jesus.sanchez-palencia@intel.com&gt;
Reviewed-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net/sched: Make etf report drops on error_queue</title>
<updated>2018-07-04T13:30:28+00:00</updated>
<author>
<name>Jesus Sanchez-Palencia</name>
<email>jesus.sanchez-palencia@intel.com</email>
</author>
<published>2018-07-03T22:43:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4b15c7075352668d4467ced7594b676707d11cae'/>
<id>urn:sha1:4b15c7075352668d4467ced7594b676707d11cae</id>
<content type='text'>
Use the socket error queue for reporting dropped packets if the
socket has enabled that feature through the SO_TXTIME API.

Packets are dropped either on enqueue() if they aren't accepted by the
qdisc or on dequeue() if the system misses their deadline. Those are
reported as different errors so applications can react accordingly.

Userspace can retrieve the errors through the socket error queue and the
corresponding cmsg interfaces. A struct sock_extended_err* is used for
returning the error data, and the packet's timestamp can be retrieved by
adding both ee_data and ee_info fields as e.g.:

    ((__u64) serr-&gt;ee_data &lt;&lt; 32) + serr-&gt;ee_info

This feature is disabled by default and must be explicitly enabled by
applications. Enabling it can bring some overhead for the Tx cycles
of the application.

Signed-off-by: Jesus Sanchez-Palencia &lt;jesus.sanchez-palencia@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
