RE: [lwip-users] lwip driver model

[Bill Auerbach]

Jeff,

1. You want to poll Ethernet_input plus update all of the lwIP timers in
your polling loop.  If this is in a task, only this task is permitted to
make lwIP API calls.  Most implementations I've seen call ethernetif_input,
not netif->input.

2.  Yes, with the protection.  I would not call Ethernet_input from the isr
because it could run a long time passing the packet up the stack for
processing.  I suppose you could protect ISR reentrancy and protect calls
into lwIP while in the ISR, but it's not necessary.  You need to run a loop
for lwIP timers and it's just as efficient to call Ethernet_input as well.

3.  Yes.  Which is why it's easier to just store the packets and have the
polling loop process them.

I posted a message on this list not too long ago with a function that takes
care of all of the lwIP timers and calls ethernetif_input.

I use the RAW API, or NO_SYS=1 as some here refer to it.

Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of Jeff Barber
>Sent: Wednesday, March 11, 2009 3:23 PM
>To: Mailing list for lwIP users
>Subject: [lwip-users] lwip driver model
>
>I'm planning to port lwIP into a new system.  I want to use the raw
>API with no OS.  I will need to write a new ethernet NIC driver and I
>just want to make sure I completely understand the driver model (I
>find the documentation available on this subject rather confusing).  I
>would appreciate it if someone could confirm the assumptions here, or
>explain where I'm off base.
>
>1. The function ethernet_input should be called to introduce new
>packets into the lwip stack.
>   (Or, more specifically, it appears that my framework should specify
>ethernet_input in the netif_add call as the input function; then the
>driver should call netif->input.)
>
>2. Interrupt handler *may* call pbuf_alloc or mem*_alloc in interrupt
>context (with an appropriate definition of sys_arch_protect) but
>should not call ethernet_input if there is any chance that other code
>in the stack is already executing.
>
>3. Hence, practically speaking, the interrupt handler will need to
>defer actually introducing packets into the stack until the main
>polling loop.
>
>Thanks a lot,
>Jeff
>
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-users