GitLab

Adding sampling examples in synthetic workload test program, fixing a reverse handler bug in synthetic workload test

Torus model revision: adding bubble flow control for deadlock prevention and updated congestion control

Changing the hash function to bj_hash_little2, more additions to the MPI Sim layer operation matching

NOTE: caused an event size bump - you may need to update config files

Updated congestion control in dragonfly: now messages are saved in a waiting list at the routers in case of buffer overflows

Adding group level mapping in the dragonfly: multiple routers can now be specified in the config file

Adding further updates to the dragonfly routing (statistics for adaptive routing updated, conditions for queue congestion sensing updated)

1) Adding dragonfly adaptive and prog-adaptive routing algorithms--- still testing with more workloads and crosschecking the computation 2) Two bug fixes in credit-based flow control

Tired of explaining that it's not a good representation of a WAN. Instead, it's
now a simple point-to-point latency/bandwidth model.

Rather than model-net LPs directly sending messages to other model-net LPs, LPs
can route the intended message through the scheduler interface to be queued up
for reception by the receiver (see the diff of loggp.c). This has the benefit of
    enabling things like priority and fairness for N->1 communication patterns.
    Currently, no packetizing is supported, and I haven't yet wrote checks for
    it - beware.

Loggp is currently the only supported model. simplenet could also be supported
without much trouble, but I doubt there's any demand for it at the moment.  This
should NOT be used by the dragonfly/torus models, as they have their own routing
backend.

Torus and simplewan each have problems precluding them from the current
scheduling fix:
- simplewan - each "device" has N input/output ports. It can't simply tell the
  scheduler when they are (it is?) idle because the scheduler doesn't know which
  packets go to which ports
- torus - also has N input/output ports (two for each dimension). Also, the same
  routing "queue" (via the "next_link_available_time" var) is used for incoming
  and outgoing messages, so we can't guarantee the scheduler that we'll be
  available at time x (an incoming msg could arrive and then be routed at time
  x-1). This isn't a problem for the dragonfly network as terminals aren't
  intermediate routers. Ideally what needs to happen here is for the
  intermediate packets/chunks to be queued up in the scheduler.

- N priorities processed in increasing order
- queue for priority i not touched until 0...i-1 queues are empty
- example injection API usage shown in test program
  - currently, only the priority scheduler has need of it

All configuration now proceeds on a per-LP level, and requires separate
registration and configuration calls, as seen in the test programs.
model_net_set_params is no longer used, and is replaced by model_net_register
and model_net_configure. The dragonfly network, having two LP types bundled in
the same code-path, is special-cased in the registration code.

LP-mapping in model-net now has the following defaults:
- counts via codes_mapping_get_lp_count are now with respect to the calling
  network LP's annotation.
- when looking up network LPs via
  codes_mapping_get_lp_info/codes_mapping_get_lp_id, the annotation of the
  calling network LP is used. Hence, routing now occurs only between LPs of the
  same annotation. If the destination LP's group specified by model_net_*event
  does not contain a modelnet LP with the same annotation as the modelnet LP in
  the sender's group, then an error will occur (in codes_mapping).

Known Issues:
- modelnet users currently cannot specify which modelnet LP to use in the case
  of multiple modelnet LPs in the sender's group. This will be fixed in future
  commits after a consensus is reached on the best way to expose this
  information.