Re: [EVL] Client UDP not receiving data

Hannes Diethelm <[email protected]> writes:

>
> Thanks for the detailed answer. I might have been not precise enough.
>
> The -S and the -R mode work as designed. To show the issue with connect() in evl, I changed
> the -S mode to:
> connect()
> while{
>   oob_sendmsg()
>   oob_recvmsg()
> }
>
> This is the classical UDP client pattern. It works with vanilla linux (net-udp.c)
> but not with evl (oob-net-udp.c), I do not receive any data.
>
> By just sending the modified code, it is easy to explain and hopefully for you to
> reproduce. This is also why I attached the files instead of sending a patch.
> Be aware that this is just to demonstrate what is not working, not intended as a patch.
>
> I run Xenomai4 in a VM and communicate with the host for debugging
> but I have also a real PC as the final target where I have the same issues.
>
> First start on the host:
> echo Hello | nc -u -l 5201
>
> Then in the VM:
> sudo evl net -ei enp7s0
> sudo oob-net-udp -d -i enp7s0 -a 192.168.122.1 -p 5201 -S
>
> On the host:
> Mellow sword!
>
> In the VM:
> == bound to enp7s0
> == sender mode (=> 192.168.122.1:5201)
> --------tx--------
> IP-Adresse: 192.168.122.1
> Port:       5201
> Family:     512
> --------rx--------
> IP-Adresse: 192.168.122.155
> Port:       58422
> Family:     512
>
> The package is visible in wireshark but oob_recvmsg does not return:
> No "= 6 bytes received: Hello" and no second transmit.

Ok, I totally misinterpreted your previous post, sorry for
that. Brain received -ENOCOFFEE.

>
> It looks like the auto assigned and bound port from connect() is not forwarded
> to the oob stage, so no data is received in oob_recvmsg().
>

This is exactly the point, indeed. Could you please try this branch [1]?
The two commits on top improve the situation with your test code here.

>
> But might be evl was never intended to work using connect() in classical UDP client style?
>

IMO, the evl netstack (and evl in general) should follow the POLA
principle as closely as possible, and any UDP user can reasonably expect
auto-binding to be handled. So this needs fixing.

>
> If you think this this example is useful, I can finalize it (for now with the bind() workaround) and also add a server mode.
> So there would be 4 modes in total. With a server mode, you can run the server on one host, the client on the other and continuously
> send data forward / backward and measure delays. I would use:
> -T send (previously it was -S but then I have nothing for server)
> -R receive
> -S server: Waits for data and sends a response for each received package.
> -C client: Sends data and measures how long it takes for the server to response.
>
> As an alternative, I could just create a second example oob-net-udp-server-client.c. This would result in a bit of duplicated code but not to much.
>
> What do you prefer?

It is definitely useful. I would go for option #1, i.e. integrated
send/recv/server/client example. First because all the boilerplate and
ancillary support for parsing options and setting up connections is
already there and the code running the client scenario to be added is
likely small enough.

Next because the I'd rather have a 'client' mode measuring round-trip
times explicitly in the context of some example code, rather than
letting people think that we would actually provide a 'ping' command
that way. Reason is about performance: the standard in-band ICMP server
is operated from kernel context; although the latency would bite
compared to any oob-based server under high load, on average the figures
obtained on an idle system would be somewhat misleading compared to the
oob server in application space, because reinstating a userland context
for handling ICMP requests may be more time-consuming than handling it
directly as close as possible from the packet delivery point in kernel
space, i.e. without entailing any context switching to userland (even to
an oob thread).

>
> I also created oob-net-ping in the same style as oob-net-icmp but this sends out a ping, receives the response
> and measures the delay, similar as the ping command:
> ./oob-net-ping -i enp7s0 -a 192.168.122.1
> [0] count=98, proto=0x800, ifindex=3, type=0, halen=6, mac=52:54:00:6b:05:f1 rtt=317.1us
> [1] count=98, proto=0x800, ifindex=3, type=0, halen=6, mac=52:54:00:6b:05:f1 rtt=218.5us
> [2] count=98, proto=0x800, ifindex=3, type=0, halen=6, mac=52:54:00:6b:05:f1 rtt=252.5us
> [3] count=98, proto=0x800, ifindex=3, type=0, halen=6, mac=52:54:00:6b:05:f1 rtt=320.1us
> It has to be cleaned it up a bit and integrated it into the libevl repo but then I will also send a patch.
>

I think we need a simple agent somewhere in the evl netstack in kernel
space answering ICMP_ECHO requests flowing in oob channels directly,
just like the in-band stack does for in-band traffic. I can look into
this.

PS: thanks for the test code you provided, it saved a lot of time on my
end.

[1] https://gitlab.com/Xenomai/xenomai4/linux-evl/-/tree/next/v6.12.y-cip-evl-rebase?ref_type=heads

-- 
Philippe.