----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3356/#review8192 -----------------------------------------------------------
Hi Matt. Finally getting back to this. Thanks for posting it, so we can see your aims. After looking through this patch, I'm worried that this patch is trying to do too much. Specifically, it adds two features: (1) adding finite buffering with ACK/NACK flow control from Ruby to memory controllers, and (2) adding flexibility to change the flow control to memory controllers. I think we should be splitting these out into separate patches; I'm fully on-board with the intent of (1), but I'd like to be able to review (2) separately, because it raises some more interesting questions (such as extensible use of flow control with the various ports). I don't think we should hold up (1) to discuss flow control. - Joel Hestness On Feb. 29, 2016, 6:50 p.m., Matthew Poremba wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3356/ > ----------------------------------------------------------- > > (Updated Feb. 29, 2016, 6:50 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11356:2c8bd12f84a2 > --------------------------- > mem: Implement alternative flow control between MemObject ports > > The default gem5 behavior for flow control between MemObjects is to use retry > (ACK/NACK) based approach where the slave MemObject typically handles flow > control from the master(s). This provides an API that may be connected to > MemObject's ports to handle flow control in a more generic, less instrusive > manner. As an example, a token-based flow control is implemented where the > master handles situations where the slave can not accept any more requests. > Tokens are split by simplistically dividing tokens privately among masters. > In this approach, nearly all flow control tracking is handle by the flow > control delegate rather than slave MemObject. This allows us to implement > a common interface to handle, for example, QoS between MemObjects without > major modificaitons to individual MemObjects. > > Currently the default is to use no flow control and fallback to the default > retry mechanisms in gem5. Flow control capability may be added by specifying > either master_flow_control or slave_flow_control in Python configuration > scripts when the MemObject is instantiated. > > > Diffs > ----- > > src/mem/MemObject.py 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/SConscript 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/dram_ctrl.cc 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/flow_control.hh PRE-CREATION > src/mem/flow_control.cc PRE-CREATION > src/mem/mem_object.hh 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/port.hh 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/port.cc 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/protocol/RubySlicc_Defines.sm > 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/ruby/slicc_interface/AbstractController.hh > 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/ruby/slicc_interface/AbstractController.cc > 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/slicc/symbols/StateMachine.py > 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/token_flow.hh PRE-CREATION > src/mem/token_flow.cc PRE-CREATION > src/python/swig/pyobject.cc 31c5786945b447b372c3b7d346aea8fa6208577c > src/mem/FlowControl.py PRE-CREATION > > Diff: http://reviews.gem5.org/r/3356/diff/ > > > Testing > ------- > > > Thanks, > > Matthew Poremba > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
