mem: Implement alternative flow control between MemObject ports
Review Request #3356 - Created Feb. 29, 2016 and updated
| Information | |
|---|---|
| Matthew Poremba | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
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.
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.