net: latmon: latency monitor service and sample

[ldts]

Supports the EVL/Xenomai4 gpio benchmarking tool as described in the Xenomai Latmus documentation.

The sample code for the Latmon service uses the FRDM_K64F J2 socket as follows:

• PIN_20: tx pulse to SUT
• PIN_18: rx ack from SUT

The client code running on the SUT shall monitor the falling edge of PIN_20.

Example usage from the latmus client running Xenomai4:
$ latmus -I gpiochip2,23,falling-edge -O gpiochip2,21 ....

Running snapshot:

• Upper terminal: Zephyr Latmon sample
• Lower terminal: Xenomai4 Latmus execution

A sample histogram plot:

Running Sample:

[jukkar]

This sample uses networking APIs but does not seem to be a networking sample but testing gpio latency. Perhaps this should be located somewhere under samples/drivers/ instead?

[bjarki-andreasen]

I do not believe this qualifies as a sample. From what I see reading the code, its an application used to calculate the latency of GPIO propagation between two systems, using a timer. For testing embedded systems, latencies are usually measured using digital analyzers to isolate the device under test, to avoid the propagated delays this application is seemingly introducing.

Samples are meant to show how to use zephyr, focusing on a specific feature like RTIO. I do not think anyone seeing this code will learn anything new about zephyr.

Why not keep this application downstream with the project it is designed for? I do not see what the zephyr project gains from adding and maintaining this application.

[ldts]

I do not believe this qualifies as a sample. From what I see reading the code, its an application used to calculate the latency of GPIO propagation between two systems, using a timer. For testing embedded systems, latencies are usually measured using digital analyzers to isolate the device under test, to avoid the propagated delays this application is seemingly introducing.

Samples are meant to show how to use zephyr, focusing on a specific feature like RTIO. I do not think anyone seeing this code will learn anything new about zephyr.

Why not keep this application downstream with the project it is designed for? I do not see what the zephyr project gains from adding and maintaining this application.

As I tried to explain in the README.rst, this program is designed for real-time Linux systems, assisting in the evaluation of their interrupt latencies. The client code, latmus, runs on the system under test (SUT) and has been a part of the Xenomai project for over 20 years, spanning multiple iterations. However, since it can run with minimal modifications on various systems, the goal is to extract it into a standalone project or potentially integrate it into the Linux kernel tree - maybe under linux/tools. The ultimate objective is to develop an affordable, open-source, hardware-backed solution for measuring interrupt latency in a clear and reliable manner.

It also offers an objective method for comparing PREEMPT_RT with Xenomai: Benchmark Scenarios.

I understand your concern but I was hoping we could have a discussion about this. In my opinion, given its simplicity, the code serves as a real-world example of pinctrl, GPIO, and networking usage. Additionally, it contributes to the Linux community by supporting discussions on real-time performance data. If it would be helpful, I’d be happy to be added as a maintainer for this sample code.

[ldts]

@jukkar @bjarki-andreasen should I add it to samples/boards instead? It seems to focus more on demonstrating functionality and hardware features. I'd like to unblock this discussion

[bjarki-andreasen]

@jukkar @bjarki-andreasen should I add it to samples/boards instead? It seems to focus more on demonstrating functionality and hardware features. I'd like to unblock this discussion

Could you address the main alternative to adding this as a sample, which is to maintain it as a normal application within the project it is a part of? There are an effectively never ending number of applications built to run on zephyr, projects like https://github.com/jakkra/ZSWatch and https://github.com/zmkfirmware/zmk are rather popular ones. Should we add those applications to samples as well? One could argue they demonstrate how to use many parts of zephyr as well, but that does not make them samples...

In short, samples demo and document a feature, applications solve a problem. The code in this PR is part of a larger project, solving a problem.

[ldts]

@bjarki-andreasen I believe I have provided some sort of justification to what you are asking; I have provided links and data backing my request and offered my support as a maintainer.

You are pointing me to some neat repositories though quite frankly I fail to see their industry relevance beyond their own individuality - the problem they are trying to solve doesn't extend beyond their single use case. I also doubt they will be active in 20 years from now. I have pointed you to a project/framework that is a quarter of a century old and supporting many industrial applications (and companies).

The latmus tool - used to measure performance deviation - will help a wide range of products and markets. So with that in mind, I am still not sure why this Zephyr code can not be integrated as sample code. Is as generic as any, but it will help many.

Now, please, could you help me understand the criteria to merge code to sample/boards? what does an application need to do be be accepted there?

[jukkar]

I do not have big issues with this sample, we have other samples that do somewhat similar things like zperf in networking. If this PR is accepted, then I suggest it is not placed under samples/net as it is using networking APIs but is not demonstrating some specific networking feature (we have various BSD socket samples in net already which do that).

