net: sockets: support poll offloading

[AndreyDodonov-EH]

Problem
Currently socket_op_vtable and socket_dispatcher do not include poll function.

It limits exposing the functionailty of offloaded sockets and limits their use-cases.

Desired solution
poll function is included into socket_op_vtable and socket_dispatcher, so that offloaded implementations can implement poll.

[rlubos]

poll() offloading is already supported - it is handled at the ioctl() level - when ZFD_IOCTL_POLL_PREPARE is called, the socket may return -EXDEV which instructs the poll() implementation to switch to the offloaded version by consecutive ioctl() call with ZFD_IOCTL_POLL_OFFLOAD, for example:

zephyr/drivers/wifi/simplelink/simplelink_sockets.c

Lines 1178 to 1199 in 3934461

	static int simplelink_ioctl(void *obj, unsigned int request, va_list args)
	{
	int sd = OBJ_TO_SD(obj);
	switch (request) {
	case ZFD_IOCTL_POLL_PREPARE:
	return -EXDEV;
	case ZFD_IOCTL_POLL_UPDATE:
	return -EOPNOTSUPP;
	case ZFD_IOCTL_POLL_OFFLOAD: {
	struct zsock_pollfd *fds;
	int nfds;
	int timeout;
	fds = va_arg(args, struct zsock_pollfd *);
	nfds = va_arg(args, int);
	timeout = va_arg(args, int);
	return simplelink_poll(fds, nfds, timeout);
	}

Hoever this approach is quite limited actually, as it does not allow to mix offloaded and non-offloaded sockets in the same poll() call. It's better if the offloaded implementation have a proper support ZFD_IOCTL_POLL_PREPARE/ZFD_IOCTL_POLL_UPDATE.

[AndreyDodonov-EH]

@rlubos Thanks for a quick reply!
That's already more than I hoped for, however yes - ability to poll several hetergeneous sockets would be cool.

My endgoal is exposing webserver over multiple heterogeneous sockets (one normal tcp and one offloaded one), and for that poll support is needed.

[rlubos]

Not sure if we have example of this in the Zephyr tree but that's certainly doable right now, we do this with nRF9x offloaded sockets:
https://github.com/nrfconnect/sdk-nrf/blob/dc1ee19bab261a87887e4c2399e112496b51cf31/lib/nrf_modem_lib/nrf9x_sockets.c#L945

I guess the issue can be closed then?

[AndreyDodonov-EH]

But you had said that it's not supported, or did you mean something else above?

Hoever this approach is quite limited actually, as it does not allow to mix offloaded and non-offloaded sockets in the same poll() call.

Meanwhile, I'll explore the NRF code, thanks for the link.

[rlubos]

But you had said that it's not supported, or did you mean something else above?

I was referring to the approach with ZFD_IOCTL_POLL_OFFLOAD, and there is nothing to improve here actually. If the entire poll() call is delegated to offloaded implementation, it's hard to expect it'd work fine with for example native Zephyr sockets. In the second part of my answer I've indicated a better alternative which allows combine native and offloaded sockets in poll:

It's better if the offloaded implementation have a proper support ZFD_IOCTL_POLL_PREPARE/ZFD_IOCTL_POLL_UPDATE.

So if the offloaded socket implementation implements ZFD_IOCTL_POLL_PREPARE and ZFD_IOCTL_POLL_UPDATE (as in the nRF example above) and provides a kernel object to monitor, then the offloaded socket can be monitored by the native poll() implementation just like any other socket type.

[AndreyDodonov-EH]

@rlubos Thanks a lot!
It definitely answers my question.
I think the issue can be closed.

As a follow up, would it be okay if I submit a PR introducing a callback from webserver, which would allow a custom socket creation, if provided?
There based on e.g. svc->details user would be able to do any custom logic, set another proto, do any other customization (in my case zsock_setsockopt(...SO_BINDTODEVICE...)

Also, I think it would make sense to prepare a PR with a sample which coveres the mechanism from nrf sockets which you described.

[rlubos]

As a follow up, would it be okay if I submit a PR introducing a callback from webserver, which would allow a custom socket creation, if provided?
There based on e.g. svc->details user would be able to do any custom logic, set another proto, do any other customization (in my case zsock_setsockopt(...SO_BINDTODEVICE...)

I just wonder, is a callback really needed here, binding to a specific network interface seems like a generic feature, we could allow to optionally provide the interface name to the service (probably with the aforementioned detail field) and let the server code do the binding. If that doesn't work though, I think callback would also be fine, we do something like this in LwM2M for instance.

[rlubos]

I recalled vaguely there's been some discussions (controversy?) about using the detail field for server-speicifc configurations (#83811 (comment)) so perhaps we should introduce a separate config field in the service, not sure here.

[jukkar]

You can specify the IP address to bind in HTTP_SERVICE_DEFINE to bind to some specific interface, so that can be used as a workaround here. But that is only available in build time, so it does not really help if the address needs to be set in runtime.

[AndreyDodonov-EH]

@jukkar Good point. But it's not just about IP address.
It's about socket creation, too.

E.g. my current local dirty change in the webserver to make it work looks something like (in http_server_core.c in http_server_init):

if (svc->detail == 42) {
	fd = zsock_socket(AF_UNSPEC, SOCK_STREAM, 0);

	struct ifreq ifr = {0};
	strncpy(ifr.ifr_name, "ser0", sizeof(ifr.ifr_name) - 1);
	if (zsock_setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, &ifr, sizeof(ifr)) < 0) {
		LOG_ERR("SO_BINDTODEVICE %s failed: %d", "ser0", errno);
		zsock_close(fd);
		return -errno;
	}
} else {
	fd = zsock_socket(af, SOCK_STREAM, proto);
}

So I wanted to provide a callback which would allow to do anything of this kind when creating a socket.