[linux-dvb] Re: V4 Demux Point

[Rob.McConnell@Zarlink.Com]

Hi Again,

Johannes Stezenbach <js@convergence.de> wrote on 07/09/2004 16:30:02:

> Hi Rob,
>
> Rob.McConnell@Zarlink.Com wrote:
> > 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).

Would this be Vulcan? ;^)

> 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.)

What is the lowest spec h/w + arch that you have successfully tried this
on?  For example, would a RISC arch running only at 50MHz be fine, or would
you need something > 200MHz with sufficient cache?  Have you tried running
this on simple h/w that only does PID filtering?

I don't want to get into a trap where we have the situation where our or
someone else's s/w cannot run fast enough on our h/w and we need to
redesign the API and go through the design cycle again.  Do you have any
figures for cpu loading (e.g. top) or profiling?

>
> > 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.

I'm happy with using the API as long as there is sufficient CPU power to do
the job adequately.  Unfortunately, we don't have the time to go back and
redesign things again.

Thanks!

Rob : )