mem: Split port retry for all different packet classes
Review Request #2646 - Created Feb. 7, 2015 and submitted
| Information | |
|---|---|
| Andreas Hansson | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
Changeset 10705:1fec273b2946 --------------------------- mem: Split port retry for all different packet classes This patch fixes a long-standing isue with the port flow control. Before this patch the retry mechanism was shared between all different packet classes. As a result, a snoop response could get stuck behind a request waiting for a retry, even if the send/recv functions were split. This caused message-dependent deadlocks in stress-test scenarios. The patch splits the retry into one per packet (message) class. Thus, sendTimingReq has a corresponding recvReqRetry, sendTimingResp has recvRespRetry etc. Most of the changes to the code involve simply clarifying what type of request a specific object was accepting. The biggest change in functionality is in the cache downstream packet queue, facing the memory. This queue was shared by requests and snoop responses, and it is now split into two queues, each with their own flow control, but the same physical MasterPort. These changes fixes the previously seen deadlocks.
Posted (Feb. 7, 2015, 10:14 a.m.)
Awesome! This lack of separate channels for requests & responses has bugged me for years, I'm really glad to see it addressed.
One minor suggestion: to me, terms like recvRetryReq and recvRetryResp seem backward, since 'retry' is the noun and 'req'/'resp' are adjectives. So in isolation, recvReqRetry makes more sense, because I'm receiving a retry that's specific to requests (i.e., a request-flavored retry), not receiving a request for a retry (as recvRetryReq implies). On the other hand, I can see how there is some parallelism between sendTimingReq and recvRetryReq. But to me the readability in context trumps the parallelism in the abstract (which you only see in places like the commit message where the function names are juxtaposed).
Just to overcome the effort hurdle, I think this issue can be fixed with:
perl -pi -e 's/([Rr])(etry)R(eq|esp)/$1$3R$2/'
Review request changed
Updated (Feb. 8, 2015, 9:48 a.m.)
Description: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Diff: |
Revision 2 (+562 -390) |
Thanks!