[bjarki-andreasen]

@bjarki-andreasen I believe I have provided some sort of justification to what you are asking; I have provided links and data backing my request and offered my support as a maintainer.

You are pointing me to some neat repositories though quite frankly I fail to see their industry relevance beyond their own individuality - the problem they are trying to solve doesn't extend beyond their single use case. I also doubt they will be active in 20 years from now. I have pointed you to a project/framework that is a quarter of a century old and supporting many industrial applications (and companies).

The latmus tool - used to measure performance deviation - will help a wide range of products and markets. So with that in mind, I am still not sure why this Zephyr code can not be integrated as sample code. Is as generic as any, but it will help many.

Yes, "some sort of justification" has been provided, I do not find said justification sufficient.

Now, please, could you help me understand the criteria to merge code to sample/boards? what does an application need to do be be accepted there?

samples/boards is for board specific samples, demoing board/vendor specific features like vendor specific device driver APIs. Its not relevant so I did not see a reason to expand upon it.

@jukkar Just like this sample does not demo any specific networking feature, its not demoing any specific zephyr feature either. Its not a sample... The "sample" in this PR is an endpoint/client for a completely independent project, it has no utility for zephyr.

@kartben What do you think? Is this a sample in your opinion? Should it be part of the zephyr codebase somewhere in any case?

[ldts]

samples/boards is for board specific samples, demoing board/vendor specific features like vendor specific device driver APIs. Its not relevant so I did not see a reason to expand upon it.

If we look into samples/boards/expressif/ethernet or the rpi_pico sample it does seem relevant to me (nothing of interest from the zephyr side, just hardware validation AFAICS). But you are clearly better informed - I stopped contributing zephyr code over 8 years ago so I cant say I am up to date.

Anyway, sure please let me know if I should drop the PR.

[bjarki-andreasen]

Have you considered contributing latmon as a network protocol, similar to how protocols like ptp are implemented? Then the sample could demo the usage of said protocol, which would be a zephyr feature :) The protocol being part of the sample is what I believe makes this an application, rather than demoing a zephyr feature.

something like:

typedef void (*net_latmon_ack_handler)(void);
int net_latmon_start(net_latmon_ack_handler ack_handler);
int net_latmon_send_data(const struct net_latmon_data *data);

in
include/zephyr/net/latmon.h
which could be included with a kconfig like config NET_LATMON.

The sample would then be a demo of how to use the protocol.

[ldts]

Have you considered contributing latmon as a network protocol, similar to how protocols like ptp are implemented? Then the sample could demo the usage of said protocol, which would be a zephyr feature :) The protocol being part of the sample is what I believe makes this an application, rather than demoing a zephyr feature.

something like:

typedef void (*net_latmon_ack_handler)(void);
int net_latmon_start(net_latmon_ack_handler ack_handler);
int net_latmon_send_data(const struct net_latmon_data *data);

in include/zephyr/net/latmon.h which could be included with a kconfig like config NET_LATMON.

The sample would then be a demo of how to use the protocol.

ah, that is a neat idea. ok let me have a look and thanks a lot for pointing it out!

[ldts]

keep alive.

[ldts]

@bjarki-andreasen I still have to address issues from the original code so please do not dive into a formal review yet - could you however comment on the partitioning as a network service? is this what you had in mind when you suggested it?

[bjarki-andreasen]

@bjarki-andreasen I still have to address issues from the original code so please do not dive into a formal review yet - could you however comment on the partitioning as a network service? is this what you had in mind when you suggested it?

Yes, this looks very much like what I envisioned :)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ldts]

AFAICS all actions have been done.

[bjarki-andreasen]

Nice work!

[bjarki-andreasen]

ping @kartben :)

[ldts]

@kartben ping

[ldts]

Maybe someone else can take over the missing reviewed by?

[kartben]

Sorry for the delay. I will make sure to come back to this within a couple days

[ldts]

Sorry for the delay. I will make sure to come back to this within a couple days

Cool thanks, yeah enough for me to know is being reviewed and moving along, didn't want it to stall.

[ldts]

@kartben when I accepted your recommendations, a Co-author tag was generated. Do these need to go into the two commits or shall I just add your Reviewed-by tags?

going to fold the commits and update the PR so please let me know

[kartben]

@kartben when I accepted your recommendations, a Co-author tag was generated. Do these need to go into the two commits or shall I just add your Reviewed-by tags?

going to fold the commits and update the PR so please let me know

Oh I didn't know it does that. No tag at all is fine as far as I'm concerned :) thanks for checking!

[ldts]

@kartben any other changes?

[ldts]

@bjarki-andreasen ping?

[ldts]

sorry @bjarki-andreasen I had to remove a section of the documents (I hadnt noticed @kartben last request). I hope this is all :)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud