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: Mon, 01 Jun 2026 11:10:17 +0200	[thread overview]
Message-ID: <874ijm62yu.fsf@xenomai.org> (raw)
In-Reply-To: <87a4te64vn.fsf@xenomai.org> (Philippe Gerum's message of "Mon, 01 Jun 2026 10:29:00 +0200")

Philippe Gerum <rpm@xenomai.org> writes:

> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
>
>> This fixes random EINPROGRESS at init or during runtime.
>>
>> Also correct whitespaces and make stdout more consistent.
>>
>> Signed-off-by: Hannes Diethelm <hannes.diethelm@gmail.com>
>> ---
>>  tidbits/oob-net-udp.c | 58 +++++++++++++++++++++++++++++++++++++------
>>  1 file changed, 50 insertions(+), 8 deletions(-)
>>
>> diff --git a/tidbits/oob-net-udp.c b/tidbits/oob-net-udp.c
>> index 11b8459..7af834f 100644
>> --- a/tidbits/oob-net-udp.c
>> +++ b/tidbits/oob-net-udp.c
>> @@ -50,12 +50,12 @@ static void usage(void)
>>  }
>>  
>>  static void print_addr(char* text, struct sockaddr_in *addr){
>> -    char ip_str[INET_ADDRSTRLEN+1];
>> -    inet_ntop(AF_INET, &(addr->sin_addr), ip_str, sizeof(ip_str));
>> -    evl_printf("%s--------\n", text);
>> -    evl_printf("IP-Address: %s\n", ip_str);
>> -    evl_printf("Port:       %d\n", ntohs(addr->sin_port));
>> -    evl_printf("Family:     %d\n", addr->sin_family);
>> +	char ip_str[INET_ADDRSTRLEN+1];
>> +	inet_ntop(AF_INET, &(addr->sin_addr), ip_str, sizeof(ip_str));
>> +	evl_printf("== %s\n", text);
>> +	evl_printf("   ip-address: %s\n", ip_str);
>> +	evl_printf("   port:       %d\n", ntohs(addr->sin_port));
>> +	evl_printf("   family:     %d\n", addr->sin_family);
>>  }
>>  
>>  static void sender(int s, const char *text, int mcount,
>> @@ -226,6 +226,8 @@ static void client(int s, const char *text, int mcount,
>>  	free(tbuf);
>>  }
>>  
>> +#define SERVER_ADDR_LIST_SIZE 64
>> +
>>  static void server(int s, const char *text, int mcount,
>>  		struct sockaddr_in *addr, int iter)
>>  {
>> @@ -236,6 +238,9 @@ static void server(int s, const char *text, int mcount,
>>  	ssize_t ret;
>>  	char *tbuf;
>>  	char rbuf[16384];
>> +	in_addr_t addr_list[SERVER_ADDR_LIST_SIZE]={};
>                                                   ^ missing whitespaces
>> +	size_t addr_list_fill=0;
>> +	bool solicit_done;
>>  
>>  	tlen = (strlen(text) + 1) * mcount;
>>  	tbuf = malloc(tlen);
>> @@ -276,6 +281,39 @@ static void server(int s, const char *text, int mcount,
>>  			evl_printf(" (TRUNCATED)");
>>  		evl_printf(": %.*s\n", (int)ret, rbuf);
>>  
>> +		/*
>> +		 * We need to call evl_net_solicit for each new
>> +		 * client once before sending data. This will break
>> +		 * realtime for the first response.
>> +		 * If this is not done and the ARP address is not
>> +		 * yet in cache or garbage-collected, oob_sendmsg
>> +		 * will return EINPROGRESS on start or during runtime.
>> +		 */
>
> We can happily send redundant solicit requests to the core, no need to
> filter out cached addresses, evl_net_solicit() will do the right thing.
>

Except that doing so would always demote the caller to the in-band
stage, which may not be what you want. The fact that we'd need to
maintain a cache in apps in order to figure out whether solicitation
should be done shows a shortcoming in the core, users should not have to
do this dance.

We should have an oob call for probing the route+arp caches with
ipv4. I'll look into this asap.

-- 
Philippe.

  reply	other threads:[~2026-06-01  9:10 UTC|newest]

Thread overview: 8+ 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 [this message]
2026-06-01 20:02       ` Hannes Diethelm
2026-06-20 17:28         ` Philippe Gerum
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=874ijm62yu.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.