[linux-dvb] Re: DVB-CI question

[Johannes Stezenbach <js@convergence.de>]

On Fri, Mar 26, 2004 at 03:08:18PM +0000, Andrew de Quincey wrote:
> 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. 

If it were as complicated as you say, userspace would be the right
place. But we have the av7110 firmware implementation, and a proprietary
STB driver, and while it is admittedly not simple there is *no* locking at
all. Because CI is essentially driven by polling (the CAM cannot send
data spontaneously, the host has to poll for data).

Also note, the av7110 implementatton uses a single 64K buffer for all
fragments, and that seems quite sufficent. The list handling for fragment
reassembly is not easy though.

It works approximately like this:

o send TPDU to CAM:
  - fragment TPDU to negotiated fragment size and put in list
o receive TPDU from CAM:
  - wait on ringbuffer wait queue
o poll CAM (from kernel thread or similar):
  - receive fragments from CAM and put in list
  - send fragments from list to CAM
  - check received fragments in list for completed TPDU
    and put in ringbuffer


Johannes


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