Wisdom of avoiding redundant buffer copying? - Embedded

This is a discussion on Wisdom of avoiding redundant buffer copying? - Embedded ; I'm working on a system (uClinux on Blackfin) which has a task that basically amounts to continuously: 1) Receive a block of data on the synchronous serial (SPORT) interface 2) Sometimes do a little processing or analyzing, but often not ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Wisdom of avoiding redundant buffer copying?

  1. Wisdom of avoiding redundant buffer copying?

    I'm working on a system (uClinux on Blackfin) which has a task that
    basically amounts to continuously:

    1) Receive a block of data on the synchronous serial (SPORT) interface

    2) Sometimes do a little processing or analyzing, but often not

    3) Transmit the block via ethernet

    4) Repeate seamlessly

    When I've done this thing on smaller and more primitive embedded
    systems, I've really tried to avoid copying the memory buffer - data
    is created in the same place in memory from which it will be
    transmitted by the ethernet stack.

    But if I use normal operating system paradigms, it would seem that my
    uClinux implementation would be

    1) Kernel mode driver receives data to its own memory buffer
    2) User program calling read() results in copy to user program's
    offered buffer
    3) User program calling send() results in copy to somewhere in the
    etherenet stack's memory

    Since I have to do a substantial re-write of the SPORT driver module
    anwyay, I keep being tempted to
    avoid the first buffer copy, and actually receive the data to the same
    memory at which the user mode program will access it. It didn't take
    long to get this working using suctom ioctl commands to deliver and
    release buffer pointers (no actually read() call), but I wonder about
    the degree to which it violates the programming model.

    Second, there are situations in which recopying could simplify things
    for me: for example, I have a situation in which I have 32 bit data
    interleaved with 16 bit data coming in via the SPORT. I can
    externally pad the 16 bit data to 32 bits and program the DMA
    controller to deinterleave the two streams two seperat buffers in
    memory. But then my 16 bit data will be sitting in a buffer
    interleaved with the 16 bit padding - which could perhaps be fixed by
    using a memory-to-memory DMA to deinterleave it when copying it to a
    user buffer supplied by a read() call.

    Another related issue: at one point I played with permanently
    allocating buffers by reducing the kernel's memory paramater below the
    top of physical memory, and using the space above that. This worked
    fine, except that calls to send() referencing these "invalid"
    addresses fail...

    Any thoughts?


  2. Re: Wisdom of avoiding redundant buffer copying?

    Yes, there is wisdom in minimizing buffer copies.


  3. Re: Wisdom of avoiding redundant buffer copying?

    On Aug 24, 6:14 pm, Just me wrote:
    > Yes, there is wisdom in minimizing buffer copies.


    But going how far in order to do so? Breaking the operating system
    model?

    Actually, I'm now looking into using mmap to do what I had done, only
    in a more model-consistent way.



+ Reply to Thread