----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3753/#review9243 -----------------------------------------------------------
src/mem/ruby/network/garnet2.0/NetworkInterface.cc (line 150) <http://reviews.gem5.org/r/3753/#comment7919> Hey Matt, There is a minor change I have been wanting to push in which you can add as part of this patch: We count network_delay as dequeue_time - enqueue_time. A minor issue is that the "enqueue_time" includes an additional cycle at the source NIC when the packet was created. For example: Suppose we have a 1-flit packet that we have to send one hop from Node 0 to Node 1. We create in Cycle 1. Cycle 1: flit enqueued by NIC 0 Cycle 2: flit in link_NIC0-Router0 Cycle 3: flit in Router 0 Cycle 4: flit in link_Router0-Router1 Cycle 5: flit in Router 1 Cycle 6: flit in link_Router1-NIC1 Cycle 7: flit dequeued by NIC 1. Network delay will be calculated as 7-1 = 6 cycles. But the actual "network" delay was 5 cycles (cycle 2 to cycle 6). The additional 1-cycle in NIC0 is going to be part of the src_queueing_delay so it is being accounted for. Does this make sense? If yes, can you update network delay to dequeue_time - enqueue_time - 1 ? And then ship it. Thanks, Tushar - Tushar Krishna On Jan. 6, 2017, 11:59 p.m., Matthew Poremba wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3753/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2017, 11:59 p.m.) > > > Review request for Default and Tushar Krishna. > > > Repository: gem5 > > > Description > ------- > > Changeset 11792:66b31157514e > --------------------------- > ruby: Check MessageBuffer space in garnet NetworkInterface > > Garnet's NetworkInterface does not consider the size of MessageBuffers when > ejecting a Message from the network. Add a size check for the MessageBuffer > and only enqueue if space is available. If space is not available, the > message if placed in a queue and the credit is held. A callback from the > MessageBuffer is implemented to wake the NetworkInterface. If there are > messages in the stalled queue, they are processed first, in a FIFO manner > and if succesfully ejected, the credit is finally sent back upstream. The > maximum size of the stall queue is equal to the number of valid VNETs > with MessageBuffers attached. > > > Diffs > ----- > > src/mem/ruby/network/garnet2.0/flit.hh > c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf > src/mem/ruby/network/garnet2.0/flit.cc > c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf > src/mem/ruby/network/garnet2.0/flitBuffer.hh > c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf > src/mem/ruby/network/MessageBuffer.hh > c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf > src/mem/ruby/network/MessageBuffer.cc > c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf > src/mem/ruby/network/garnet2.0/NetworkInterface.hh > c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf > src/mem/ruby/network/garnet2.0/NetworkInterface.cc > c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf > > Diff: http://reviews.gem5.org/r/3753/diff/ > > > Testing > ------- > > > Thanks, > > Matthew Poremba > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
