Before I try to get a better understanding of the code, can you explain what's

the purpose of multi_etherlink object?  Can you provide an actual entity this

object is trying to emulate?

There are several style issues. The writer should read gem5.org/Coding_Style.

I am still trying to understand all the synchronization code.  So it will take

me sometime before I am able to review that code.

src/dev/etherpkt.hh (Diff revision 3)

store not strore in these two lines.

Show all issues

src/dev/multi_etherlink.hh (Diff revision 3)

double?  The simulator does not understand fractional ticks.

Show all issues

1. Curtis Dunham June 24, 2015, 5 p.m. (June 24, 2015, 5 p.m.)

   We understand the concern, but we just multiple this number by a packet's size to compute the number of ticks it will take to send.  Since we round that number up to the next tick, we don't see any problem here.  The double allows us to nicely handle arbitrary link bandwidths.

src/dev/multi_etherlink.hh (Diff revision 3)

Please don't call it rate.  In abstraction ticks per byte is also a rate, but I think the general meaning for rate is something amount of work carried out per unit time.  You probably want to work with the bandwidth of the link.

Show all issues

1. Curtis Dunham June 24, 2015, 5 p.m. (June 24, 2015, 5 p.m.)

   The live range of this variable is just two lines, but nonetheless I changed it to "invBW" since it is essentially an inverse bandwidth, time over data rather than data over time.

src/dev/multi_etherlink.cc (Diff revision 3)

I think there is some confusion between what the python parameter represents and what the C++ code expects for this ticksPerByte variable.

Show all issues

1. Curtis Dunham June 24, 2015, 5 p.m. (June 24, 2015, 5 p.m.)

   The definition of NetworkBandwidth in src/python/m5/params.py explains this oddness.  It starts in the standard bits-per-second unit scheme, but in the getValue() method it gets flipped upside down to ticks per byte.  So in fact this oddness dates back to 2007 when Nate Binkert introduced these definitions.  Since what you typically want to do (which is what this code does) is multiply the number of bytes you have by some constant to get the transmission time in ticks, it works rather nicely.

src/dev/multi_etherlink.cc (Diff revision 3)

If the checkpoint patch from Andreas Sandberg goes in first, you would need to fix the serialize functions.

1. Curtis Dunham June 24, 2015, 5 p.m. (June 24, 2015, 5 p.m.)

   Yes. We have code internally that makes these adjustments and we'll be sure to apply it if that is the eventual patch ordering.

src/dev/multi_iface.cc (Diff revision 3)

indentation is of.

Show all issues

util/multi/gem5-multi.sh (Diff revision 3)

number not naumber.

Firstly, thanks for this patch, this is really nice work.
I have only done a cursory review of this patch so I'm still looking over the code in more detail, but I thought I'd share some of my initial thoughts to get the conversation going on this since it seems to have stagnated.
Reiterating Nilay's point: there are a lot of style issues that need to be fixed.
It seems like this would be useful for large-scale systems, but could you give some idea how easily one could derive from the multi link/iface objects for use with a multi-threaded aproach, thereby avoiding socket-based communication? E.g., if I wanted to model small/medium scale distributed systems consisting of ~10s of nodes on a single host machine. It would be nice if multi-gem5 and a multi-threaded approached were unified and built off the same base classes.
For the TCP server, have you thought about an event-based approach, i.e., libevent or libev as opposed to using poll()?

Ship It!