[lwip-users] Re: [lwip] Forcing PBUF_POOL

[David Haas]

Peter,

I'll just comment on the driver part of this. The example driver show
copying from the pbufs into a flat buffer or directly out a port. This is
not necessary if your hardware supports descriptor rings. You can just put
the payload addresses into the descriptor ring and DMA will do the rest.
Just make sure you free the pbufs after transmission takes place. In this
way buffer chaining is also not too bad, since it is just another entry on
the descriptor ring. What hardware are you using?

Buffer chaining is useful in a protocol stack because you can preprend
additional protocol layers easily. It actually becomes more efficient than
moving the data. Even if you use a single buffer to put the data into in
UDP, it still will need an IP header and then a link-layer (ethernet or PPP
or SLIP) header. If you don't have room in the buffer to prepend the data,
then you really have to chain the buffers. I believe that lwip makes sure
there is enough room in the buffer to prepend the headers without chaining.
So there is actually no chaining most of the time.

I suppose you can use a canned ethernet header if you know what the
destination address will always be. But keep in mind you might have
broadcast frames.

David.

----- Original Message -----
From: "Wurmsdobler, Peter" <address@hidden>
To: <address@hidden>
Sent: Wednesday, November 20, 2002 6:40 AM
Subject: [lwip] Forcing PBUF_POOL


> Hello,
>
> We are considering to use lwIP for a control application, mainly UDP for
> control messages, but also TCP for other services. Therfore, speed is
> important and PBUF_POOL buffers are preferable, both for input and output.
> Second, since control messages are rather small, it will be unlikely that
> they have to be chained. Another issue is, that the underlying link layer
> will be FireWire, with a worst case payload of 512 bytes
> (for 100Mbit/sec).
>
> If I understand the current implementation correctly, what happens for UDP
> is: The application allocates a pbuf for data, fills them in and can then
> use udp_send to send the pbuf over a udp_pcb. Certainly the data can be
> longer than a PBUF_SIZE in which case there will be a chain. In any case,
> udp_send will chain a header buffer in front and finally over ip_output_if
> and netif->output sent it to the driver code. There the pbuffs have to be
> copied into a linear buffer which can be written to the device driver
> function.
>
> In our case, messages are much smaller than PBUF_SIZE (or PBUF_SIZE can be
> adapted to be 512). So it would be preferable for us to use a pre-canned
> pbuf containing already a link header, use those and have udp_send not to
> chain another pbuf in front. Even further, the link layer would not be
> obliged to copy all pbuf payload to a local buffer, but a pointer to the
> payload (including all headers) could be passed to the low-level output
> function. No copying would take place throughout the entire stack. In the
> case of bigger data, there would be the overhead that all pbufs in the
chain
> have to be populated with the same header.
>
> What do you think and how could I achieve this with the currrent code?
Would
> I need to write a modified udp_send function ?
>
> In the case of TCP, a tcp_write in the current implementation will enqueue
> the stream to be cut into segments. For each segment a MEMP_TCP_SEG and a
> PBUF_RAM of the segment size are allocated. The byte stream chunks are
> copied into the respective pbuf. If (pcb->mss) is negotiated to be always
> smaller than (512-(sum of all headersizes))), _and_ PBUF_POOL pbufs are
> used, then the same concept would also work. The driver could just use
> p->paylaod to stream the link packet to the device. Only one copy takes
> place.
>
> Is this reasonable? What changes do I have to make other than suggest in
> order not to break the stack?
>
> peter
>
> Peter Wurmsdober
> Eurotherm Drives Ltd.
> Littlehampton, BN17 7RZ, UK
> TEL: +44 19 03 73 73 58
> FAX: +44 19 03 73 71 07
> [This message was sent through the lwip discussion list.]

[This message was sent through the lwip discussion list.]