[Top][All Lists]

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

Re: [lwip-users] buffering outgoing packets

From: Tyrel Newton
Subject: Re: [lwip-users] buffering outgoing packets
Date: Fri, 30 Apr 2010 09:12:24 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100317 Thunderbird/3.0.4

That was my conclusion as well--simply disable IP fragmentation. My application only involves sending stuff over an Ethernet-only LAN with gigabit switches, so there should be no need for IP frag and reass if I only transmit stuff that fits within the MTU (though it sounds like IP reass is not a problem). To the networking gurus: is this a fair statement/assumption?

Btw, while I still have to copy the Ethernet frame to the driver's internal buffers, I'm trying to avoid the second, intermediary copy to another pbuf once the original pbuf reaches the network interface driver layer.

On 4/30/2010 8:54 AM, Jeff Barber wrote:
Hmm... I seem to have not been paying attention when this discussion
went by.  Now wondering what (if anything) I need to do.  I am using
zero-copy on both transmit and receive, and relying on the ability to
increase the pbuf reference count to keep the pbuf from being freed
while it's being transmitted.  (None of the issues mentioned in task
7896 apply to me so I think I'm okay on receives.)

Looking at the 29361 bugtracker entry, it appears that zero-copy
transmit is only an issue if there is IP fragmentation.  Is that
correct?  If so, then is it true that I would not have problems if I
have a known MTU and never send a "PDU" larger than the MTU?  Or in
other words, if I never send a UDP datagram that doesn't fit in the
MTU, and ensure that the TCP maximum segment size fits within the MTU?

In fact, it sounds like maybe I should just disable support for IP
fragmentation and reassembly altogether.


On Fri, Apr 30, 2010 at 2:10 AM, Simon Goldschmidt<address@hidden>  wrote:
Tyrel Newton wrote:
I'm wondering if there is any truth to this statement. Do outgoing
packets that are queued at the network interface driver level
really need to be copied verbatim into a separate buffer? This seems
counter-intuitive to lwIP's low-memory usage design goals.
That's a topic we've already discussing about and which we wanted to fix with 
1.4.0 (as it might involve API- or doc-changes). You can always try to not copy 
the packets (which is of course desirable), but you *might* run into changes if 
you are using the RAW API and are re-using pbufs passed to one of the 
output/send/write functions *or* if you are using IP-fragmentation (IP_FRAG==1).

See http://savannah.nongnu.org/task/?7896 and 
https://savannah.nongnu.org/bugs/?29361 for bugtracker entries about this issue.

GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

lwip-users mailing list

lwip-users mailing list

reply via email to

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