Link priority and the pause control token

[lilltroll]

I need to share one L-link between realtime I2S data and long non real-time data packages.

Link-Prio.gif

Thus, the red arrow needs realtime priority.

One way is to apply a FIFO connected to the I2S-TX thread and to the I2S-mixer thread, but it is not an absolute guarantee, and it steals 2 threads.

Another way is to send a "pause command" from the I2S-TX thread to the UDP thread over a channel and let the UDP thread fire an interrupt on that command. The interrupt sends a pause control token to the switch, making the L-Link available for a new audio transaction.
When the audio transaction has finished, a new "end command" is sent and the interrupt ends and the long data transfers thereafter continues.
This works in the simulator, but it becomes a little more complex when the UDP server is feeding many clients over several interfaces.

My question is: Can the I2S-TX thread directly tell the switch to pause, whitout telling the UDP thread , in such a way that the I2S-TX can send a short message to the I2S-mixer?

[lilltroll]

My thought is that the pause control token will change a register in the switch, but also that all threads can write and read to the switch register directly.

I do not have much of a clue what is happening inside the switch when it receives a pause token.

[segher]

The pswitch the PAUSE is sent on passes the token over the
link used for the established circuit, and frees that circuit,
so that others can use that plink; when data is sent from this
chanend again, a new circuit is established, headers are sent
again.

An sswitch that receives a PAUSE passes it on and frees the
circuit, exactly like with an END.

A pswitch that receives a PAUSE just drops it on the floor.

I don't think there is any out-of-band way (switch regs in
what you say?) to do any of this.

[lilltroll]

Thanks!

I was hoping for you to answer: Maybe you had some magic link trick in your hat to show me :)
I will implement a interrupt that fires a pause token on the active channel.

[segher]

Another way is to send a PAUSE on your big data stream every
(at most) N tokens, if you can tolerate that much latency. Simpler
code is better ;-)

[lilltroll]

Hmm, I think I have a wish-list for a new feature using interfaces in XC !

[bearcat]

I implemented a control token handler to arbitrate multiple packets thru a single link. Which control token is sent at the beginning of the packet directs the traffic to the correct routine or via a intra-tile channel end to another core.

Sending a pause token is being "depreciated" if I remember correctly, but still can be done.

Not sure if this is a help or not...

[lilltroll]

What is the drawback with the pause token? Why even bother with
TX:
while(1){
OUTCT(END)
CHKCT(END)
OUT
OUTCT(END)
CHKCT(END)
do something else
}
RX:
while(1){
CHKCT(END)
OUTCT(END)
IN
process the data
CHKCT(END)
OUTCT(END)
}

when we can do

OUTCT(END)
CHKCT(END)
while(1){
OUT
OUTCT (PAUSE)
do something else
}

CHKCT(END)
OUTCT(END)
while(1){
IN
process the data
}

[hr]
If an interface has an return value, is it transmitted as an separate transaction in the end or is the channel blocked until the return value is sent ?

[segher]

The main drawback of using PAUSE is that it is harder to
determine the maximum latency this gives for other communication
using that link. The main advantage is that that maximum
latency is lower, if you do things correctly :-)

[richard]

What is the drawback with the pause token?

The main drawback with pause tokens is packet overtaking. If you send two packets to the same destination then, whenever there are multiple possible routes to the destination, there is no guarantee the packets will be received in the same order they were sent.

Typically this is solved by adding extra synchronisation, i.e. the second packet isn't sent until after the sender has received an acknowledgement that tells it that the previous packet has been received. If you take a sequence of outputs and arbitrarily insert pause tokens between them then there won't have sufficient synchronization to ensure packets are received in order. You'll probably find that you get away with it most of the time, but it will go horribly wrong it hard to debug ways when the volume of network traffic increases.

Even if there is only a single XMOS link between a pair of nodes there are still multiple routes since there are multiple plinks (4) between the tile and switch on the node.

It is possible to safely use pause tokens (e.g. if you synchronize after every packet or if the application is tolerant to packet reordering), but you need to be careful about how you use them.