recvAtomicLogic() in mem_ctrl.cc
On 7/11/2023 3:03 PM, John Smith wrote:
Thanks for responding, Elliot. I somewhat understand that after the write is accomplished, the
returning packet won't have the data. But still, why is the returned value 0 in that case? Shouldn't
it still be equal to the memory access latency.
In the Atomic case this code is assuming the write can
be absorbed into a write buffer, so there is no additional
latency visible to the user. Of course it is possible to
saturate the buffers, and if you want a more accurate
accounting you can use a Timing model instead.
EM
Hi Eliot,
Based on my understanding, when pkt->makeResponse() is called it updates
the "cmd" of the pkt with the appropriate responseCommand (this line of
code: cmd = cmd.responseCommand();) . If you look at
"MemCmd::commandInfo[]" in packet.cc, the response command for a
"WriteReq" command is "WriteResp". And the attributes of a "WriteResp"
command don't have "HasData", which is why the response pkt will return
false on a "hasData()" check.
You might also want to look at the struct CommandInfo in packet.hh.
-Ayaz
On Tue, Jul 11, 2023 at 2:15 PM Eliot Moss via gem5-users <
gem5-users@gem5.org> wrote:
On 7/11/2023 3:03 PM, John Smith wrote:
Thanks for responding, Elliot. I somewhat understand that after the
write is accomplished, the
returning packet won't have the data. But still, why is the returned
value 0 in that case? Shouldn't
it still be equal to the memory access latency.
In the Atomic case this code is assuming the write can
be absorbed into a write buffer, so there is no additional
latency visible to the user. Of course it is possible to
saturate the buffers, and if you want a more accurate
accounting you can use a Timing model instead.
EM
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-leave@gem5.org
Thank you Elliot and Ayaz for the well explained responses. I understood
the code snippet now.
On Tue, Jul 11, 2023 at 5:46 PM Ayaz Akram yazakram@ucdavis.edu wrote:
Hi Eliot,
Based on my understanding, when pkt->makeResponse() is called it updates
the "cmd" of the pkt with the appropriate responseCommand (this line of
code: cmd = cmd.responseCommand();) . If you look at
"MemCmd::commandInfo[]" in packet.cc, the response command for a
"WriteReq" command is "WriteResp". And the attributes of a "WriteResp"
command don't have "HasData", which is why the response pkt will return
false on a "hasData()" check.
You might also want to look at the struct CommandInfo in packet.hh.
-Ayaz
On Tue, Jul 11, 2023 at 2:15 PM Eliot Moss via gem5-users <
gem5-users@gem5.org> wrote:
On 7/11/2023 3:03 PM, John Smith wrote:
Thanks for responding, Elliot. I somewhat understand that after the
write is accomplished, the
returning packet won't have the data. But still, why is the returned
value 0 in that case? Shouldn't
it still be equal to the memory access latency.
In the Atomic case this code is assuming the write can
be absorbed into a write buffer, so there is no additional
latency visible to the user. Of course it is possible to
saturate the buffers, and if you want a more accurate
accounting you can use a Timing model instead.
EM
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-leave@gem5.org
On 7/11/2023 5:46 PM, Ayaz Akram via gem5-users wrote:
Hi Eliot,
Based on my understanding, when pkt->makeResponse() is called it updates the "cmd" of the pkt with
the appropriate responseCommand (this line of code: cmd = cmd.responseCommand();) . If you look at
"MemCmd::commandInfo[]" in packet.cc, the response command for a "WriteReq" command is "WriteResp".
And the attributes of a "WriteResp" command don't have "HasData", which is why the response pkt will
return false on a "hasData()" check.
You might also want to look at the struct CommandInfo in packet.hh.
Ah, yes - I was confusing hasData with the STATIC_DATA and DYNAMIC_DATA
properties, which have to do with whether the data field is set (and
with whether it needs to be deleted when the packet is deleted), which
is separate from the logical notion of whether the packet is carrying
data from one place to another.
Thanks for the reminder! EM