> But isn't this where sendfile(2) is used? The input file is your disc
> file and the output file is your network socket. The kernel triggers
> the DMA from disc to memory (say a skbuf) and then triggers the DMA
> from memory to the network interface. No cache pollution at all.
sendfile() does seem quite elegant, yes, but unfortunately it
doesn't match the application. The server deals with many
source files; they need to be multiplexed together into a
sequence of ~200-byte packets, interleaved to respect downstream
decoder timing, then sent at the correct rate to the output
interface, which is an MPEG-2 transport-stream PCI card. (The
card follows a descriptor list of packets, DMAing them out of
main memory, somewhat similar to a network card.)
Since these details aren't that interesting to anyone else,
I'm unlikely to find a send_multifile_with_MPEG_timing() in
the kernel, which is what I really need. The next best thing
is having the means to implement something equivalent.
> You could even develop this further and have the kernel trigger DMA
> from disc to network interface. No need to get memory involved at
> all. If we can do it with TV in a window (IIRC there is a direct
> PCI->PCI DMA from the video capture card to the display frame buffer),
> why can't we do that with your application?
If only the cache on the disk hardware were sufficiently large,
and disk could be byte-addressed rather than just 512-byte
boundaries, and something could be done about the timestamps,
this might work. It's certainly food for thought.
Cheers,
Peter Monta
-
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/