Bridge: Remove NACKs in the bridge and unify with packet queue
Review Request #1314 - Created July 20, 2012 and submitted
| Information | |
|---|---|
| Andreas Hansson | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
Changeset 9156:e3ef41440197 --------------------------- Bridge: Remove NACKs in the bridge and unify with packet queue This patch removes the NACKing in the bridge, as the split request/response busses now ensure that protocol deadlocks do not occur, i.e. the message-dependency chain is broken by always allowing responses to make progress without being stalled by requests. The NACKs had limited support in the system with most components ignoring their use (with a suitable call to panic), and as the NACKs are no longer needed to avoid protocol deadlocks, the cleanest way is to simply remove them. The bridge is the starting point as this is the only place where the NACKs are created. A follow-up patch will remove the code that deals with NACKs in the endpoints, e.g. the X86 table walker and DMA port. Ultimately the type of packet can be complete removed (until someone sees a need for modelling more complex protocols, which can now be done in parts of the system since the port and interface is split). As a consequence of the NACK removal, the bridge now has to send a retry to a master if the request or response queue was full on the first attempt. This change also makes the bridge ports very similar to QueuedPorts, and a later patch will change the bridge to use these. A first step in this direction is taken by aligning the name of the member functions, as done by this patch. A bit of tidying up has also been done as part of the simplifications. Surprisingly, this patch has no impact on any of the regressions. Hence, there was never any NACKs issued. In a follow-up patch I would suggest changing the size of the bridge buffers set in FSConfig.py to also test the situation where the bridge fills up.
util/regress all passing (disregarding t1000 and eio)
Issue Summary
1
1
0
0
| Description | From | Last Updated | Status |
|---|---|---|---|
| So if sendTimingReq() fails, we'll just implicitly try again when we get the retry callback, right? And the inRetry flag ... | Steve Reinhardt | Aug. 6, 2012, 12:32 p.m. | Open |
Ship It!
Other than maybe documenting the retry situation a little more, this looks good to me.
-
src/mem/bridge.cc (Diff revision 1) -
So if sendTimingReq() fails, we'll just implicitly try again when we get the retry callback, right? And the inRetry flag was redundant all along, because if we have packets in the queue but don't have a sendEvent scheduled, then we must be waiting for a retry? It all makes sense, but probably calls for a comment somewhere... let me know if you have one somewhere else and I just missed it.
Review request changed
Updated (Aug. 6, 2012, 8:49 p.m.)
Description: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Diff: |
Revision 2 (+195 -267) |
