Re: [lwip-users] udp (RFC!)

[David Haas]

Hi,


Leon Woestenberg wrote:

> Correct me if I'm wrong, but I thought all BSD socket calls give their
> buffer by reference. In that case, we could still deploy the zero-copy
> tactic used by lwIP, but have lwIP do a copy-on-demand in case it
> cannot handle the data directly (during the blocking call).
>  
Sure, all calls pass their data buffers by reference.

Copy-on-demand is a good idea, but there are actually two ways that data 
buffers get queued. We understand the arp problem, where a frame is put 
on the arp queue. But depending on the ethernet driver, frames might 
simply be queued on a DMA queue for output. The coldfire driver works 
this way. Data buffers are queued on a DMA ring for output. At some 
later time (depending on ethernet flow control or collisions), the data 
is DMAed out and another thread gets woken up by a signal from the 
transmit complete ISR. This thread then frees the pbuf whose data buffer 
was sent. Of course the DMA delay is much shorter than the ARP delay and 
probably does not cause a problem most of the time, but if you had a 
misconfigured or really slow ethernet, it could definitely cause a problem.

So for coldfire copy-on-demand would mean copying ALL frames sent via 
sockets. Note that frames sent (like ICMP or ARP frames) where PBUF_RAM 
buffers are used, don't need to be copied. If frame fowarding was being 
done, those frames would similarly not need to be copied.

I suppose I could fix this at a low level and copy all PBUF_ROM buffers 
into PBUF_RAM buffers before queuing onto the ARP queue or queuing in 
the output driver. I could write a pbuf_copy_if_rom() function in pbuf.c 
to do it.

Any other thoughts?

Regards,
David.

>