Re: [lwip-users] pbuf pool size / mss size in low memoryenvironmentandrouting to slow link

[David Empson]

----- Original Message ----- 
From: <address@hidden>
To: "Mailing list for lwIP users" <address@hidden>
Sent: Thursday, December 03, 2009 6:29 PM
Subject: Re: [lwip-users] pbuf pool size / mss size in low
memoryenvironmentandrouting to slow link


> David Empson schrieb:
> > "Simon Goldschmidt" <address@hidden> wrote:
> >
> > > "Marco Jakobs" address@hidden wrote:
> > >
> > > > I'm just wondering how the PPP of LWIP is handling the pbuf's, maybe
> > > > someone can drop a line about this ...
> > > I don't know that by heart but I think I remember the PPP code (as it is
> > > ported from sources that don't know pbufs) needs the input packets in
> > > contigouous memory and copies from PBUF_POOL to PBUF_RAM if the input
> > > packet is a linked list of pbufs (i.e. p->len != p->tot_len).
> >
> > I can't see any evidence of that.
> The function pppSingleBuf() does that. However, I'm not really sure how
> often that function is used. At least with pppoe (which I'M currently
> trying to get to work :), it seems to be called on every RX pbuf, though.

Ah, my mistake. I was looking at our port, which has been restructured and
doesn't do that. (Complete rewrite of the receive side.)

Looking at the standard PPP code in LWIP 1.3.2-rc1: pppSingleBuf() is also
in the PPP over serial code. It is used for received frames which get passed
on to internal protocol handlers in PPP (such as LCP and IPCP) that expect a
simple pointer and length, so they require a contiguous block of data.

It is not used for TCP or IP frames. They are passed on to standard LWIP
code as a pbuf chain.

I'm not familiar enough with PPPoE to analyse its usage there.

pppSingleBuf() is not used for transmit at all (in either PPPoS or PPPoE).

In summary, this still doesn't affect my earlier comments - the PPP code
will work fine with pbuf size less than MTU.

The only code that may have problems with pbuf size less than MTU are
applications or Ethernet drivers which aren't prepared to deal with chains
of pbufs.