[linux-dvb] Re: V4 Demux Point

[Johannes Stezenbach <js@convergence.de>]

Hi Rob,

Rob.McConnell@Zarlink.Com wrote:
> Hi Johannes,
> 
> A while back we were in discussions on the demux V4 API.  What I was
> unhappy with was the fact that you could not have multiple section filters
> attached to a single fd to match the underlying h/w.  For our DTV-1 chip,
> we would have to do a copy from the h/w buffer to each fd/process's kernel
> buffer wasting valuable time.  Additionally, the middle-ware would have to
> have more threads to deal with this architecture.  The end result is that
> the CPU load is higher as you have effectively more processes running  with
> greater context switching overhead and more copying being done.
> 
> There seems to be a technical conflict of interest between DTV chips that
> have a single h/w output buffer per section filter and ones like ours that
> allow you to attach multiple section filters on a single PID with a common
> h/w output buffer.  The current V4 API is indeed clean/lean, but we are
> particularly worried about the extra processor load especially as we are
> running demanding applications like MHEG-5 and 8-day EPG on our h/w.

Well, we run MHP and 8-day EPG on platforms which have the same
archtecture as yours (one hw ringbuffer per PID-filter, sections
get tagged to know which section filter they apply to and have to
be copied to the fd rindbuffer). Even for MHP object carousels (DSM-CC)
and EPG data the overhead for doing the additional copy seems to
be negligible. It would be noticable (but still bearable) for
high bandwidth dvb_net MPE. (Yes, there is some load when MHP
runs, but it's nearly all userspace, not kernel.)

> Are we at a point where the V4 API is now frozen or can we open up
> negotiations on the architecture again?  I would love to see an API that
> caters for both scenarios as this would be optimal.

The API is not set in stone, but it's getting harder to change
things now.

Ideally you could *prove* that there actually is a performance problem
with the API, and supply a patch to implement your proposal.


Regards,
Johannes