Repository navigation
wiznet: lwip: Implement zero-copy for socket buffers. - #17447
greezybacon wants to merge 1 commit into
Conversation
This avoids an issue for WIZnet devices:
1. In the `wiznet5k_poll` method, if the chip indicates there is data
available to receive and it is received but no buffer space is
available in LwIP, then the packet will be fetched from the device
and discarded. Instead, now it will remain on the device until
sufficient memory is available in the MCU.
Additionally, it optimizes and simplifies the usage of the WIZnet device
based on the assumption that the MACRAW mode will be used on exactly one
socket on the device. It also sends and receives socket buffers directly
between the device and LwIP PBUFs without a copy. It frees 1514 bytes of
a static Ethernet frame buffer over the baseline.
Signed-off-by: Jared Hancock <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #17447 +/- ##
==========================================
- Coverage 98.54% 98.54% -0.01%
==========================================
Files 169 169
Lines 21890 21943 +53
==========================================
+ Hits 21571 21623 +52
- Misses 319 320 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Code size report: |
|
This looks like a really good improvement!
Hmm, that might be a problem. The stm32 port has supported W5200 and W5500 ever since the beginning, and I still have a few lying around that can test with. I guess W5200 is very old by now so we could remove support for it. Users need to explicitly enable it for custom builds, so they could add it back themselves if needed (or stick with and older version of MicroPython). |
|
@dpgeorge I don't mind adding support back for the 5200 and/or 5300. Where could I get a demo/eval board to test against? |
I don't know! I'm happy to test. If you can just add some code that looks reasonable and builds for the W5200, then I can test and feedback any changes that need to be made. |
3 participants
Summary
This is closer to a zero-copy mechanism for the Wiznet chip and LwIP stack. Instead of using a static Ethernet frame buffer, it copies from the device directly into LwIP pbufs and visa versa.
Additionally, it avoids an issue for WIZnet devices:
wiznet5k_pollmethod, if the chip indicates there is data available to receive and it is received but no buffer space is available in LwIP, then the packet will be fetched from the device and discarded. Instead, now it will remain on the device until sufficient memory is available in the MCU.Furthermore, it optimizes and simplifies the usage of the WIZnet device based on the particular usage that the MACRAW mode will be used on exactly one socket on the device. It frees 1514 bytes of a static Ethernet frame buffer over the baseline.
Testing
I've tested this pretty extensively on the RP2040 and WIZnet W5100S. Based on interest, I'm happy to test it further on other devices.
Trade-offs and Alternatives
As written, it removes support for the W5200 and W5300 chips- although there is no reference board or firmware in the project for these devices.
However, insourcing a simplified driver could make for a simpler platform to add support for the W6100.
If Ethernet tracing is enabled, when traces are written to the console, if the LwIP pbuf is fragmented, only the first fragment is traced. This is to prevent the need for a copy of the buffer.