Re: [lwip-users] Memory management for packet buffers

[Mason]

Mason wrote:

> I'm trying to port lwip 1.4.0 to STMicro's OS21/OS+ operating system.
> 
> I've coded the required sys_arch.c
> 
> I'm now working on the Ethernet interface code.
> 
> On my platform, reads (rx) and writes (tx) are asynchronous.
> 
> Here's how the driver works for reads:
> 
> I register a packet-handling function, and 120 1536-byte buffers
> (large enough to store an entire frame). The driver "owns" these
> buffers. When a frame is received, the interrupt handler copies
> the frame to the first available buffer, then calls the packet-
> handling function. When the app doesn't need the buffer anymore,
> it returns control of the buffer back to the driver.
> 
> I'm not sure how to do this within the pbuf infrastructure?

Here's how I'm trying to solve the problem.

I've defined

struct buffer_desc_t
{
  struct pbuf_custom pbuf;
  ethernet_async_t   desc;
};

ethernet_async_t is the OS+ structure which describes a
buffer (address, size, callback function, private data)

I allocate an array of 120 such structs, each pointing
to a buffer suitable for DMA I/O.

I make each desc point to the corresponding pbuf.

When a packet is received, the IRQ handler calls
the callback function, with the desc as parameter.
In the callback function, I call pbuf_alloced_custom
to make the custom pbuf point to the frame we received,
and then I can call netif->input on the pbuf.

I have two problems  :-(

1) the clean-up function

The parameter of the cleanup function is a struct pbuf pointer,
but what I need is the OS+ desc.

Since the pbuf pointer is the first field of struct pbuf_custom,
which is the first field of struct buffer_desc_t, I think I may
get away with casting (struct pbuf *) to (struct buffer_desc_t *)
but it feels dirty and unsafe. Is there a cleaner way?

2) SYS_ARCH_PROTECT within the IRQ handler

netif->input is tcpip_input which tries to post the packet
to the tcpip_thread. To allocate the message, it calls
SYS_ARCH_PROTECT.

I've defined sys_arch_protect to use an lwip-specific mutex.
The problem is: it is illegal to block on a mutex in the
IRQ handler. Bleh!

(I can't mask interrupts just because the network stacks
needs a block of memory, or because multiple threads are
using the socket layer.)

Can someone guide me to the light?  ;-(

-- 
Regards.