Review Board 2.0.15


mem: Make the XBar responsible for tracking response routing

Review Request #2310 - Created July 7, 2014 and submitted

Information
Tony Gutierrez
gem5
default
Reviewers
Default 
Changeset 10645:1e1e3186ade3
---------------------------
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%.

regressions now pass
Review request changed
Updated (Jan. 5, 2015, 8:31 a.m.)

Summary:
-base: fix operator== for comparing EthAddr objects
+mem: Make the XBar responsible for tracking response routing

Description:
~  

Changeset 10252:4ef536dde28a

  ~

Changeset 10645:1e1e3186ade3

   
~  

base: fix operator== for comparing EthAddr objects

  ~

mem: Make the XBar responsible for tracking response routing

   
~  

this operator uses memcmp() to detect if two EthAddr object have the same

~   address, however memcmp() will return 0 if all bytes are equal. operator==
~   returns the return value of memcmp() to indicate whether or not two
~   address are equal. this is incorrect as it will always give the opposite of
~   the intended behavior. this patch fixes that problem.

  ~

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%.

Diff:

Revision 2 (+108 -73)

Show changes

src/mem/coherent_xbar.hh
src/mem/coherent_xbar.cc
src/mem/noncoherent_xbar.cc
src/mem/xbar.hh
Andreas Hansson
Posted (Jan. 5, 2015, 8:32 a.m.)
My bad, wrong review :-)