[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [task #6861] Pimp ip_frag.c
From: |
Jonathan Larmour |
Subject: |
[lwip-devel] [task #6861] Pimp ip_frag.c |
Date: |
Fri, 20 Jul 2007 15:16:32 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070530 Fedora/1.5.0.12-1.fc5 Firefox/1.5.0.12 |
Follow-up Comment #13, task #6861 (project lwip):
Hi folks. Sorry I've been out of touch - I was off on vacation for 3 weeks or
so, and then returned to work to be dumped into major firefighting. I'm only
now starting on the lwIP backlog that built up in the time. Anyway.....
Re comment #7: I've no idea what was going on there. I know I tested some
version of the code but it's highly improbable it could have worked with that
flaw. Unless perhaps I made what I thought was a minor tweak after testing
:-|. Anyway, what you say is right.
Re comment #8: I assume you're referring to the IP_FRAG_USES_STATIC_BUF==1
case. I guess you could indeed use a PBUF_RAM. However this would make even
more obvious a flaw with the static buffer approach - what if the hardware
hasn't sent the pbuf by the time this function could have been called a
second time. But nicely enough, using a pbuf does seem to allow us a way to
catch this - check the pbuf reference count.
Re comment #9:
Kieran wrote:
> Out of interest, has anything been done with this option to
> prevent the reassembly code consuming all the pbufs, so
> stopping the rest of the stack?
I'm not sure what the issue you're referring to here is - the reassembly code
only allocates pbufs when reassembly is complete. If you were referring to the
fragmentation code, then that does not store up pbufs - any created pbufs
should get sent to the hardware; or if memory runs out, freed.
Re comment #10:
> (BTW I'm still not convinced we need a switch for this, the
> PBUF_REF code should be OK!)
I don't mind personally, but clearly the PBUF_REF code is bigger, and takes
longer (lots of pbuf allocs being done as well as the code itself). That
being said, a fixed size, permanently allocated large buffer seems worse.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/task/?6861>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
- [lwip-devel] [task #6861] Pimp ip_frag.c, Kieran Mansley, 2007/07/13
- [lwip-devel] [task #6861] Pimp ip_frag.c, Simon Goldschmidt, 2007/07/13
- [lwip-devel] [task #6861] Pimp ip_frag.c,
Jonathan Larmour <=
- [lwip-devel] [task #6861] Pimp ip_frag.c, Simon Goldschmidt, 2007/07/20
- [lwip-devel] [task #6861] Pimp ip_frag.c, Thomas Taranowski, 2007/07/23
- [lwip-devel] [task #6861] Pimp ip_frag.c, Simon Goldschmidt, 2007/07/23
- [lwip-devel] [task #6861] Pimp ip_frag.c, Thomas Taranowski, 2007/07/23
- [lwip-devel] [task #6861] Pimp ip_frag.c, Jonathan Larmour, 2007/07/26
- [lwip-devel] [task #6861] Pimp ip_frag.c, Jonathan Larmour, 2007/07/26
- [lwip-devel] [task #6861] Pimp ip_frag.c, Simon Goldschmidt, 2007/07/26
- [lwip-devel] [task #6861] Pimp ip_frag.c, Kieran Mansley, 2007/07/26
- [lwip-devel] [task #6861] Pimp ip_frag.c, Thomas Taranowski, 2007/07/27
- [lwip-devel] [task #6861] Pimp ip_frag.c, Thomas Taranowski, 2007/07/27