Re: AW: [lwip-devel] Packet queues (was Re: [bug#11400]ARP multi-packet-queue modifies TCP ...)

[Jonathan Larmour]

Goldschmidt Simon wrote:
> Jonathan,
>
>  >> 2. With a PBUF_REF, I simply 'hope' the ethernet hardware is
>  >> fast enough
>  >> (I have only 20 packets on queue max, that's about 2.5 ms to send all
>  >> packets)
>  >It can be true on any RTOS where network operations can be pre-empted by
>  >higher priority tasks - perhaps even the thread that is sending the data
>  >will be a high priority task preventing execution of the lwIP tcpip
>  >thread.
>
> (I was talking about udp_send() here, but it's also true for ICMP and 
> RAW and maybe other protocols, not TCP though -> queueing):
> I don't think that's possible. e.g. in udp_send(), ip_output*() is 
> called, which calls netif->output(). So, when udp_send() returns, the 
> packet is (aside from ARP queueing) either already sent (if the driver 
> waits) or for a normal DMA-driver, in the DMA-queue. 

Those are the important things though - the ARP queue and the driver's own 
queue. The driver's queue may be for DMA, or may not - any interrupt-driven 
driver implementation would also probably have buffering, as it's 
significantly more efficient.

> The only problem is: the application thread could be running again (and 
> modifying the pbuf or its payload) before the hardware DMA'ed the packet 
> out to the wire. _That_ I meant does not happen in my system, but might 
> in others!

It certainly will in others.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
  **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> **
  **  April 3-5 2007, Booth 1922, San Jose McEnery Convention Center  **
------["The best things in life aren't things."]------      Opinions==mine