Mesa Hostmot2 Xenomai4 OOB networking support#4199
Conversation
|
BTW: I know, rootless xenomai is still todo. I will do that after #4132 is in. It will conflict otherwhise. |
|
@pcw-mesa What do you think aboat this PR? Do we want two drivers? hm2_eth.c and hm2_eth_net.c? Shouldnt be better implement OOB to hm2_eth.c? To @hdiethelm : I can help with testing 7i96s. |
This way, I can cleanly separate the two Ethernet implementations and not break the existing one by accident. Also hm2_eth.c is already quite big and I did not want to blow it up even more. But you are right, having one module and instead using for example rt_eth_type=evl,posix,..., similar to board_ip=ip[,ip…] would be an alternative and it would even allow to only use one xenomai capable network card if you have a second board that is not that important and connected to a non-xenomai capable NIC. I will look into it.
Thanks! I have also a 7i96s, this PR is already tested both with posix and evl networking. But a second test is always good to have, not all configs behave the same. |
This variant will be easier for switching "posix and evl". If you want evl to be used normally, you will need to add it to PNCconf. For most Mesa card users, installing a LinuxCNC distribution is the best they can do. |
|
ChatGPT is helping me with this PR. We have these questions: Before I start preparing the environment, I have a few questions:
|
|
You will find most information here: For PREEMPT_RT, i use Debian Trixie, stock preempt kernel. Intel I350 uses the igb driver. For e1000e, you need quite an old card. |
If this fails, everything beaks and there are a thon of error messages. So better abort here
Split into two network implementations, one for posix and one for evl. There are now two modules: hm2_eth and hm2_eth_evl.
hdiethelm
force-pushed
the
hm2_eth_oob_v5
branch
from
f2f5ab0 to
32b5122
Compare
|
So, I went back to having one component with two network backends:
Xenomai4 EVL mode: |
hdiethelm
force-pushed
the
hm2_eth_oob_v5
branch
from
32b5122 to
56d4a15
Compare
|
I'm currently stuck on getting the EVL kernel working: The "board_rtnet" parameter looks good. Do you think it would be possible to add: board_rtnet=evl - this configuration doesn't make sense when: board_rtnet=posix - does this configuration make sense when: The less the user has to configure, the better. |
I uploaded a non-rt variant and the matching config. See: hdiethelm/xenomai4-linuxcnc#1 Thanks for the good description.
However, I have to check if LinuxCNC is running in Xenomai4 mode when you configure |
I respect your opinion, but I think LinuxCNC should be friendly. Should be possible check if Linux is running in Xenomai4 mode and check network card supports OOB networking in PNCconf? For example pressbutton next checkbutton "EVL mode" I know it's too early to ask this. EVL needs to be tested first. But I'm interested. |
I believe if you invest the effort to get xenimai4 running, setting That said, if we discover that Xenimai4 really performs better than PREEMPT_RT for many users, then we can still invest some time in:
For now, it's mostly a toy project for me to learn Xenimai4. At least on my setup, it doesn't perform much better than PREEMPT_RT but this old PC anyway runs nearly perfect, max latency of 20us including Ethernet is absolutely unnecessary for a Mesa card but still fun... ;-) It will be nice to have a report from you if it works well on your setup. Never the less, having this part also merged to master makes it testable for many people. I will update the hm2_eth doc in this PR after testing, I don't like to change it many times based on feedback about the implementation. |
|
I think options like OS detection belong more in the configuration utilities or maybe startup scripts I am really curious what Ethernet performance is possible with Xenomai/OOB networking, as trying to get higher |
Agreed.
I have to check tomorrow, but as I remember, I have a loop time of 50us avg / 70us max. with a well tuned PC and an Intel I350. BTW: For a long time, the HAL time measurements where in cycles. This PR changed all to ns: #4082 |
|
Here are my first results: Latency with Preempt: Latency with EVL: I was interested mainly aboat Mesa tests: CPU test with Preempt: CPU test with EVL: NIC test with Preempt: NIC test with EVL: Copy terminal: This is wierd. Machine worked as usualy: I made this tests quickly. For big machine I am makeing 24 hour tests. |
|
Thanks already for testing. I will look into it in detail tomorrow. |
|
|
So, what I can tell so far:
Reason why all this effort above: mesa sends a package and waits for the response. Due to the waiting, it is way more efficient latency wise to run all including the ethernet task and interrupt on one core. Otherwise, the data has to be copied from one core to main memory and back to the other. At least in my setup, the jitter got reduced by a lot doing this. I use the eth-rt-affinity at startup in I wanted to create a doc and might be even a tool to do it from my tuning experience since some time but a few other projects went between... ;-) @pcw-mesa My timing info: All short term tests, a few minutes: |
|
@zz912 I don't like it that much but it seams that this is the only way I can run a long duration init function in the real time context. I have a chicken and egg problem:
|
|
I works wrong: 
|
Change back to one component that uses a "board_rtnet" argument to switch between the types
Requres: initf hm2_eth.realtime-init servo-thread in .hal file
3 participants
This PR adds Xenomai4 EVL out of band networking support for Mesa Hostmot2.
Out of band networking is basically a fast path inside the xenomai real time kernel that enables networking without involving the normal kernel.
Due to some users might want to use Xenomai4 with the standard kernel networking, I decided to create a new component calledhm2_eth_evlwhilehm2_ethbehaves exactly like before.Common code is left inhm2_eth.cand network specific code is moved tohm2_eth_net.candhm2_eth_net_evl.c.The linker is used to link
hm2_eth_evlandhm2_ethwith two different network implementations and the same common code.To select the mode, you can use:
board_rtnet=posixorboard_rtnet=evl, where the default is posix, so it is a non-breaking change.A few changes in the existing code where performed:
Things still open:
fetch_hwaddrtohm2_fetch_hwaddrfor example to avoid conflicts?Loadinghm2_eth_evlandhm2_ethat the same time would probably create a runtime linker issue which generates undefined behavior.It's a bit hard to review due to moved code.
git diff master:src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth_oob_v5:src/hal/drivers/mesa-hostmot2/hm2_eth_net_posix.chelps.