[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
>