lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] Constraining pbuf pools location by the linker


From: Bastien Allibert
Subject: Re: [lwip-devel] Constraining pbuf pools location by the linker
Date: Fri, 21 Mar 2014 21:34:51 +0100

Hi Claudius,

Yes i meant CCM. The rest is effectively accessible from the Ethernet DMA. But 
till now, i located my bss segment in CCM, which was not a problem as long as i 
used “standard” ethernet driver (i.e. with payload copy before DMA transfer).

As per zero-copy driver, I’m not sure to get your point : a bit more 
complexity, for sure. But I’m not sure about which dynamic allocations you’re 
talking about ? please detail. Regarding buffer collector, i implemented it by 
posting a message into a mailbox every time a TX IRQ triggers. When this 
mailbox message is treated by the appropriate task, it automatically frees the 
pbuf chain. Again, more complexity, definitely agreed, but also more elegance 
as you said.

Now, about performance…. i honestly don’t know. I want to benchmark all of 
this, but do not have time to do that right now.

But if you are interested to share around this topic, I’m really interested to 
discuss and share my code (thinking of creating a github for it), and improve 
it together.

Regards
Bastien

On 21 Mar 2014, at 19:26, Claudius Zingerli <address@hidden> wrote:

> Hi Bastien,
> 
> On 2014-03-20 16:26, Bastien Allibert wrote:
> [STM32F4 zero copy]
>> The problem is : in STM32F4 chip, not all of the memory can be accessed
>> by the ethernet DMA. So, if i want to compute my DMA descriptors
> 
> Do you mean CCM? The rest should be accessible from the DMA.
> Do you really need zero copy? I was working on an implementation for the same 
> MCU, but despite the elegance, it increased the code complexity quite a bit 
> (More dynamic mem allocations, buffer collector, error handling). Your MCU 
> should be capable of giving you almost line speed (100Mbps Ethernet) while 
> still idling most of the time. Been there, done that and finally disabled ZC 
> again :(
> 
> Let me know about your ZC experiences.
> 
> Claudius
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]