[lwip-devel] [patch #9384] Partial SACK (RFC 2018) support

[Joel Cunningham]

Follow-up Comment #10, patch #9384 (project lwip):

> Now if that array had 5 entries (or more) that were valid SACKs, filling one
gap would leave us with 4 SACKs that could be included.
This is because we don't calculate them dynamically, but rather when new data
packets are received. 

I got to thinking about this and how there is a decent amount of complexity
managing the rcv_sacks array (tracking inuse/free slots, shifting entries
up/down, inserting new entries, etc) and thought we already have
infrastructure (in LwIP) for managing memory in this manner; the memory
pools.

Would it make more sense to have a MEMP_SACK_BLOCK?  Then maintain a linked
list in each pcb that has SACKs enabled and has entries on the OOSEQ queue.

This would allow much simpler insertion removal since it's a linked list and
inuse/free tracking is provided by the memp abstraction.  This could
potentially provide better memory usage as each pcb doesn't have to have spots
for 4 SACK blocks in their pcb.  It would also allow individual pcbs to have
more than 4 SACK blocks since they are allocated from a general pool

In some cases (each PCB claims MAX SACK blocks) it could use more memory
compared to implementation in your patch since we would need to add an extra
next pointer to the SACK block and the overhead from the memory pool
structure, but I'd imagine this wouldn't be the normal case

Is this more inline with how LwIP uses memory?  I can't think of an existing
case where an array is used directly like rcv_sacks is

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?9384>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/