Re: [lwip-devel] [task #7896] Support zero-copy drivers

[Jonathan Larmour]

On 17/06/10 21:10, address@hidden wrote:
> Wow, your alive, hehe. Nice hearing from you!

I had a year off, and now my time is directed by the way the wind blows
from my work. Which may involve improving lwIP... but as ever time is money.

> Jonathan Larmour wrote:
>>> I think it would still be more efficient if
>>> you don't have chained DMA if you had to do this in 2 separate
>>> transfers to the MAC.
>>>      
>> Not all MACs would be able to do that.
>>    
> For example the last FPGA-based MAC I used only allowed single-buffer
> ethernet frames that are aligned on a 32-bit boundary.
> 
> So reading the rest of the mail, is this (task #7896) all about
> alignment only? Because if so, I wouldn't want to let that hold back
> 1.4.0 if it's only new code, not changing the API.

I would expect supporting zero-copy to involve some API changes (or at
least extensions) and some major surgery to the packet buffer code. But if
you're talking about a 1.4.0 release in the near future, I don't think
there's much chance of this being done and dusted by then, so if I were
you I wouldn't let it block a release. Just my opinion :).

> The only thing I can add is that for my other MAC, the only limitation
> is alignment, too. There might be other things though (like having all
> pbufs of a specific maximum length for RX), but I guess these could be
> also solved by allocating pbufs correctly.

More widely, there can be other issues beyond alignment, such as the
location of the payload contents - it may need to be within a PCI window
in memory for example. Or it may need to reside in one particular bank of
memory[1]. Again this points to changing the way pbufs are allocated.

Also in some cases we can't put arbitrary data amongst the packet data. So
we would have to allow pool pbufs where the struct pbuf _doesn't_ precede
the pbuf payload. That bit isn't hard at least.

There's the question of multiple devices - different MACs could have
different requirements. Covering all bases may be tricky, certainly given
a straightforward pbuf_alloc with no indication which MAC will eventually
be used with it. I don't know if we could come up with a usage model which
could do it. We may have to say we can't guarantee zero copy with multiple
different devices; and that isn't very common at least. We may have to
have per-device pbuf pools.

In all cases, drivers would probably have to be written so that they
didn't _require_ zero-copy, but would be able to fall back to copying if
their various requirements weren't met.

Jifl
[1] The NXP LPC24xx series is an example, certainly the LPC2468. It has
16Kb directly addressable on-chip ethernet RAM. It _can_ also address
normal external off-chip RAM, but that's much slower, and in fact we found
it caused packets to get dropped readily.