[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #51925] Replace the OOSEQ max bytes and pbufs constant

From: Douglas
Subject: [lwip-devel] [bug #51925] Replace the OOSEQ max bytes and pbufs constants with functions.
Date: Sun, 3 Sep 2017 05:30:14 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0


                 Summary: Replace the OOSEQ max bytes and pbufs constants with
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: ourairquality
            Submitted on: Sun 03 Sep 2017 09:30:13 AM UTC
                Category: TCP
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: git head



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.

It also helps to be able to consider the available dynamic memory when
advising an appropriate maximum number of bytes to buffer on the ooseq list.

These decisions can also benefit from knowing the number already allocated on
a particular pcb, so this is passed to these functions. For example, if the
system only wants to allow the total number of rx pbufs queued on all the
ooseq lists to grow by one and a call is make indicating a pcb already has two
then it can return three for this call, but might return one for another call
- supporting a greedy allocation strategy.

Found I needed this on the esp8266 which has a limited and fixed rx pool.
While the pbufs could be copied on input to lwip that wastes the rx pool.
Perhaps OOSEQ should not even be contemplated on such a limited device, but
when combination with SACK it makes a big difference on a wifi link with high
loss, and if there is only one pcb working hard then it is practical to keep a
few buffers on the oosq list, even being able to buffer just one buffer on the
ooseq list makes a big difference.


File Attachments:

Date: Sun 03 Sep 2017 09:30:13 AM UTC  Name:
0001-Replace-the-OOSEQ-max-bytes-and-pbufs-constants-with.patch  Size: 5KiB  
By: ourairquality



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]