On 26.06.2022 16:53:17, Vincent Mailhol wrote:
> This is a simple tool I wrote in the past. It will report the time
> need for a packet to travel from:
> * application TX path to kernel TX path
> * kernel TX path to kernel RX path (i.e. kernel round trip)
> * kernel RX path to application RX path
> * application TX path to application RX path (i.e application round
> trip)
I'm currently playing around with hardware timestmaps in the mcp251xfd
driver and the other day I stumbled over commit 741b91f1b0ea ("can: dev:
can_put_echo_skb(): add software tx timestamps") and I was thinking
which tool you're using to test this. :)
Once the hardware timestamps are running stable, this is exactly the
tool I need! Thanks for sharing this.
> This tool is useful to benchmark latency on software and hardware. It
> can be used to, for example:
> * compare performances of two CAN controllers (by using the kernel
> round trip information)
> * compare the different CAN queue disciplines (by using the
> application TX path to kernel TX path information)
>
> I am sharing it as-is. Please see this message as an FYI. I do not
> consider this mature enough and I am not expecting anyone to pick that
> patch. Everything is hard coded, I did not put effort to make it
> configurable.
>
> The tool requires the TX timestamps (which I previously added to the
> kernel in [1] and [2]).
>
> To use it:
> | $make
> | ./can-roundtrip-stats
>
> My ultimate goal was to add the TX timestamp feature to candump from
> can-utils [3], however, I faced a blocker: the TX timestamps are sent
> to the error queue of the sender's socket meaning that a listener
> (such as candump) will not see those TX timestamp on his error queue
> because this is a different socket as the sender. If anyone knows a
> method to access the error queue of another process's socket, let me
> know (I guess that you need to be root, but did not find how to do
> it).
I don't think there's an official way to read the TX timestamps (i.e.
error queue) of a socket that's outside of your process.
> Because I did not manage to add the feature to candump, I am sharing
> instead this standalone tool, hoping someone might find it useful.
I'm not sure which is the best tool to add this to...cangen,
cansequence. Maybe evolve these tools into some kind of CAN ping
command.
> At the moment, I am not planning to invest more time in the
> foreseeable future. If someone want to take over and make is a bit
> more sexy so that it can reach can-utils, go ahead. I think that it
> basically misses a command line interface in the same fashion of
> cangen to make is configurable.
I've added it to a branch of my can-utils:
https://github.com/marckleinebudde/can-utils/tree/can-roundtrip-stats
> Else, you can also tweak the hard coded information to easily adjust
> it to your needs.
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
