Hi Steve,
Thanks for clarifying. I understand the different forward/response
combinations; I think the cause of my confusion was that technically
mshr->isForwardNoResponse() seems to be more of a fromCpuNoResponse():
bool isForwardNoResponse() const
{
if (getNumTargets() != 1) return false;
Target *tgt = getTarget();
return tgt->source == Target::FromCPU && !tgt->pkt->needsResponse();
}
and as such encompasses both the R=N cases (since if I recall, locally
generated writebacks also get marked FromCPU). So then, I suppose
isForwardNoResponse() would be used to identify those cases in which no
response is expected and the MSHR can be recycled after a succesful send
(as you've indicated), which indeed leaves isForward to differentiate
between cases 2 and 4 based on the F column.
Ok, I think I got it. Thanks!
-- Jeroen
Yea, you've got most of it there... I think the key detail you might
be missing is that forwarded packets and non-response packets are
closely related but not quite the same thing. It's quite possible
that the usage of isForward and isForwardNoResponse() is confusing the
issue, so forget about those for a moment. Conceptually, a forwarded
request is one that isn't interacting with the cache, it's just
basically passing through from the cpu-side port to the mem-side
port. Obviously a non-response packet is one that's not expecting a
response. Any combination of these two is possible.
F R Example
N N Locally generated writeback
N Y Locally generated fill (due to a read or write coming in from
the CPU side that misses)
Y N Some writeback misses from upper level (say L1 writeback that
misses in the L2)*
Y Y Uncacheable memory or device access from CPU
*I believe the forward non-response case is pretty rare... once upon a
time writebacks that came in through the CPU port and missed in the
cache were always just forwarded on to the next level, but that has
some performance issues, so now they are written into the cache even
if they miss, and the only case where they would get forwarded is if
for some reason a new block could not be allocated.
You're right that the mshr->isForward flag is only useful in the last
case above, since if we don't expect a response, we won't hold on to
the mshr after the request is issued, so remembering that it was a
forward is moot. So that flag really is just used to distinguish case
2 from case 4.
Hope that helps...
Steve
On Tue, Dec 7, 2010 at 8:06 PM, Jeroen DR <[email protected]
<mailto:voetsjoeba%[email protected]>> wrote:
Hi,
Just a quick check to see if I got this right. I know that if a
missed request does not need a response, then the downstream
packet that is sent out to service it will be the original request
as it came in; or at least, for missed requests that came in from
the CPU-side. In getTimingPacket(), this corresponds to the
mshr->isForwardNoResponse() check.
Otherwise, getBusPacket is called to create a downstream packet of
the appropriate command type based on the original packet. This
method may still return NULL if the original packet does not
require a response. In this case, getTimingPacket notices this yet
still sends out a newly created packet and marks mshr->isForward
which is then checked by handleFill. Evidently this would be the
case for no-response packets that didn't originate from the CPU.
I just wanted to confirm that the reason why mshr->isForward isn't
set for no-response packets originating from the CPU is because
isForwardNoResponse()-MSHRs get recycled immediately after their
downstream request is sent (by virtue of MSHR::markInService)
which would effectively kill the isForward flag. Other sources
maintain their MSHR, allowing us to check for the flag afterwards.
It was just a little confusing to see one case where the
MSHR->isForward flag gets set before sending out a no-response
packet, while the other case it doesn't get set (even though it's
clearly also a no-response packet).
I was also hoping someone could describe a small scenario in which
the isForward flag is used, because I'm having a little trouble
seeing where these snoop-side no-response MSHR requests fit in. As
far as I can tell it's only used in handleFill to see if it has
stuff to fill (i.e. if it should expect to find a response in the
packet).
Cheers,
-- Jeroen
_______________________________________________
m5-users mailing list
[email protected] <mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
