change: bump max sockets in lwip Kconfig (IDFGH-12906)

[rdgoprslv]

Addresses #3840

Tested under ESP32S3, running 50 tasks, each with a client, and a server listening to one client, totalizing 150 sockets/files open, forwarding data from PPP to Ethernet and vice versa.

Reasoning for 255 total sockets/files is VFS local_fd_t being a uint8_t.

Since FD_SETSIZE is defined at tool level, a CMakeLists user definition is needed in cases above 64 (the default value).

[CLAassistant]

All committers have signed the CLA.

[github-actions]

	Messages
📖	🎉 Good Job! All checks are passing!

👋 Hello rdgoprslv, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

This GitHub project is public mirror of our internal git repository

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved, we synchronize it into our internal git repository.
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the default branch.
5. On next sync from the internal git repository merged change will appear in this public GitHub repository.

Generated by 🚫 dangerJS against f78c567

[david-cermak]

Thanks for this PR, this is very helpful, including the description and note about FD_SETSIZE!

Could you please squash the commits into one?

[rdgoprslv]

Done.

[atanisoft]

I'll agree this is a cool PR, but how do we handle FD_SETSIZE? Is it possible to define this generically when socket count exceeds the declared limit (61) before requiring an override?

Also what about the case of other VFS usages that are not sockets? Can that be confirmed as still working when using 61 sockets (as example)?

[rdgoprslv]

I agree it would be ideal that Kconfig itself defined FD_SETSIZE, but I don't know enough about Kconfig to make it happen.

Also, I spotted a off-by-one error, local_fd_t supports 256 files, not 255 as previously stated. This add one to the theoretical maximum allowed FD_SETSIZE and CONFIG_LWIP_MAX_SOCKETS.

About testing

• Hardware:
  • Chip is ESP32-S3 (QFN56) (revision v0.2)
    • Features: WiFi, BLE, Embedded PSRAM 2MB (AP_3v3)
    • Crystal is 40MHz

PSRAM being used for configuration data only.

• Firmware:
  • Configurations used in every scenario:
    CONFIG_LWIP_MAX_ACTIVE_TCP=255
CONFIG_LWIP_MAX_LISTENING_TCP=255
  • Running a Port Forwarder from PPP to Ethernet.
  • FS used for files is littlefs.

First scenario

FD_SETSIZE=64 (tool default)
CONFIG_LWIP_MAX_SOCKETS=61

Results:

• Simultaneously opened 61 listening sockets successfully, trying to accept a connection fails, as expected.
• Simultaneously opened 21 listening sockets, 20 accepted clients, and 20 sockets connected as a client successfully. Trying to accept the 21st client fails, as expected.
• Since FD_SETSIZE=64 and CONFIG_LWIP_MAX_SOCKETS=61, that leaves room for 3 "regular" FDs, used by stdout, stdin and stderr, trying to open a file via littlefs fails, as expected.

Second scenario

FD_SETSIZE=64
CONFIG_LWIP_MAX_SOCKETS=32

Results:

• Simultaneously opened 16 files, 8 listening sockets, 8 accepted clients, and 8 sockets connected as a client successfully.

Third scenario

FD_SETSIZE=256
CONFIG_LWIP_MAX_SOCKETS=253

Results:

• Simultaneously opened 50 listening sockets, 50 accepted clients, and 50 sockets connected as a client successfully. Hardware RAM limitations prevents opening more sockets.
• Since FD_SETSIZE=256 and CONFIG_LWIP_MAX_SOCKETS=253, that leaves room for 3 "regular" FDs, used by stdout, stdin and stderr, trying to open a file via littlefs fails, as expected.

Fourth scenario

FD_SETSIZE=256
CONFIG_LWIP_MAX_SOCKETS=200

Results:

• Simultaneously opened 25 files, 25 listening sockets, 25 accepted clients, and 25 sockets connected as a client successfully. Hardware RAM is the limit.

Further optimizations on port forwarder firmware would allow bigger numbers, but I think this is enough for now.

[euripedesrocha]

Hi @rdgoprslv thanks for the contribution. The changes were merged in 48295d3

[atanisoft]

Any chance of a back port to 5.3?