I don't think I changed anything here... hg annotate seems to back me
up on that, too. I think the fundamental (but subtle) issue here is
that once you successfully send a packet, the ownership for that
packet object is conceptually handed off to the recipient, so
technically the sender shouldn't
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Steve Reinhardt
Sent: Thursday, August 19, 2010 3:03 PM
To: M5 Developer List
Subject: Re: [m5-dev] TimingSimpleCPU, x86: sendSplitData packet sender
states
(That said, looking over
Quoting Steve Reinhardt ste...@gmail.com:
I don't think I changed anything here... hg annotate seems to back me
up on that, too. I think the fundamental (but subtle) issue here is
that once you successfully send a packet, the ownership for that
packet object is conceptually handed off to the
Hi,
I am currently looking at the sendSplitData function in TimingSimpleCPU
(cpu/simple/timing.cc:~307), and I'm encountering a problem with the packet
sender states when running with Ruby. After the call to buildSplitPacket,
pkt1 and pkt2 have senderState type SplitFragmentSenderState.
I just realized that the clearFromParent call is used for tracking which of
the packets have successfully sent, so that if the send port is busy, it can
retry them when a recvRetry is received later. It appears that maybe a
better solution to this is to hold a pointer on the stack in
