Question: what is the use of the request table on this slide?
jazzbass
@kayvonf Currently, we have split transactions. We have request transactions and response transactions.
The function of the request table is to keep track of requests that have not received responses yet. We need the table to identify responses that we receive through the bus (we need to somehow associate them to a previous request), also, we need it to check for possible conflicts before we make a request (for example, issuing a BusRd while there is a pending BusRdX request to the same address). Using a simple policy, caches shouldn't make a request that conflicts with some request already in the request table, they should check the request table before making any request.
Kapteyn
Question 1:
This slide talks about assigning a tag to each request, but I don't think it's shown in the table because the tag is not the same thing as the field storing which processor issued the request.
I think the caches would need to store both a tag for each request and the processor that issued the request for at least two reasons:
1) as mentioned above, it needs to know if any requests it wishes to send conflict with another processor's outstanding request.
2) it needs to know whether or not a response coming from memory is a response for one of their own requests. In which case it should read the data from the response bus and update its cache accordingly.
Another issue is that caches need to keep their request table up to date by clearing out pending requests once they have received their responses.
All this seems to imply that caches must constantly listen to the response data/tag bus as well as the request bus in order to keep their tables up to date and to get the data they asked for when it comes over the response bus. Is that a correct assumption?
Question 2:
I believe if the cache is not designed to make 1) snooping and acknowledging a request and 2) updating its request table with that request one atomic operation, there can be a race condition.
Let's say P1 does not have line A in its cache. P1's cache snoops a BusRdx for A on the request bus and sends the ack "I don't have the line, go ahead". But before P1's cache has had a chance to update its request table P1 asks its cache for line A with the intent to read-modify. Now the cache can make one of two choices:
1) stall the request from the processor and update its request table first so that when it services P1's request, it will see that a BusRdx has already been issued for that line and will hold off on sending its own BusRdx.
2) give priority to the processor's request instead and send off a BusRdx for A, causing an error in the protocol because now we have two outstanding BusRdx for the same line.
So if the protocol is to be implemented correctly, is it correct to say that the caches have to make snooping and acknowledging a request and updating its request table with that request one atomic operation?
kayvonf
The tag is stored in the table, it's just implicit since the tag for the message is the index into the table. By definition there is no other outstanding request with the same index so the tag is unique.
Correct. The act of snooping involves updating and structures that reflect the results of the snoop.
Question: what is the use of the request table on this slide?
@kayvonf Currently, we have split transactions. We have request transactions and response transactions.
The function of the request table is to keep track of requests that have not received responses yet. We need the table to identify responses that we receive through the bus (we need to somehow associate them to a previous request), also, we need it to check for possible conflicts before we make a request (for example, issuing a BusRd while there is a pending BusRdX request to the same address). Using a simple policy, caches shouldn't make a request that conflicts with some request already in the request table, they should check the request table before making any request.
Question 1:
This slide talks about assigning a tag to each request, but I don't think it's shown in the table because the tag is not the same thing as the field storing which processor issued the request.
I think the caches would need to store both a tag for each request and the processor that issued the request for at least two reasons:
1) as mentioned above, it needs to know if any requests it wishes to send conflict with another processor's outstanding request.
2) it needs to know whether or not a response coming from memory is a response for one of their own requests. In which case it should read the data from the response bus and update its cache accordingly.
Another issue is that caches need to keep their request table up to date by clearing out pending requests once they have received their responses.
All this seems to imply that caches must constantly listen to the response data/tag bus as well as the request bus in order to keep their tables up to date and to get the data they asked for when it comes over the response bus. Is that a correct assumption?
Question 2:
I believe if the cache is not designed to make 1) snooping and acknowledging a request and 2) updating its request table with that request one atomic operation, there can be a race condition.
Let's say P1 does not have line A in its cache. P1's cache snoops a BusRdx for A on the request bus and sends the ack "I don't have the line, go ahead". But before P1's cache has had a chance to update its request table P1 asks its cache for line A with the intent to read-modify. Now the cache can make one of two choices:
1) stall the request from the processor and update its request table first so that when it services P1's request, it will see that a BusRdx has already been issued for that line and will hold off on sending its own BusRdx.
2) give priority to the processor's request instead and send off a BusRdx for A, causing an error in the protocol because now we have two outstanding BusRdx for the same line.
So if the protocol is to be implemented correctly, is it correct to say that the caches have to make snooping and acknowledging a request and updating its request table with that request one atomic operation?
The tag is stored in the table, it's just implicit since the tag for the message is the index into the table. By definition there is no other outstanding request with the same index so the tag is unique.
Correct. The act of snooping involves updating and structures that reflect the results of the snoop.