[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] low_level_output question
From: |
address@hidden |
Subject: |
Re: [lwip-users] low_level_output question |
Date: |
Tue, 07 Apr 2009 17:20:31 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Macintosh/20090302) |
Bill Auerbach wrote:
Incrementing the reference count is the way to move the freeing of the pbuf
from the stack to the Ethernet driver. It's been done by several
implementers successfully.
I can tell you that won't work if
- sending data over UDP using the sockets API and
- having a fast device and
- modifying the buffer passed to lwip_send(to) after it returns
The reason is that (like I said in my previous post), incrementing the
ref-count will do for _RAM and _POOL, but not for _REF and _ROM pbufs;
udp sockets use _REF. Here, incrementing the ref-count prevents the pbuf
from being freed, but it does not prevent the actual from getting
modified before sending. The only two solutions are a) not returning
from lwip_send(to) until the data is sent by the hardware and b) copying
the data before sending (using PBUF_RAM, not PBUF_REF). Both solutions
have their problems, thus task #7896 to discuss it.
A comment in low_level_output to increment the
ref count if the packet isn't being physically sent before the function
returns and to free it at a later time when it has is sufficient.
I'm afraid it's not. See above.
What hasn't been clear to me is the safety of handling pbufs in interrupt
service
routines. Can a TX dma complete ISR call pbuf_free?
Yes, it can, as long as LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT is set to
1. Note this has been fixed after 1.3.0, so unless you are using a CVS
version from after that, you will have to wait for 1.3.1 to use it.
Simon
Re: [lwip-users] low_level_output question, Kieran Mansley, 2009/04/07