BSD Sockets API: Offloading support

[zephyrbot]

Reported by Paul Sokolovsky:

Users of devices which provide socket and TCP/IP offload engines would benefit in memory and power efficiency by enabling full offload of the Zephyr BSD socket APIs to a dedicated co-processor.

The TI CC3220SF SoC, part of the CC32XX SimpleLink SoC family of WiFi enabled devices, will be used as the initial socket offload implementation.

(Imported from Jira ZEP-2271)

[zephyrbot]

by Paul Sokolovsky:

Gil: We missed to have this explicitly captured, d'oh. This is yours otherwise, please edit as needed and set priority/fix version. Thanks.

[zephyrbot]

by Gilbert Pitney:

The Zephyr IP stack designers placed a CONFIG_NET_OFFLOAD option in Zephyr, with the intention of supporting IP offload devices.

See slide 7 in this slideset:
https://www.slideshare.net/linaroorg/bud17112-porting-the-ti-simplelink-cc32xx-wifi-stack-to-the-zephyr-iot-os

However, since then, there has been progress on adding a BSD socket layer to Zephyr. See: https://jira.zephyrproject.org/browse/ZEP-1921

The "plan of record" was to offload via the CONFIG_NET_OFFLOAD option, but that would incur overhead mapping BSD socket APIs to Zephyr net_context APIs and then to the engine's offload socket APIs.

To enable full offload, code space and energy savings entitlement to the network co-processor, the best solution would be to offload directly from the BSD API socket layer, similar to what is done in MyNewt. See: https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h

The disadvantage is that would bypass any future IP routing logic in Zephyr (but not a big issue for IoT client nodes only connected via WiFi). The advantage will be in code and network data buffer savings (those will be offloaded to the co-processor) and power savings (the MCU can be powered down while the co-processor is maintaining open TCP sessions).

[zephyrbot]

by Mark Linkmeyer:

Hi Gilbert Pitney , what's the status of this? Is it to be done in time for 1.9? Thx.

[zephyrbot]

by Gilbert Pitney:

I think this will need to be pushed to 1.10, for a few reasons:

• It's not complete ;-)
• The framework is based on a PR (#789) which has yet to be merged;
• This is somewhat related to the "NET_OFFLOAD" feature, which I see from a Zephyr roadmap slide has also been pushed to 1.10;

So, I think it's logical to move to 1.10.

[zephyrbot]

by Gilbert Pitney:

updated to 1.10, and placed In Progress.

[laperie]

as most of you are aware we are actively working to address sockets API compatibility on the stack design level. It'll happen earliest in 1.12

[laperie]

Removing 1.12 version assignment: This specific issue is more a discussion than a concrete action item. We will set a milestone after we agree on design and dependencies