[linux-dvb] Re: refactoring

[John Dalgliesh <johnd@defyne.org>]

On Sun, 17 Oct 2004, Holger Waechtler wrote:
>
> John Dalgliesh wrote:
>
> >On Fri, 15 Oct 2004, Holger Waechtler wrote:
> >
> >>The entire ringbuffer of DMA areas is exposed read-only to the
> >>application and every client can query via ioctl() the current DMA write
> >>pointer position or the number ov valid (filled) DMA areas, or simply a
> >>bitfield describing which DMA buffers are filled with data.
> >>
> >>Ringbuffer read-pointers need to get handled by the application,  the
> >>situation is basically similiar to the one when you program a DMA driver
> >>in kernel space, you can only read the current write position register
> >>from the hardware.
> >>
> >>
> >
> >As you may recall this is what I've done in my Mac drivers. But I've taken
> >it one step further and exported the current write position via a
> >single-page memory mapping to userspace as well (so there are two memory
> >mappings, one big one and one small one).
> >
> >The driver gives the user information about where in the mapping the level
> >is to be found and how to turn it into a number of bytes. For PCI devices,
> >this means that the userspace program doesn't ever have to cross into the
> >kernel in the normal process of decoding, so there is no overhead there
> >(the small mapping exported is part of their PCI register address space).
> >Moreover, it means that the kernel drivers aren't interested when new data
> >is ready, so they don't have to setup or handle interrupts - once a
> >channel has been tuned the kernel drivers sit back and do nothing.
> >
>
> How do you check whether new data is available? Are you doing
> busy-polling on the write position? I wanted to wake up a
> poll()-waitqueue in the data-available irq, but maybe there are better
> ways...

Well the thing is that there is almost always new data waiting (at least
on full-TS devices) so it's not really busy waiting. The user program just
gets a chunk of new packets, then does whatever it wants to them: writes
them to disk, sends them over the network, demultiplexes the PES for
decoding, etc.

By the time it's finished that there's almost always more packets that
have arrived in the meantime. Faster loops just get less latency and
smaller bunches of packets at a time. If a program wants to do something
with high latency (like decoding video) then it will have to copy the data
to its own buffer before it disappears from the ringbuffer. But usually
those programs need to do something more complex with the input anyway
(like building the PES, etc.) and will naturally be copying for that.

I do have a usleep of about 1 quantum if no more data is available but
that's mainly to prevent a busy waiting loop when the frontend is not
locked. In practice it doesn't happen for programs that do stuff with the
data - it only takes a few microseconds until more is available. And if a
program doesn't care about latency (e.g. it is just writing the TS to
disk) then it can add its own usleeps to taste. The ringbuffer is big
enough for around 1/2 a second of data so there is a fair amount of room
to manoeuvre.

> Holger

{P^/