----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1314/#review3137 -----------------------------------------------------------
Ship it! Ship It! - Ali Saidi On July 21, 2012, 5:10 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1314/ > ----------------------------------------------------------- > > (Updated July 21, 2012, 5:10 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9131:50fc74240e41 > --------------------------- > 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. > > > Diffs > ----- > > configs/common/FSConfig.py 2f6f0631af48 > configs/example/fs.py 2f6f0631af48 > src/mem/Bridge.py 2f6f0631af48 > src/mem/SConscript 2f6f0631af48 > src/mem/bridge.hh 2f6f0631af48 > src/mem/bridge.cc 2f6f0631af48 > tests/configs/twosys-tsunami-simple-atomic.py 2f6f0631af48 > > Diff: http://reviews.gem5.org/r/1314/diff/ > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
