mem: Make the XBar responsible for tracking response routing

This patch removes the need for a source and destination field in the
packet by shifting the onus of the tracking to the crossbar, much like
a real implementation. This change in behaviour also means we no
longer need a SenderState to remember the source/dest when ever we
have multiple crossbars in the system. Thus, the stack that was
created by the SenderState is not needed, and each crossbar locally
tracks the response routing.

The fields in the packet are still left behind as the RubyPort (which
also acts as a crossbar) does routing based on them. In the succeeding
patches the uses of the src and dest field will be removed. Combined,
these patches improve the simulation performance by roughly 2%.

1 files changed, 9 insertions, 0 deletions

diff --git a/src/mem/xbar.hh b/src/mem/xbar.hh
index 7f3c17677..6e7d7afce 100644
--- a/src/mem/xbar.hh
+++ b/src/mem/xbar.hh
@@ -54,6 +54,7 @@
 #include <deque>
 
 #include "base/addr_range_map.hh"
+#include "base/hashmap.hh"
 #include "base/types.hh"
 #include "mem/mem_object.hh"
 #include "params/BaseXBar.hh"
@@ -247,6 +248,14 @@ class BaseXBar : public MemObject
 
     AddrRangeMap<PortID> portMap;
 
+    /**
+     * Remember where request packets came from so that we can route
+     * responses to the appropriate port. This relies on the fact that
+     * the underlying Request pointer inside the Packet stays
+     * constant.
+     */
+    m5::unordered_map<RequestPtr, PortID> routeTo;
+
     /** all contigous ranges seen by this crossbar */
     AddrRangeList xbarRanges;