scatter/gather DMA does this quite nicely (need to design a device
layer, so that cards that have this acceleration can benefit from it)
> (2) Process header to see who/what/why/where.
granted - but this is not a copy, it is just referencing memory
> (3) Page in user buffer, could start on any boundary. Could be too
> small for the whole packet. In the meantime more packets are
> arriving.
maybe a packet ring interface would be useful...
> (4) Copy or DMA user data.
prefer DMA, let CPU do something useful
> (5) Checksum the whole thing, i.e., header which is somewhere in the
> kernel, plus the user data.
once again, get support for cards that do this - otherwise
do it below the device layer.
> (6) Checksum is bad. Zero out user data, ignore IP header.
this is error recovery - not the fast path to begin with.
> (7) Packet arrived out-of order, allocate a buffer for it, copy from
> user buffer to allocated buffer. Zero out user data.
once again, not fast path- but you could easily see allocating a couple
of extra buffers (prefetching concepts)
> (8) Packet is okay, see if more room in user buffer, if so adjust
> pointers and branch to (1)
slightly tricky, some DMA playfullness can make this not so bad.
> (9) Wake user.
>
> It seems to me that it's just more efficient to copy to kernel buffers
> as is done, then pack buffers and copy data to user-space when requested.
>
> A user should not be required to have a read() or recv() in the queue
> at all times which would seem to be a requirment for a system that
> is able to send directly from the hardware to the user. Presently, with
> connected sockets, the kernel will accumulate data so when a user wants
> it, it is available.
>
> Cheers,
> Dick Johnson
i slightly disagree, i think an architecture needs to be setup so
that a device layer can be used for acceleration, if the card can
assist in the functionality, then let it - otherwise have the fallback
of doing it in software.
Charles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/