Re: [RTnet-developers] Joint Slots patch

[Jan K. <ki...@rt...>]

Vareka, Bill wrote:
> Here is a patch to add the option of joint slots. I have not had a chance to
> fully test this but the changes are fairly confined so this should be good.
>

Great work, and also very well described. Thanks for your contribution!

> The basic idea is that you define multiple slots but all but the first are
> defined as 'joined' to the first one.  Then when you write via the socket,
> the data goes to a common slot buffer and is sent in the next assigned slot.
> This can be used to significantly reduce latencies without requiring very
> short cycle periods.
>
> The changes are:
> 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.  Also, the mtu's of both
> the slot your joining and your own slot must be the same.
>
> 2) The tdma_config struct adds an additional int field called jointslot to
> the set_slot union.  A value between 0 and MaxSlots indicates a
> desire to be coupled.  Default is -1 (no coupling).
>
> 3) 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.
>
> 4) By default, slot->queue just points to &slot->myqueue.
>
> 5) The act of joining is achieved by changing slot->queue to point to
> another pre-existing slot's myqueue member.
>
> 6) 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.
>
> 7) 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.
>
> 8) The only other impact is a few function calls which currently have
> &slot->queue which needed to be changed to slot->queue since it's a pointer
> already.

Looks good. On the first glace I had some concerns regarding the loops
over all slots under spinlock to find potential mates (even when there
are none), but I see no other simple solution so far. Will try to think
about it further, though.

>
> 9) An unrelated bug was addressed, in the original tdma_ioctl.c file on line
> 474 the original code had
>         while ((rtskb = __rtskb_prio_dequeue(&slot->queue)))
> but I believe the correct call should have been
>         while ((rtskb = __rtskb_prio_dequeue(&old_slot->queue)))
> I've incorporated that into this patch as well but it is really independent
> of the joint-slots changes.

Oh, yes, good spot. Looks like some real cleanup bug...

>
> Unlike what I stated in an earlier post, this no longer treats the NRT slot
> any different from the others, thus you can also join to it if you want.
>

Ok, I have some code refactoring still pending on my box which I would
like to finish and check in first, but then it will be your patch's
turn. Should definitely make it into SVN for the next release!

Jan