[lkml]   [2005]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] [PATCH 0/3] ioat: DMA engine support
    On Wed, Nov 23, 2005 at 11:30:08PM +0100, Andi Kleen wrote:
    > The main problem I see is that it'll likely only pay off when you can keep
    > the queue of copies long (to amortize the cost of
    > talking to an external chip). At least for the standard recvmsg
    > skb->user space, user space-> skb cases these queues are
    > likely short in most cases. That's because most applications
    > do relatively small recvmsg or sendmsgs.

    Don't forget that there are benefits of not polluting the cache with the
    traffic for the incoming skbs.

    > Longer term the right way to handle this would be likely to use
    > POSIX AIO on sockets. With that interface it would be easier
    > to keep long queues of data in flight, which would be best for
    > the DMA engine.

    Yes, that's something I'd like to try soon.

    > But it's not clear it's a good idea: a lot of these applications prefer to
    > have the target in cache. And IOAT will force it out of cache.

    In the I/O AT case it might make sense to do a few prefetch()es of the
    userland data on the return-to-userspace code path. Similarly, we should
    make sure that network drivers prefetch the header at the earliest possible
    time, too.

    > I remember the registers in the Amiga Blitter for this and I'm
    > still scared... Maybe it's better to keep it simple.

    *grin* but you could use it for such cool tasks as MFM en/decoding! =-)

    "Time is what keeps everything from happening all at once." -- John Wheeler
    Don't Email: <>.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-24 01:22    [W:0.025 / U:147.620 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site