GitLab

same var name used for the "sequencing" macros

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.

NOTES:
- torus does not use it, as it has some routing logic preventing direct usage.
  It probably can be done, but I'll leave that for later.
- collectives in torus, dragonfly don't use it yet.

- 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.

- "modelnet" parameter in cfg is now a no-op
- "modelnet_order" parameter in cfg is required,
  listing order in which networks are indexed to
  the model
- modified "model_net_set_params" signature
- updated tests to use the new interface

Adding collective modeling functions in model-net (currently only dragonfly/torus models support it)

- NOTE: the current scheduling policy of FCFS is hard-coded, this will change
  in future revisions
- NOTE: random number generation has changed due to the differences in
  scheduling and packet ordering. Hence, results may be slightly different from
  runs prior to this commit

- pull itself not yet tested

minor changes to model-net plug-in: (1) making the torus network's chunk size configurable (2) handling some edge cases which we haven't encountered so far but its good to have them for future

also misc update to how loggp method plugs into modelnet

- just a copy of simplenet with variables and functions renamed for now

Adding statistics collection using lp-io in model-net API (comes from the simple-net stats collection), works for simple-net, torus and the dragonfly network models (updating comments)

Adding statistics collection using lp-io in model-net API (comes from the simple-net stats collection), works for simple-net, torus and the dragonfly network models

Adding dragonfly network model with codes, model-net-test case run time parameters are updated (see README_MN_TEST.txt for details)

Updates to modelnet torus plugin: reporting torus average+maximum latency and hops traversed via model-net API function

Adding the torus network plugin with modelnet API, see model-net/README_MN_TEST.txt for instructions to run the test

Updates to model-net test program based on the new config file format. We can now configure all network parameters from the config file