On 27.07.2022 19:16:27, Vincent Mailhol wrote:
> This series revolves around ethtool and timestamping. Its ultimate
> goal is that the timestamping implementation within socketCAN meets
> the specification of other network drivers in the kernel. This way,
> tcpdump or other tools derived from libpcap can be used to do
> timestamping on CAN devices.
>
> * Example on a device with hardware timestamp support *
>
> Before this series:
> | # tcpdump -j adapter_unsynced -i can0
> | tcpdump: WARNING: When trying to set timestamp type
> | 'adapter_unsynced' on can0: That type of time stamp is not supported
> | by that device
>
> After applying this series, the warning disappears and tcpdump can be
> used to get RX hardware timestamps.
>
>
> This series is articulated in three major parts.
>
> * Part 1: Add TX software timestamps and report the software
> timestamping capabilities through ethtool.
>
> All the drivers using can_put_echo_skb() already support TX software
> timestamps. However, the five drivers not using this function (namely
> can327, janz-ican3, slcan, vcan and vxcan) lack such support. Patch 1
> to 4 adds this support. Finally, patch 5 advertises the timesamping
> capabilities of all drivers which do not support hardware timestamps.
>
>
> * Part 2: add TX hardware timestapms
>
> This part is a single patch. In SocketCAN TX hardware is equal to the
> RX hardware timestamps of the corresponding loopback frame. Reuse the
> TX hardware timestamp to populate the RX hardware timestamp. While the
> need of this feature can be debatable, we implement it here so that
> generic timestamping tools which are agnostic of the specificity of
> SocketCAN can still obtain the value. For example, tcpdump expects for
> both TX and RX hardware timestamps to be supported in order to do:
> | # tcpdump -j adapter_unsynced -i canX
>
>
> * Part 3: report the hardware timestamping capabilities and implement
> the hardware timestamps ioctls.
>
> The kernel documentation specifies in [1] that, for the drivers which
> support hardware timestamping, SIOCSHWTSTAMP ioctl must be supported
> and that SIOCGHWTSTAMP ioctl should be supported. Currently, none of
> the CAN drivers do so. This is a gap.
>
> Furthermore, even if not specified, the tools based on libpcap
> (e.g. tcpdump) also expect ethtool_ops::get_ts_info to be implemented.
>
> This last part first adds some generic implementation of
> net_device_ops::ndo_eth_ioctl and ethtool_ops::get_ts_info which can
> be used by the drivers with hardware timestamping capabilities.
>
> It then uses those generic functions to add ioctl and reporting
> functionalities to the drivers with hardware timestamping support
> (namely: mcp251xfd, etas_es58x, kvaser_{pciefd,usb}, peak_{canfd,usb})
>
>
> [1] Kernel doc: Timestamping, section 3.1 "Hardware Timestamping
> Implementation: Device Drivers"
> Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers
>
>
> * Testing *
>
> I also developed a tool to test all the different timestamps. For
> those who would also like to test it, please have a look at:
> https://lore.kernel.org/linux-can/20220725134345.432367-1-mailhol.vincent@xxxxxxxxxx/T/
Applied to linux-can-next/master with fixed mscan driver.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
