OK, I see... so basically the Target::FromCPU part of the test is redundant, since there's no way a non-response packet can get into an mshr without being marked as FromCPU, and it would be more descriptive just to call it isNoResponse(). I think the current naming is just an artifact of the historical development of the code.
If I get a chance I'll make that change. Thanks for pointing it out. Steve On Wed, Dec 8, 2010 at 12:22 AM, Jeroen DR <[email protected]<voetsjoeba%[email protected]> > wrote: > 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]<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 > [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
