Only 1 NET_SOCKET_OFFLOAD driver can be used

[mike-scott]

Is your feature request related to a problem? Please describe.
Fix Zephyr to allow for several devices to be configured as NET_SOCKET_OFFLOAD.

Describe the solution you'd like
I haven't thought too much about the solution, but it would probably involve the offloaded drivers allocating file descriptors using vtables, so that packets can be routed between 2 different offloaded drivers appropriately.

Describe alternatives you've considered
No alternatives.

Additional context
If we allow for more than 1 device to use the socket offload feature, then we can open up more options for Zephyr devices such as Wifi NCP combined with a modem as a wireless gateway, etc.

[mike-scott]

@rlubos @GAnthony adding for discussion

[rlubos]

Yes, this has been sitting in my head for some time now and the idea was the same as you propose - to move the offloading underneath the z_sock_* API and use the vtable.

The two problems I see with this solution that would be needed to solve:

1. Socket creation - how to tell which offloaded engine should be used (or a native stack) when the socket is created. I assume all solutions would like to support standard socket families/types.
2. The offloaded socket implementations would need more sophisticated poll handling - the implementations I saw so far simply call poll/select underneath, which limits the use only to offloaded sockets.

[GAnthony]

@vanti, FYI.

Yes, having a single socket offload device was a design limitation (which satisfied most TI use cases).

The vtable work was pushed to ensure the existing socket offload got into the LTS release, (some discussion on that was here: #11891).

The two problems I see with this [vtable] solution that would be needed to solve:

1. Socket creation - how to tell which offloaded engine should be used (or a native stack) when the socket is created.

Indeed. Either:

• a specific Protocol Family in the socket create call, indicating the net interface.
• or maybe delay the actual (offloaded) socket creation until a setsockopt(..., SO_BINDTODEVICE, ...); is done (non-standard);
• or some integration with the IP routing table (but that's not available at the socket level?)

2. The offloaded socket implementations would need more sophisticated poll handling

Right. In the case of SimpleLink, the select() code runs on the the network coprocessor (NWP), so would have no way to unblock if another network interface's event occurred.
The NWP would need the ability to notify the host of socket events (accept, recv) . SimpleLink has a TriggerMode, which I expected to do that, but was unable to get it working in the multithreaded OS (Zephyr) case. Maybe other offload devices will have such a feature.

[pfalcon]

I'm glad there's some lively discussion here. Let me start with unassigning this from myself, as I don't think I can be a driver for this issue. Socket offloading was originally implemented by @GAnthony based on TI's usecase, so its maintenance might be inherited by @vanti. I'm happy to help in any way I can, but again, not drive it (unless assigned to that task by my team lead).

As pointed out by @rlubos and @GAnthony, the original idea was to plug offloading beneath sock vtable. (And started to forget about that, will all the Battles of POSIX that we had recently).

Describe alternatives you've considered
No alternatives.

Well, there's an alternative. And I humbly follow that alternative, it being: socket offloading is nothing but a temporary workaround, allowing to make a proof of concept port of Zephyr to some networking hardware in quick&dirty manner. However, for sustainable support, vendors should provide a way to integrate their hardware at most on L2 (i.e., packet) level, and let Zephyr networking stack to do the actual networking.

Because otherwise house-of-cardness of such a solution will always pop up, e.g.:

so that packets can be routed between 2 different offloaded drivers appropriately.

There're no packets on socket level, so no "packet routing" to be done. Any "offloaded sockets" will be disjoint, with only "routing" possible is on application and application protocol level.

[carlescufi]

@rlubos can this be closed now?

[rlubos]

@carlescufi I believe so, yes.