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

[Hannes Diethelm <hannes.diethelm@gmail.com>]

Am 21.07.26 um 22:15 schrieb Philippe Gerum:
> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
> 
>> Am 20.07.26 um 16:27 schrieb Philippe Gerum:
>>
>> An option would be either to support of oob_ioctl() for SIOCGARP. Or create something like
>> evl_net_routeinfo(s, addr) returning flags would make probing obsolete.
>>
> 
> Not entirely. The issue with solely having SIOCGARP or any probe-only
> explicit request is that you would have to pair two syscalls at each
> transmit at least, one to probe for the sender address before possibly
> soliciting that peer if absent from the oob cache, another one for
> sending the message eventually. i.e., for every packet:
> 
>      ioctl(SIOCGARP)
>           !ATF_COM? -> evl_net_solicit()
>      oob_sendmsg(..., 0)

You are right, that is an unneeded syscall as long as you don't keep a
list of clients as before. This can remove the need from calling
evl_net_solicit() in the case the client is already in ARP and permanent but
this will be the only change and won't help that much.

> 
> OTOH, with the latest attempt to address this issue, we can send a
> probe-only request by passing MSG_PROBE (EHOSTUNREACH), or a request
> that does not attempt to defer transmit to the inband stage on probe
> failure by passing MSG_DONTWAIT (EWOULDBLOCK). i.e., for every packet
> 
> redo:
>      oob_sendmsg(..., MSG_DONTWAIT)
>           EWOULDBLOCK?
>                 oob_sendmsg(..., MSG_PROBE)
>                    EHOSTUNREACH?
>                        evl_net_solicit()
>                        goto redo
>                    otherwise assume ENOMEM
>           otherwise all done
> 
> IOW, using a proper combination of MSG_DONTWAIT and MSG_PROBE in the
> right sequence would either succeed to send the packet immediately on
> the first oob_sendmsg() call, otherwise fail on memory shortage or
> missing route from the oob cache. In the latter case, which could only
> happen once for each new peer under normal circumstances, we could
> disambiguate the EWOULDBLOCK status using an explicit probe.
> 
> A better way to do this in a single step unambiguously would require the
> addition of another operation flag, like MSG_DONTDEFER, preventing the
> deferral to inband on failed probe and causing oob_sendmsg() to return
> with a specific error code. e.g. something as simple as the following
> would cover all requirements:
> 
>       oob_sendmsg(..., MSG_DONTDEFER) -> EADDRNOTAVAIL on failed probe.
> 
> Now, we might also piggyback off of MSG_OOB instead of defining yet
> another operation flag, as a way to say "oob only, don't relay to
> inband", but I'm still pondering whether this would be nicely witty or
> utterly confusing..
> 

Yes, this is a variant. I was not aware that MSG_DONTWAIT -> EWOULDBLOCK
can also mean ENOMEM.

Now after considering all options, i start to prefer the variant before
this patch, keeping a list of already solicit'ed clients. It is straight
forward, simple and fast. And you know exactly when to expect an in band
call. Might be we should just drop this patch instead of adding unnecessary
complexity for example code?

With MSG_DONTWAIT/MSG_PROBE you are not sure if the ARP entry is permanent.
That means if you are unlucky, a few packages are sent to the client before
EHOSTUNREACH is returned which could be bad for real time.
If you have a real time server and clients, I imagine clients would expect
the first response to be delayed due to initialization / ARP but every following
response to be in time.

With ioctl(SIOCGARP) or evl_net_routeinfo(), a list of checked client's would
also be needed due to it would be wasteful to call the kernel each time before
sending a package.

MSG_DONTWAIT / MSG_PROBE could still be useful in certain applications, for example
when you have a separate thread that handles evl_net_solicit(), so you can
just call oob_sendmsg() until it succeeds without needing to signal back.

This would be something like this:

server_thread:
     if(!is_in_list(addr))
         write_solicit_queue(addr)
         add_to_list(addr)
     oob_sendmsg(..., MSG_DONTWAIT)
          EWOULDBLOCK?
                oob_sendmsg(..., MSG_PROBE)
                   EHOSTUNREACH?
                       skip or mark for retry depending on the application
                   otherwise assume ENOMEM -> generate error
          otherwise all done

solicit_thread:
     while(true)
	addr=read_solicit_queue()
	evl_net_solicit(addr)

I also prefer using an explicit MSG_PROBE instead of an implicit zero size
message.

For ioctl(SIOCGARP) or evl_net_routeinfo(), I don't see a good use-case after
all. You can just use evl_net_solicit(), it probably won't hurt if you do it once to
much and you have to implement the case when evl_net_solicit() is needed anyway
and take the timing for this into account.