On Sun. 26 juin 2022 à 18:10, Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote:
> 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.
Does the mcp251xfd use the host clock to do its hardware timestamp?
(Not sure how SPI hardware works and if they have their own quartz or
if they share it with the host system). If it is indeed the same clock
you can have even more precise statistics.
> > 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.
What I was thinking is that tools such as tcpdump are able to get TX
packets of ethernet interfaces even if not normally visible (because
contrary to CAN, there is no default loopback). I was wondering if the
same could be done with error queues, but as you can guess my research
did lead anywhere. I also guess there is no official support but then,
I am wondering how hard it would be to hack the error queues to expose
them to the privileged processes.
> > 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
Thanks!
I also see you did a quick cleanup.
Yours sincerely,
Vincent Mailhol
