Re: [RTnet-developers] Joint threads

[Vareka, B. <BV...@am...>]

> Vareka, Bill wrote:
>> I moved this over from Rtnet-users because this seems the more
appropriate
>> board.  Yes, I have thought about how to do this and at the moment I've
>> written a first stab at the code but I have yet to put together a system
to
>> test it on.  The crux of the changes are as follows:
>> 1) add a -j option to tdmacfg for 'slots' which takes the joint slot id.
It
>> will be required that the slot you want to reference to must have already
>> been defined before you define the joint slot.  Had not yet though about
the
>> actual tdma.conf file but this should be pretty straight forward.
>> 
>> 2) The tdma_config struct adds an additional int field called jointslot
to
>> the set_slot union.  A value between 0 and MaxSlots (but not 1) indicates
a
>> desire to be coupled.  Default is -1 (no coupling).
>> 
>> 3) Because of the special role of the default NRT slot (1) and the fact
that
>> a mechanism already exists for it to 'share' slot 0, I have strictly
>> forbidden the option to link slot 1 to other slots or other slots to it.
>> Also, since it's already NRT, there is no likely benefit in jointing it
to
>> other slots for speed and latency purposes. 
>> 
> 
> But slot 0 and 1 will not form a super-slot this way, thus there will be
> no higher bandwidth available for NRT traffic. I wouldn't forbid the
> option to create joint NRT slots, as long as no technical reasons
> complicat this (e.g have negativ impact on RT slots). There might be
> users some day who could need it.
>

Actually the real constraint was that the way that the NRT maps back and
forth to slot 0 means that a fair amount of extra checking has to happen to
keep that working as before.  I'll look some more and see how much extra
complication is involved. You're right though, this could be used to provide
extra NRT bandwidth. I hadn't thought of that. 
 
> But I think there is some other constraint: all slots to be coupled
> should have the same size. Otherwise it would be tricky to return the
> slot group's MTU to higher layers and to deal with packets not fitting
> into some of the slots.
> 

Yes, this is another check that should be applied.  If the slot size of a
joining slot is not the same as that of the reference, then the join is
aborted and the ioctl call fails.  

>> 4) Modify the tdma_slot by changing the 'queue' member to be a pointer to
a
>> rtskb_prio_queue and add an additional actual rtskb_prio_queue called
>> myqueue.
>> 
>> 5) By default, slot->queue just points to &slot->myqueue.  
>> 
>> 6) The act of joining is achieved by changing slot->queue to point to
>> another pre-existing slot's myqueue member.  
>> 
>> 7) the rest of the tdma_slot structs for the two joint slots are not
>> identical because this is where things like offset, period and phasing
info
>> are kept and those are different for the two slots.  Only the
>> rtskb_prio_queue is common between them.  Note that I didn't really
>> appreciate this until I looked closely at the NRT example.  There things
are
>> different because there never really is a slot 1 for the default case but
>> here we want the slots to really exist, we just want them to use the same
>> message queue.
>> 
>> 8) If you remove a slot which is jointed to another slot but you're not
the
>> reference, then you just delete normally.  But if others have queue
pointer
>> pointing to your myqueue object then all those slots have their queue's
>> redirected to their own myqueue objects.  Obviously, care is taken that
this
>> is done when ref_count is 0 so we don't corrupt a loop in progress.
>> 
>> 9) The only other impact is a few function calls which currently have
>> &slot->queue which need to be changed to slot->queue since it's a pointer
>> already.
>> 
>> As is typical, I've got several other high priority projects going at
once
>> so I suspect I won't have this tested and ready for a week or so.
>> 
> 
> This all sounds very reasonible and feasible to me. And you don't have
> to hurry with your patch, the next RTnet release will still take some
> time (among other aspects, it depends on fusion's 0.9 release and a
> potential classic port).
> 
> Jan
>