>
> but isn't the real question - should the copy even take case? i have no
> doubt that if a copy occurs, some cheap computation (ie. a cksum can
> easily be hidden in the data transfer through the CPU).
>
> but, why should the copy even occur? there is easily enough research
> lingering around these days to show the zero copying is good (Unet for
> instance as well as ExoKernel) these were direct access to user space
> without copies, but the same philosophy can hold for kernel space.
>
> Charles
>
> >
Don't forget that it is unlikely that a new protocol will be invented
to support zero-copy. Therefore we have the problem of:
(1) Get only IP header from controller.
(2) Process header to see who/what/why/where.
(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.
(4) Copy or DMA user data.
(5) Checksum the whole thing, i.e., header which is somewhere in the
kernel, plus the user data.
(6) Checksum is bad. Zero out user data, ignore IP header.
(7) Packet arrived out-of order, allocate a buffer for it, copy from
user buffer to allocated buffer. Zero out user data.
(8) Packet is okay, see if more room in user buffer, if so adjust
pointers and branch to (1)
(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
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
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/