All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Hannes Diethelm <hannes.diethelm@gmail.com>
Cc: xenomai@lists.linux.dev
Subject: Re: [PATCH 1/1] tidbits: net-udp: solicit new client for server mode
Date: Tue, 21 Jul 2026 22:15:35 +0200	[thread overview]
Message-ID: <87jyqodrq0.fsf@xenomai.org> (raw)
In-Reply-To: <11409ae1-be7b-4003-8d40-f5e1cb34d2ec@gmail.com> (Hannes Diethelm's message of "Mon, 20 Jul 2026 22:03:52 +0200")

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)

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..

-- 
Philippe.

  parent reply	other threads:[~2026-07-21 20:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28 19:44 [PATCH 0/1] tidbits: net-udp: solicit new client for server mode Hannes Diethelm
2026-05-28 19:44 ` [PATCH 1/1] " Hannes Diethelm
2026-06-01  8:29   ` Philippe Gerum
2026-06-01  9:10     ` Philippe Gerum
2026-06-01 20:02       ` Hannes Diethelm
2026-06-20 17:28         ` Philippe Gerum
2026-06-27 20:21           ` Hannes Diethelm
2026-07-04 17:52             ` Philippe Gerum
2026-07-17 19:19               ` Hannes Diethelm
2026-07-20 14:27                 ` Philippe Gerum
2026-07-20 20:03                   ` Hannes Diethelm
2026-07-21  7:51                     ` Philippe Gerum
2026-07-21 16:48                       ` Philippe Gerum
2026-07-21 20:15                     ` Philippe Gerum [this message]
2026-07-21 22:36                       ` Hannes Diethelm
     [not found]                         ` <dc6c2532-08e4-417d-85dd-8d2e89b34ae7@gmail.com>
     [not found]                           ` <87h5lrh503.fsf@xenomai.org>
     [not found]                             ` <87tspqg9bu.fsf@xenomai.org>
2026-07-22 20:45                               ` Hannes Diethelm
2026-06-01 19:33     ` [PATCH v2] " Hannes Diethelm
2026-05-29  5:29 ` [PATCH 0/1] " Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87jyqodrq0.fsf@xenomai.org \
    --to=rpm@xenomai.org \
    --cc=hannes.diethelm@gmail.com \
    --cc=xenomai@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.