Function caminos_lib::topology::new_topology

pub fn new_topology(arg: TopologyBuilderArgument<'_>) -> Box<dyn Topology>

Build a topology. All topologies should admit an optional legend_name to be used in plots.

Cartesian topologies

Mesh example: a bidimensional mesh of side 16. Routers in the periphery has less degree, defined as un-connected ports.

Mesh{
	sides: [16,16],
	servers_per_router:1,
	legend_name: "A 16x16 mesh network",
}

Torus example

A bidimenstional torus of side 16. All routers have degree 4. Plus another port to connect to the server.

Torus{
	sides: [16,16],
	servers_per_router:1,
	legend_name: "A 16x16 torus network",
}

Hamming example

A bidimensional Hamming graph isomorphic to the Cartesian product of two Complete graph of 16 vertices. Also known as HyperX or flattened butterfly topology. Has degree 2*(16-1)=30. It is recommended to use a number of servers per router close to the side value, because of its low average distance.

Hamming{
	sides: [16,16],
	servers_per_router:16,
	legend_name: "A 16x16 Hamming network",
}

Topologies given by lists of neighbours.

Random regular graph example

A random regular can be built when at least one of degree or routers is an even number. A useful formula is degree^k=2routers*ln(routers), where the exponent k is close to the average distance. For large enough numbers ceil(k) should be the diameter. To have enough population severs_per_router should be a little below the quotient degree/average_distance, as some little throughput is wasted by the non-uniforme use of the links.

RandomRegularGraph{
	routers: 500,
	degree: 20,
	servers_per_router: 8,
	legend_name: "A random 20-regular graph of 500 routers",
}

File example

A file can be load as topology. This can be useful to keep a specific random graph without need to care about using the same RNG seed. It can also be used to simulate topologies generated by other software.

File{
	filename: "/path/to/my/topology/file",
	format: 0,//TODO: this needs documentation...
	servers_per_router: 5,
	legend_name: "some network in the device",
}

Dragonfly networks.

The global_ports_per_router was denotated h in their original article. It is only included the case with groups of size a=2h and g=ah+1 groups. The number of servers per router can be varied, but recommended to the same value as global_ports_per_router. Only the palm-tree arrangment of global links is currently supported.

CanonicDragonfly{
	global_ports_per_router: 4,
	servers_per_router: 4,
	legend_name: "h=4 dragonfly with palm-tree global arrangement",
}

Networks built over finite fields. Only prime fields are currently supported.

LeviProjective.

This topology is the Levi graph of the projective plane over a finite field. Both lines and points of the projective plane become vertices, that is, routers. Has average distance around 2.5, diameter 3 and girth 6. The finite field is of order prime, that should be a prime number. Powers are not yet supported. The topology degree is the prime plus one. Called projective networks in “Projective Networks: Topologies for Large Parallel Computer Systems” by C. Camarero et al.

LeviProjective{
	prime: 19,
	servers_per_router: 8,
	legend_name: "Levi-projective network over q=19",
}

Projective.

This is the quotient of the LeviProjective over a polarity: a bijection between points and lines that maintains incidence. It is also known as Brown graph or Erdös–Renyí graph. The degree is again prime+1, except in the fixed points which became loops. These loops are removed from the network, becoming non-conected ports. Has diameter 2, average distance a little below and girth 5. Called demi-projective networks in “Projective Networks: Topologies for Large Parallel Computer Systems” by C. Camarero et al.

Projective{
	prime: 19,
	servers_per_router: 10,
	legend_name: "demi-projective network over q=19",
}

SlimFly.

This is the MMS (Mirka–Miller–Siran) graph. For prime=5 it is the Hogffman–Singleton graph. Has Paley graphs as subgraph, or similar depending on whether the prime is congruent to what modulo 4. has diameter 2. Note the links in the (quasi)-Paley graph (which we can call local links) are used in a slightly different amount to the other links. This slightly reduces the delivered throughput.

SlimFly{
	prime: 19,
	//primitive: 2,//optional value, should actually be a primitive number. Should be better to let it be calculated.
	servers_per_router:9,
	legend_name: "Slimfly MMS over q=19",
}

Multi-stage networks.

In a multi-stage network routers are grouped by levels, which the routers within a level connecting only to routers of the preceding and the next levels. Routers at level 0 (the first level) are called leaf routers and they are the ones connected servers. We call stages to the connections from a level to the next. The number of stages is called height and it is one less than the number of levels. The levels hence range from 0 up to height (both inclusive).

Generic MultiStage

MultiStage{
	stages:[
		Fat { bottom_factor:4, top_factor:4 },
		Fat { bottom_factor:8, top_factor:4 },
	],
	servers_per_leaf: 4,
	legend_name: "a fat-tree defined using stages"
}

XGFT

An eXtended Generalized Fat-Tree, see “On Generalized Fat Trees” by S. R. Öhring et al.

XGFT{
	height: 3,
	down: [4,4,8],
	up: [4,4,4],
	servers_per_leaf: 4,
	legend_name: "XGFT(3;4,4,8;4,4,4)",
}

OFT

Orthogonal Fat-Tree, see “Recursively Scalable Fat-Trees as Interconnection Networks” by M. Valerio et al. Uses the construction shown in “Projective Networks: Topologies for Large Parallel Computer Systems” by C. Camarero et al. For the moment only implemented for projective planes over prime finite fields, excluding higher powers.

The optional parameter double_topmost_level (default to true) indicates whether the bottom of the last stage should be doubled, as using all ports in the topmost routers for downwards connections.

OFT{
	height: 2,
	prime: 3,
	servers_per_leaf: 4,
	//double_topmost_level: false,//optional parameter
	legend_name: "OFT over the projective plane of 3 points",
}

RFC

Random Folded Clos. See “Random Folded Clos Topologies for Datacenter Networks” by C. Camarero et al.

RFC{
	height: 3,
	down: [10,10,20],
	up: [10,10,10],
	sizes: [80,80,80,40],
	servers_per_leaf: 4,
	legend_name: "RGC of radix 20 with 80 leaf routers",
}