lwIP - A Lightweight TCP/IP stack - Bugs: bug #51925, Replace the OOSEQ max bytes and...
You are not allowed to post comments on this tracker with your current authentication level.
bug #51925: Replace the OOSEQ max bytes and pbufs constants with functions.
Submitter: | Douglas <ourairquality> | ||
Submitted: | Sun 03 Sep 2017 09:30:13 AM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Change Request | Status: | Fixed |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | git head |
Jump to the original submission
Thu 21 Sep 2017 08:37:54 AM UTC, comment #6: |
Simon Goldschmidt <goldsimon> |
Wed 06 Sep 2017 01:20:45 PM UTC, comment #5: The configuration does not use pbuf pools rather MEMP_MEM_MALLOC. The RX buffers are allocated from a special pool, from a NMI handler that can not call back into most of the library code, these later have a pbuf wrapper allocated as a reference - so these are not using pbuf_alloc for their primary allocation and the PBUF_POOL_IS_EMPTY does not help.
|
Douglas <ourairquality> |
Tue 05 Sep 2017 07:12:07 PM UTC, comment #4: Also, keep in mind that keeping backwards compatibility is a really strong requirement for us! We're open to throw things over, but not without compelling arguments! |
Simon Goldschmidt <goldsimon> |
Tue 05 Sep 2017 02:51:40 PM UTC, comment #3: I forgot about this, but there is already support to free OOSEQ packets upon PBUF_POOL exhaustion. See PBUF_POOL_IS_EMPTY (called from pbuf_alloc). Is this not working in your configuration? |
Joel Cunningham <jcunningham> |
Tue 05 Sep 2017 02:24:54 PM UTC, comment #2: Thank you for taking a look. Here is how this is being used, see the functions ooseq_max_bytes() and ooseq_max_pbufs():
|
Douglas <ourairquality> |
Tue 05 Sep 2017 02:02:45 PM UTC, comment #1: I took a look at your patch and I'm having trouble fully understanding how one is supposed to implement TCP_OOSEQ_MAX_BYTES and TCP_OOSEQ_MAX_PBUFS since no examples were provided. They could return constants to maintain the current behavior, but I want to understand the advantage this change provides
|
Joel Cunningham <jcunningham> |
Sun 03 Sep 2017 09:30:13 AM UTC, original submission:
Some systems need to take into account an RX buffer pool size when advising an appropriate number of RX pbufs to queue on the ooseq list. For some systems there is a practical hard limit beyond which the rx pool becomes exhausted blocking reception of further buffers until some are freed.
|
Douglas <ourairquality> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-09-21 | goldsimon | Status | None | Fixed | |
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed | |||
2017-09-06 | ourairquality | Attached File | - | Added 0001-Replace-the-OOSEQ-max-bytes-and-pbufs-constants-with.patch, #41744 | |
2017-09-03 | ourairquality | Attached File | - | Added 0001-Replace-the-OOSEQ-max-bytes-and-pbufs-constants-with.patch, #41720 |
Powered by Savane 3.13-caa5.
Corresponding source code
Pushed slightly changed:
- the *_LIMIT defines take the pcb, not the pcb's ooseq
- reverted your || -> && changes to make the defines work independently (which never worked before)