[linux-dvb] Re: DVB-CI question

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Friday 26 March 2004 14:33, Klaus Schmidinger wrote:
> Andrew de Quincey wrote:
> > I've had to write all this horrendously complicated buffering code in
> > order to support the CAM link level interface in the kernel; i.e. taking
> > the multiplexed packet fragments from multiple connection IDs/slots and
> > reassembling them into full packets. This means the code is quite quite
> > nasty; one buffer per connection id PER slot, combined with some complex
> > locking.
> >
> > I've just thought: why don't I just return the fragments, and expect the
> > userspace code to do the defragmentation. Then I could have just two
> > buffers for each CI slot, and virtually no complexity.
> >
> > What do you think? It means it wont work with existing apps until they
> > implement the packet re-assembly code... but thats not exactly hard to do
> > in userspace. I was going to revamp the DVB CI API a bit anyway (all
> > changes will have to be agreed by everyone naturally), so I could easily
> > add a new "CI interface type" for this.
>
> If it's not hard to do in userspace, why is it so hard in the driver?
> Why should every application implement this by itself? I'd say this should
> be done by the driver, and the applications shall exchange complete TPDU's
> with the driver. Or did I misunderstand this and you're talking about
> something completely different?

Its just it makes the driver's IO routines _really_ complex, as they have to 
deal with multiple connections, multiple slots, the possibility that the CAM 
can be yanked out by the user at any time, and lots of other things. There is 
a LOT of complex locking involved to ensure it can't break.

Add to that the fact that each de-fragmented packet can be up to 65536 bytes, 
so at least one of those buffers is needed PER connection PER slot. Adds up 
to a lot of wasted memory. It would also fix some otherwise unsolvable 
buffering issues in the driver (or rather, not solvable without some 
extremely nasty code).

IMO, the driver should be as simple as possible. I don't think the CAM 
interface benefits speed-wise from the reassembly being in the driver, so, 
apart from saving a little bit of extra code in userspace I can't see any 
good reason for the reassembly being in the kernel. Each app already has to 
implement all the other layers of the EN50221 control protocol stack itself; 
why not this extra bit as well? 

At the moment, I'm still convinced that this is a good idea. I'm implementing 
all layers of the EN50021 protocol and the driver in parallel right now, and 
userspace looks far more suitable for the defragmentation code. 


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.