Why "It is OK to receive RequestStatus_Aliased, it can be considered Issued" in Sequencer::makeRequest(PacketPtr pkt)?

[ImagineBoom]

Question: Why RequestStatus_Aliased can be considered as issued? If so how the next same address request is handled?

This is the code that confuses me, I don't know how the second request with the same address will be resent or where it will be blocked.

step1. insertRequest():
If a second request has the same address with one of outstanding requests, it's just put into the m_RequestTable, then return RequestStatus_Aliased

the code at src/mem/ruby/system/Sequencer.cc Sequencer::insertRequest(...)

    if (seq_req_list.size() > 1) {
        return RequestStatus_Aliased;
    }
    m_outstandReqHist.sample(m_outstanding_count);
    return RequestStatus_Ready;

step2. check status
the status is RequestStatus_Aliased so it can only return RequestStatus_Issued

the code at src/mem/ruby/system/Sequencer.cc Sequencer::makeRequest(PacketPtr pkt)

    RequestStatus status = insertRequest(pkt, primary_type, secondary_type);
    // It is OK to receive RequestStatus_Aliased, it can be considered Issued
    if (status != RequestStatus_Ready && status != RequestStatus_Aliased)
        return status;
    // non-aliased with any existing request in the request table, just issue
    // to the cache
    if (status != RequestStatus_Aliased)
        issueRequest(pkt, secondary_type);
    return RequestStatus_Issued;

step3. use status for judge if retry
the return status is RequestStatus_Issued so in recvTimingReq(..) just return true and not process the followed retry codes.

the code at src/mem/ruby/system/RubyPort.cc RubyPort::MemResponsePort::recvTimingReq(PacketPtr pkt)

    // Submit the ruby request
    RequestStatus requestStatus = owner.makeRequest(pkt);

    // If the request successfully issued then we should return true.
    // Otherwise, we need to tell the port to retry at a later point
    // and return false.
    if (requestStatus == RequestStatus_Issued) {
        DPRINTF(RubyPort, "Request %s 0x%x issued\n", pkt->cmdString(),
                pkt->getAddr());
        return true;
    }

[OdnetninI]

As you mention, when a request aliases with a previous address, the request is inserted in the m_RequestTable.

When the request callbacks from the cache, it completes all the pending requests.
You can check an example at Sequencer::readCallback

auto &seq_req_list = m_RequestTable[address];
while (!seq_req_list.empty()) {
        ....
        seq_req_list.pop_front();
}

Regarding the issueRequest, it forwards the request from the sequencer to the caches and the coherence protocol.
In the case you mention, the request for that address was already sent to the cache, so there is no need of sending it again.

Therefore, there is no retry. Let me show you a summary of the example you mention:

1. CPU Requests address 0xABCD (Request A)
2. Address 0xABCD reaches the sequencer
3. The request is not aliased -> Sent to Cache
4. CPU Request address 0xABCD again (Request B)
5. Address 0xABCD reaches the sequencer
6. The request is aliased -> add the request to the request table
7. Wait ...
8. The cache brings back the cacheline with the desired permissions for Request A
9. The cache executes read/write Callback
10. The sequencer notices the callback
11. The sequencer process Request A
12. The sequencer finds also Request B in the m_RequestTable.
13. The sequencer process Request B
14. There are no more requests
15. CPU notices the completion of Requests A and B

With this scheme, Aliased can be considered as Issued because from the point of view of the CPU, it is issued, no retry is needed.

Please take into account that there are more details to take into account.
Some requests require sending another request to cache.
Check the callback functions of the Sequencer.cc.

I hope it helps :)