Re: [lwip-users] buffering outgoing packets

[Tyrel Newton]

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.
>
> Thanks,
> Jeff
>
> 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.
> >
> > Simon
> > --
> > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> >
> >
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/lwip-users
> >
> >      
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>