zsock_select() timeout value implementation

[bob2oneil]

I would like to use the equivalent of the Linux select() statement, which I prefer over the poll() multiplexed i/o in part because of the timeout value being specified in microseconds, whereas poll() is in milliseconds. So I would prefer the higher precision in timing so I can use the timeout to yield but have high precision towards timing based events.

Looking through the source code for zsock_select(), it appears that underneath the covers it actually uses zsock_poll() in the source file sockets_select.c, and as a result, it simply converts the microsecond precision timeval into milliseconds.

Do I have this understanding correct in terms of zsock_select actual implementation? Is they any other form of single thread multiplexed i/o based on BSD sockets that might provide higher timer fidelity?

Assuming my observation is correct, does anyone have an opinion on why the poll() implementation is considered superior?

Here is the relevant code from this source file.

        poll_timeout = -1;
	if (timeout != NULL) {
		poll_timeout = timeout->tv_sec * 1000
			       + timeout->tv_usec / 1000;
	}

	res = zsock_poll(pfds, num_pfds, poll_timeout);
	if (res == -1) {
		return -1;
	}

[jukkar]

Indeed, select() is using poll() atm. After looking the code, I think it is trivial to change the code to internally use higher precision in poll implementation and just convert to desired precision in select/poll when calling the internal poll implementation. Patches are welcome if you want to go this route.
We also support SO_RCVTIMEO that allows application to define the receive timeout in microsecond resolution.

[jukkar]

Is it reasonable to think I could create a replacement for the zsock_select() that uses the logic you suggest here,

I would just suggest that you send a PR that proposes this change. The changes look quite simple and they make sense so that select() could be made to work with microsecond resolution. We can then review and tune the PR if there is need to do that.

[bob2oneil]

Thanks Jukka, just issued a Pull Request, will see how it goes. Is there an expectation that I will provide the changes, or is this just a wish list?

[jukkar]

just issued a Pull Request, will see how it goes. Is there an expectation that I will provide the changes, or is this just a wish list?

A pull request should contain the changes you are proposing, I am not seeing any from you in https://github.com/zephyrproject-rtos/zephyr/pulls
Ah, it was this one #36145

[bob2oneil]

My bad, I did not fully understand using the PR as the request mechanism vs submitted changed code. I understood that there was a chance of changed code, but that it might be something one of the reviewers picked up. I can give it a chance myself, but lacking your domain knowledge, I may not do as good a job. I also perhaps did not appreciate perhaps how much this is a community development with community submittals. Thanks for continuing my education into all things Zephyr, as newbie, I am just finding my way.

Can you give this one a look? Looking through the net_if code for a promiscuous socket, there is packet cloning and it would seem that maybe that is not compatible with a different raw socket. I need support (meaning stack has to ARP respond) for 257 IP addresses with a UDP only unicast primary IP 192.168.0.1, and then for the 200.168.0.0/24 network more like a raw socket where I need the IP/UDP/TCP header intact, but I can probably recreate the 12 byte Ethernet prior to sending to the destination.

It is not clear to me how I combine the kernel-based net_if stuff with 2 bridge sockets.

I am sure you know the answer.

And once I have the answer, I will likely not need additional Zephyr support for a bit as the squeeking wheel will have its grease.

#36151

[jukkar]

Lets not mix the things in #36151 to this smallish change for select timeout value, those are quite orthogonal. I try to find out some time to implement the change to select() so we get this one forward.

[jukkar]

I have a fix proposal at #36220

[jukkar]

Actually this is not a discussion but a real issue, unfortunately I do not see a way to convert to an issue.

[bob2oneil]

Thanks Jukka for spearheading this.

[pfalcon]

In my review comment #36220 (review) , I explain why select() in Zephyr was implemented the way it is, and those were deliberate requirements. Theoretical higher resolution of select() is just that - theoretical benefit, which in practice would only lead to confusion - 1 microsecond passed to select() would likely get rounded up to much higher value (if not on the order of milliseconds, then tenth of milliseconds).

As I mention there, if not thinking in terms of synthetic resolutions, but in algorithmic complexity/conversion overheads, the only way forward is to implement epoll(), but that takes timeout in milliseconds either.

There're a lot of materials on the topic by just googling "select vs poll", here's random google hit: https://devarea.com/linux-io-multiplexing-select-vs-poll-vs-epoll/ and quote:

Unlike select(), with its inefficient three bitmask-based sets of file descriptors ...

[bob2oneil]

Some good information. But borrowing from my experience with embedded Linux, using select() as a timeout mechanism, I was able to get microsecond precision timing (give or take a few hundred microseconds) based on the timeout value provided. But that was embedded Linux, and this is perhaps a different animal.

[bob2oneil]

Thanks Jukka, for spending the time and getting this into the main branch. It would not have happened without you handling the logistics and leveraging both you knowledge of the Zephyr network stack as well as the primary contributors to the project necessary for reviewing the effort and getting it into the main repo.