lwip-devel
[Top][All Lists]
Advanced

[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/





reply via email to

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