Re: [lwip-users] lwIP reentrancy issues and TCP

[AjK]

Richard,




> It  is always apprecated by the FreeRTOS community if projects that that,
> if they  are using FreeRTOS, are posted to the FreeRTOS Interactive site:
> http://interactive.freertos.org

I'll have a look at see what's what here, I may have something to publish 
although a lot of my work is more "how-to and understand" rather than "grab 
install and go" if you get the difference ;)


> So there is one queue per protocol being  handled.
> 
> You could alternatively have a single queue, but post to the  queue a
> structure that has the protocol identifier as one member, and a  pointer
> to the data as another member.  Then you could have one task  that
> handles both protocols - the first thing it does is check the  protocol
> identifier to know which function to pass the data to to get  processed
> correctly.

The issue here is that I have a system which is non-rtos. It was the first 
implementation I did and was born from the fact that other drivers I had 
encountered were "we love LWIP and no you cannot grab an ethernet packet that 
we 
don't like". Basically, initially I just wanted to do LLDP broadcasts and parse 
incoming broadcasts, no more than that (no LWIP at all). But, back then, 
hooking 
into the device driver just wan't possible. So I decided I'd just hack the 
driver code. That's when I found all this non-sense of the descriptors writing 
to a buffer (big buffer, large enough for a full packet) and then /if/ it's 
0800 
or 0806 (ip or arp) pbuf_alloc() and copy the buffer. I was like, "erm, what?". 
So I decided to write my own driver. So the easiest and most obvious method was 
to allow "protocol handlers" to register themselves with the driver pass am 
etherType uint16_t and a C function pointer for the driver to call. Pretty 
standard stuff. Then when I came to also so LWIP the netif code just became 
another protocol handler.

I like that callback model as it's simple to implement, simple to understand 
and 
is capable of catering for both rtos and non-rtos.

However, thinking more on this (I just had a break for something to eat!) it's 
looking more to me that maybe I am being a bit lazy on this. What I should 
probably do is split my driver up with conditionals that "build it for 
FreeRTOS" 
or "build it for non-rtos classic mode". If it's going to stand up as being a 
reference design then there really should be a clear road map through the code 
demostrating each method.

> Be  careful of using critical section type protection mechanisms.  If
> that  can be done in FreeRTOS depends on the port being used.  

Actually, my "non-rtos" design disabled EMAC RX IRQ to prevent buffer pointers 
being corrupted. Having looked at CM3 port I see a critical section is 
basically 
just that (albeit a little more crude by whacking all interrupts!). So, taking 
your advice, I need to look at this part and redo it. Splitting the driver to 
two compile methods is clearly the way forward to produce a clear reference 
design for either non-rtos or FreeRTOS implementations. Splitting it would 
probably help my sanity too ;)

> I find normally you can do the re-allocation of a buffer to the EMAC driver 
> at 
>the task level too.

Excellent, just the sought of feedback/advice I'm looking for. Having not done 
this in RTOS before it's always a wonder "will it keep pace?"

> When you have data  passed to the task, the task knows that the
> descriptor from which the data  originated needs to be allocated a new
> buffer.  Then, when the  processing of the data in the buffer has been
> completed, the task releases  the memory again.

Not quite. As it stands the driver makes callback to the protocol handler and 
passes a struct pbuf * to a pbuf chain that represents the packet. It knows 
nothing about emacs, dma or descriptors. As for releasing the memory, again, 
that's lwips job to call pbuf_free() when it needs too. The driver can't do 
that.

However, in the split design, the task that gets handed the job of "doing 
something with the packet" can be fully aware of the emac driver as it'll 
simply 
be part of the driver. So in that case, yes, far more sense to pass to the task 
all it needs to know to get the job done (ie a flag which says "RX IRQ, go 
handle it please").

> I'm not sure what you mean by "hardware level".  

I just mean the split between parts that interact with the emac (hardware) and 
purely software (lwip). Lwip doesn't want to know anything about descriptors 
etc. It just wants data packets etc.

> > Although I'm fairly new to lwip-users mailing list I  have noticed that the 
>work 
>
> > I'm doing and going to publish addresses  many of the questions I've seen 
> > on 
>the 
>
> > list. 
> 
> Exactly.  I  was pointed to the Windows example in the lwIP contrib
> distribution as an  example that may be good for you too.  That would
> just then need  converting to use FreeRTOS instead of the windows threads.

I'll take the hint and use that maybe as "the end goal" when I do my write up ;)

regards,
--Andy