Feature request: offloading capability of the W5500 driver.

[flabou]

Hello, I realize, this is probably a significant feature request as it would need pretty big modification of the W5500 driver.

Is your enhancement proposal related to a problem? Please describe. The current implementation of the W5500 driver does not seem to support offloading of the sockets (possibly also other network offloading features), even though the chip contains 8 hardware sockets, and implements the TCP/IP stack. The problem is that the ethernet stack of zephyr consumes a decent chunk of ROM and RAM, which could potentially be reduced if it was offloaded to this chip.

Describe the solution you'd like Implement the socket (and IP? and NET IF?) offloading capability in the W5500 driver, so that the CONFIG_NET_OFFLOAD, CONFIG_NET_SOCKETS_OFFLOAD, and CONFIG_NET_DEFAULT_IF_OFFLOAD work.

[TerryGeng]

This might not be straightforward. Wiznet W5500's Ethernet offload library made it very clear in https://github.com/Wiznet/ioLibrary_Driver/blob/b981401e7f3d07015619adf44c13998e13e777f9/Ethernet/socket.h#L69 that bind() and accept() don't exist.

If I understand correctly, in the Wiznet world, once a connection is made to a port in the listening state, it is automatically accepted, using the listening socket. This is completely different from the POSIX behavior that one has to accept that connection, then accept return a new socket to communicate while the old socket is still listening there.

There is also no bind(), since each Wiznet socket itself is associated with a port number when it is created with Wiznet's socket function.

One possible implementation I can think of is:

• The file descriptor and the actual Wiznet socket number need to be de-associated. There has to be a table keeping the internal mapping between the fd's and the actual Wiznet socket.
• When a socket is created by Zephyr's socket(), allocate an fd only without invoking anything from Wiznet.
• Only when connect() or bind() is called do we actually call the Wiznet API and allocate a Wiznet socket.
• When accept() is called on an fd, say fd F1, check the state of that Wiznet socket, say socket S1, (similar to https://github.com/Wiznet/ioLibrary_Driver/blob/b981401e7f3d07015619adf44c13998e13e777f9/Internet/httpServer/httpServer.c#L135). If the state is SOCK_ESTABLISHED, then allocate a new fd F2, associate this socket S1 to F2, while creating a new Wiznet socket S2, associate it to the original F1.

Does it sound good to experts here? If it does, I might give it a try.

[TerryGeng]

I have spent my weekend and Monday trying to set things up and now I have some progress to report.

So far, I have been able to port the socket functions from Wiznet's official codebase, including connect, send, recv, etc. They have been checked by my limited initial testing. I have to build a larger test set but I think I'm in the position to move forward to actually interfacing the Wiznet functions to Zephyr's socket offload interface.

In fact, as I was working on it, I had to refactor the eth_w5500.c (https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/ethernet/eth_w5500.c) by quite a bit to accommodate the need to read and write registers of not just socket 0 (that's for MACRAW mode) but also for socket 1 to 7. I also need to figure out what the way is to structure it so that it suits both the MACRAW mode and the socket offload mode.

Depending on my progress, I might be able to open a draft PR before next week.