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]<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] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
