|
From: | Jonathan Larmour |
Subject: | Re: AW: [lwip-devel] Packet queues (was Re: [bug#11400]ARP multi-packet-queue modifies TCP ...) |
Date: | Tue, 10 Apr 2007 18:49:09 +0100 |
User-agent: | Thunderbird 1.5.0.10 (X11/20070301) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |