Re: [lwip-devel] again... Zero Copy Ethernet interface

[Alain M.]

Piero 74 escreveu:

1. i like HOOKs with defines... in the past i discussed in freertos forum about how adding kernel tracer possibility, and the decided solution was hook functions inside defines (see the last freertos release)

Hooks inside defines are great if you want to ADD a functionality to a function

In this particular case, I am advocating a different approach which is to allow the port implementator to completetly rewrite those functions.

As an example, in another today's post someone is allocing pbufs in flash... That is really completley different!!!

What most call my attention is the number of people who have been strugling to implements pbuf alternatives. To the least, it shows that a new pbuf modutalization is needed.

Alain

2. i think that HERE we have to summarize ideas, and, as Simon said, produce a template, a "skeleton" which should be used to start zero copy driver with DMA implementation, providing some guide lines, depending of various DMA limits, depending of HW; and, yes, some ready-to-use routines should be provided

3. when discussion here will produce a stable results, move changes to lwip stack, and add pages on wiki

Now i'm reading again my microcontroller user manual... i forgot details about my emac DMA works...

after this i will try to discuss here if proposed solutions up to now, are applicable on my HW,

and i will try to summarize in one email all the important results.

Out Of Thread...

i think that the future step to improve lwip performance, after these guide lines about zero copy driver, should be a review of BSD socket layer.

I suppose that may lwip users uses sockets and an OS, and wants good performances,

Bye

Piero

2009/1/7 address@hidden <address@hidden>

Jonathan Larmour wrote:

It certainly needs to be carefully considered. Different devices have
different properties:

- some must have all buffers (RX and TX) in a defined region of memory
- some must have RX in one region, TX in another
- some can have buffers in one region and use that preferentially for
speed, but can fall back to slower memory if needed
- some can tolerate the 'struct pbuf' header, some can't
- some can scatter gather, some can't
- Some allow entirely variably sized buffers.
- some have fixed size buffers, which may be fixed at the MTU, or may be
smaller; and may be hard-coded for that hardware (e.g. 128 bytes on
AT91SAM7X) or can be any size, but it has to be fixed for all buffers when
the device is initialised.
- some have fixed size buffers and require them to be filled for all but
the final one in the chain
- some have fixed size buffers and don't mind if they are not all filled
- some have associated buffer descriptors which need fiddling with when the
pbuf data becomes available again after having been freed.
- In any of the above, there can be alignment constraints above and beyond
the CPU architectural alignment; most frequently DMA and/or cache line.

And the real annoyance: you could have two different devices with different
(non-overlapping) sets of the above restrictions.

 

Nice list. I guess the hook method is quite a nice start for a generic solution: I can't see how we can easily cover all of the above.

In addition to the hooks we could/should provide:
a) an example or template implementation of a relocatable pool to allocate memory from a specific predefined region,
b) a flag if a pbuf is allocated for RX or for TX and
c) an example or ready-to-use routine to be used in low_level_output() that can copy a pbuf to new pbufs if the originals cannot be used

The seldom cases where an RX pbuf is reused for TX can be solved by c).

Although this is not a complete solution for zero-copy, it would allow many users for zero-copy DMA which currently have to change the lwIP core code to get that.

Simon