On 7/11/2023 12:37 PM, John Smith via gem5-users wrote:

John - Certain packets carry no data.  For example, a cache line invalidate
without write back will have that property.  Maybe others.

Best - Eliot

Okay, but I've also noticed that a WriteReq generally carries no data. Why
exactly is that? Cause if we are writing to memory, then the memory access
latency shouldn't be 0 right?

On Tue, Jul 11, 2023 at 12:49 PM Eliot Moss moss@cs.umass.edu wrote:

On 7/11/2023 12:52 PM, John Smith wrote:

I believe that happens if the write got its data by snooping a cache.
The packet still goes to the memory, but with the write suppressed.
This certainly happens in the Timing case; I admit I'm a little less
clear about the Atomic one.

Best - EM

On 7/11/2023 1:01 PM, Eliot Moss wrote:

Sorry - I see I was responding about a read.

So, what surprises me is that you're saying that write requests generally
carry no data.  That doesn't seem right.  What leads you to that conclusion?

Best - EM

So, I used the function pkt->isWrite() to check if the packet is a write
request. And I observed that inside the pkt->hasData() if condition,
pkt->isWrite() returned false. Hence only the read packets were entering
the if(pkt->hasData()) condition

On Tue, Jul 11, 2023 at 1:10 PM Eliot Moss moss@cs.umass.edu wrote:

On 7/11/2023 1:28 PM, John Smith via gem5-users wrote:

So you're saying that inside the if condition, pkt->isWrite is always false?

I see.  I couldn't find a place in the code (in the version I have downloaded
anyway) where the data is dropped, but I can imagine it happening after the
write is accomplished (though I don't see why), so that the "returning"
packet no longer has data.  What are the exact types of the components
involved?  And maybe someone else is more competent to answer this since it
is somewhat stumping me from my reading of the code.

Cheers - Eliot

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.

On Tue, Jul 11, 2023 at 2:34 PM Eliot Moss moss@cs.umass.edu wrote:

Hi John,

If you are checking if the pkt is write when pkt->hasData() condition is
true in recvAtomicLogic() function, the check (pkt_is_write) will always be
false. The reason is that a write pkt would have already written its data
to the memory (abstract memory) in the previous line of code
"mem_intr->access(pkt);" That access to the memory interface converts a
request pkt into a response pkt and adds or removes data from the pkt
(depending on if the request was a read or a write). Also, in this
implementation, the accessLatency will only be returned if the request was
a read request i.e., the write requests would not see any latency.

-Ayaz

On Tue, Jul 11, 2023 at 12:06 PM John Smith via gem5-users <
gem5-users@gem5.org> wrote:

On 7/11/2023 3:20 PM, Ayaz Akram via gem5-users wrote:

Dear Ayaz - That makes sense to me, but I could not find where
the dropping of the data happens in the code.  The makeResponse
function on packets does not affect the data, and neither does
the writeData function (which grabs the data and copies it to
the memory).  If you know where this happens, it might improve
John's and my understandings of how this code path works.

Regards - Eliot