> On Jan. 10, 2017, 4:43 p.m., Tushar Krishna wrote: > > src/mem/ruby/network/garnet2.0/NetworkInterface.cc, line 150 > > <http://reviews.gem5.org/r/3753/diff/4/?file=64266#file64266line150> > > > > 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 > > Matthew Poremba wrote: > I think I follow. Just to make sure I understand, the additional cycle > comes from the source side, correct? Since flitisizeMessage places the flit > in a VC output buffer but it is not injected until the next cycle? If that's > correct, I'll fold that change into this patch.
Yes that's correct. Thanks. - Tushar ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3753/#review9243 ----------------------------------------------------------- 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
