Re: [PATCH 1/1] tidbits: net-udp: solicit new client for server mode

[Philippe Gerum <rpm@xenomai.org>]

Hannes Diethelm <hannes.diethelm@gmail.com> writes:

> Am 20.06.26 um 19:28 schrieb Philippe Gerum:
>> - Honor MSG_PROBE for oob_sendmsg(), so that only the general call
>>    sanity and route resolution to the destination host is performed when
>>    set in the request flags, without actually sending any data. On
>>    success of such call, we would know that the routing information is
>>    readily available from the oob caches, no offload to in-band would
>>    have happened if we had not given this flag. The absence of routing
>>    information to the destination from some oob cache would yield a
>>    specific error, so that the caller may decide what to do next.
>
> It seams the flag MSG_PROBE is kernel only? I did not find any occurrence
> in /usr/include or in libevl.
>

Yep, my bad. Using MSG_PROBE is not the right way, since that would
conflict with MSG_PROXY in userland which has a totally different
meaning. I have revisited the implementation, simplifying it actually:
since the evl netstack already accepts zero-sized messages, sending such
a datagram to the UDP layer now amounts to returning early with the
address resolution status, short-circuiting the logic before the actual
transmission happens.

IOW, passing a NULL or empty iov into the msghdr struct does what
MSG_PROBE was intended to do.

>> - Extend the effect of receiving MSG_DONTWAIT (and more generally
>>    O_NONBLOCK on fildes) to what we would do upon missing routing
>>    information: if present, return with a specific error code _without_
>>    relaying the packet to the in-band stack. The caller may then decide
>>    to handle the case locally. Otherwise, proceed as usual (i.e. relay to
>>    the in-band stack, then notify the caller with -EINPROGRESS).
>
> So the oob-net-udp server code can be changed to use MSG_DONTWAIT and
> if the return value is EWOULDBLOCK, call evl_net_solicit() and try again instead
> of holding a list of IP's right?
>

Yep.

>> - Provide a way to synchronize with the route resolution process in
>> evl,
>>    i.e. a syscall that would block until a given destination is available
>>    from the oob cache. This call already exists, evl_net_solicit() can be
>>    used for that purpose (if a resolution request is already in flight,
>>    subsequent ones to the same destination won't cause any harm).
>> Points 1 and 2 are implemented in [1]. Feedback greatly appreciated
>> and
>> important when you have time. Usability for real-world applications is
>> key.
>
> I am a bit busy right now, but I would like to test it. However, It can
> take a week or two.
>

Np. Your contribution has been valuable, so it's worth waiting for it.

>> 
>>> It would also be nice to have an "evl net" command to list the
>>> entry's. I tried the normal arp command but it doesn't behave nicely
>>> with evl.
>> Could you please elaborate on this issue? Currently, updates to the
>> in-band cache are propagated to the oob cache (by registering a hook
>> into the relevant notifier chain in the kernel). So I would expect all
>> destinations of interest to oob which are visible from the in-band arp
>> cache to be available from the evl map as well.
>> 
>
> The issue was on my side, I need to run "arp -n" so it does not resolve host
> names. Otherwise, it takes quite some time. But this makes sense, with OOB
> active, it will never receive the answer on the request, so it times out.
>

Ok, this is not user-friendly. I'll have a look.

> By the way: Since some time, all incoming network traffic goes to the OOB
> stage when it is enabled. However, all outgoing traffic from the in-band stage
> is still sent. Would it make sense to block all outgoing traffic after
> "evl net -ei" except might be ARP requests if they are initialized by evl_net_solicit()?
>

I believe this may break some use cases I'm aware of. Some people do
currently use such asymmetry between ingress-oob and egress-inband on
the same interface on purpose.

> At the moment, this is done using nftables for linuxcnc, this works fine
> for preemt_rt and xenomai, so not really needed.
>

Currently, it is assumed that any outgoing inband traffic has a purpose,
even on an oob-enabled interface. What kind of egress inband traffic
could/should be dropped safely when flowing through an oob interface?

>> This said, I agree that we need a way to inspect the oob cache
>> specifically. Working on it.
>> [1]
>> https://gitlab.com/Xenomai/xenomai4/linux-evl/-/tree/wip/net-solicit?ref_type=heads
>> 

-- 
Philippe.