On Thu, May 18, 2017 at 10:07 AM, Miroslav Lichvar wrote:
> Add SOF_TIMESTAMPING_OPT_PKTINFO option to request a new control message
> for incoming packets with hardware timestamps. It contains the index of
> the real interface which received the packet and the length of the
> packet at layer 2.
>
> The index is useful with bonding, bridges and other interfaces, where
> IP_PKTINFO doesn't allow applications to determine which PHC made the
> timestamp. With the L2 length (and link speed) it is possible to
> transpose preamble timestamps to trailer timestamps, which are used in
> the NTP protocol.
>
> While this information could be provided by two new socket options
> independently from timestamping, it doesn't look like they would be very
> useful. With this option any performance impact is limited to hardware
> timestamping.
>
> Use dev_get_by_napi_id() to get the device and its index. On kernels
> with disabled CONFIG_NET_RX_BUSY_POLL or drivers not using NAPI, a zero
> index will be returned in the control message.
>
> CC: Richard Cochran
> CC: Willem de Bruijn
> Signed-off-by: Miroslav Lichvar
Acked-by: Willem de Bruijn
> +SOF_TIMESTAMPING_OPT_PKTINFO:
> +
> + Enable the SCM_TIMESTAMPING_PKTINFO control message for incoming
> + packets with hardware timestamps. The message contains struct
> + scm_ts_pktinfo, which supplies the index of the real interface which
> + received the packet and its length at layer 2. A valid (non-zero)
> + interface index will be returned only if CONFIG_NET_RX_BUSY_POLL is
> + enabled and the driver is using NAPI.
It is probably good to explicitly call out that the remaining two fields
are reserved and undefined. To stress that applications cannot be
overly pedantic and start failing if these become non-zero.
