Input / Output device loopback

[rowleya]

It would be nice to be able to connect a device back to itself if it supports both input and output. I believe that the tools will currently fail to add a route (or rather add a route to a virtual chip).

[alan-stokes]

yes and no. if you want to do that as the only thing. we have the reflector code that puts a router entry on the 2 spinnaker link real chips. this can be found here: https://github.com/SpiNNakerManchester/spinn_link_reflector

if its within another setup, then we'd need to look at special support for it. Which i'm hestinent to do unless we have no other option. special cases cuases issues later down line.

[rowleya]

I suspect this covers it - it should be relatively easy (if source == virtual and dest == virtual, and source == dest, add a reflector entry to the routing table of the real connected chip).

The issue is that it is easy to write a script that attempts to do this and will result in SpiNNaker traffic running around the machine, as the router will put a routing entry on the virtual chip at present.

[alan-stokes]

the reflector does exactly this replaces the router table generation with one that hardcodes the routers to reflect all packets back down the spinnaker links. id really try to avoid giving the ability to add random entries around the place, the potential for chasos being rather high there. anything else id like to know the exact use case, and see if theres another way we can do it.

[rowleya]

The use case is that a user has a device that both sends and receives packets and is connected to a SpiNNakerLink. The user calls p.external_devices.activate_live_output_to(device, device). The simulation goes haywire because it fails to add a routing entry to a real router.

Note that it really is that easy to break a simulation at present. The user shouldn't have to know that this will break it...

[alan-stokes]

right, but that is the action of the usecase, not the desire behind it. the reflector allows you to test it. which is what i believe that use-case is. We could put a safety check for both source and destination not being on the same virtual chip to stop it from getting to mapping.

to support this within a pynn script with other networks as well, does put us in a nasty situation, but it begs the question again why you want to stream back what you've sent in. your sending it in, so you've already got the data........... that use case sounds like its a pathological use case, to which id go tuff. You cant expect to have everything and thats just so annoying to put in. special case functionality will bite us later down line.

[dkfellows]

Either done enough or won't be done.