Same old story...
> Hello
> If you in SYS_ARCH_PROTECT save the interrupt flags before you disable the
> interrupt and in SYS_ARCH_UNPROTECT restore the interrupt flags,
> You can use the functions in ISR
I guess you mean 'pbuf_free' by 'the functions'? If so, I have to dissapoint
you: if you us
...@whi.se
+46 8 449 05 30
-Ursprungligt meddelande-
Från: lwip-users-bounces+j.wester=whi...@nongnu.org
[mailto:lwip-users-bounces+j.wester=whi...@nongnu.org] För John Kennedy
Skickat: den 7 april 2009 17:00
Till: 'Mailing list for lwIP users'
Ämne: RE: [lwip-users] low_level_outpu
t: Tuesday, April 07, 2009 9:26 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] low_level_output question
John Kennedy wrote:
> Since pbuf_free decrements the pbuf reference count and only frees the pbuf
> when the reference count goes to zero I assumed that by incrementing the
>
John Kennedy wrote:
Since pbuf_free decrements the pbuf reference count and only frees the pbuf
when the reference count goes to zero I assumed that by incrementing the
reference count in the Ethernet driver it would prevent the stack from freeing
or reusing the pbuf, and that the Ethernet dri
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
lto:bauerb...@arrayonline.com]
Sent: Tuesday, April 07, 2009 6:31 AM
To: 'Mailing list for lwIP users'
Subject: RE: [lwip-users] low_level_output question
Incrementing the reference count is the way to move the freeing of the pbuf
from the stack to the Ethernet driver. It's been don
online@nongnu.org
>[mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On
>Behalf Of Simon Goldschmidt
>Sent: Tuesday, April 07, 2009 3:51 AM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] low_level_output question
>
>There's a task on savannah on t
On Tue, 2009-04-07 at 09:39 +0200, Fabian Koch wrote:
> I propose we do either of the following:
>
> 1) In the ethernetif-skeleton explicitly document the behavior and
> tell the developer to memcpy the data if their transmission is async.
> 2) See 1), but tell the developer to increment the ref
There's a task on savannah on this (#7896 ):
https://savannah.nongnu.org/task/?7896
Basically, the scheme will work on _POOL and _RAM pbufs, but not on _ROM/_REF
pbufs, which is why usage of these types would have to be adjusted (including a
copy-on-delayed-usage flag or something like that).
Hello everyone,
> Hi,
> I'm porting lwip (using an RTOS and the socket API) and I have a
> question regarding the low_level_output function.
> If I can't send the pbuf immediately (netif busy), to avoid copying
> the pbuf, I'd like to do the following:
> * Increment the reference count to
ennedy
>Sent: Thursday, April 02, 2009 6:16 PM
>To: lwip-users@nongnu.org
>Subject: [lwip-users] low_level_output question
>
>Hi,
>I'm porting lwip (using an RTOS and the socket API) and I have a
>question regarding the low_level_output function.
>If I can't send the p
Hi,
I'm porting lwip (using an RTOS and the socket API) and I have a question
regarding the low_level_output function.
If I can't send the pbuf immediately (netif busy), to avoid copying the pbuf,
I'd like to do the following:
* Increment the reference count to prevent lwip from re-using or
Hi there,
One short/quick question.
In the ethernetif.c module the function low_level_output() (or actually the function stored in netif->linkoutput) returns an value of the type err_t.
What happens when this is != ERR_OK?
Will lwip try to resend this packet later?
Will this be reported up to t
13 matches
Mail list logo
