Hi Andreas,
thanks for pointing out this issue. You are right, but I think the
risk of message-dependent deadlock could be avoided by using one vnet for
request messages and another vnet for response messages. Am I missing
something?
Regards,
Stefano.
----
Stefano Esposito
Ph.D. Student - IEEE Student Member
DAUIN - Politecnico di Torino
C.so Duca degli Abruzzi, 24
10129 - Torino
Italy
email: stefano.espos...@polito.it
phone: +390110907091
fax: +390110907099
2017-04-07 9:43 GMT+02:00 Andreas Hansson <andreas.hans...@arm.com>:
> Hi all,
>
> To me this smells like a message-dependent deadlock waiting to happen. If
> you create a message like this you extend the dependency chain, and if you
> are not really careful regarding what resources that message uses it’s
> likely to fail. Am I missing something?
>
> Andreas
>
> From: gem5-users <gem5-users-boun...@gem5.org> on behalf of "Krishna,
> Tushar" <tus...@ece.gatech.edu>
> Reply-To: gem5 users mailing list <gem5-users@gem5.org>
> Date: Thursday, 6 April 2017 at 21:09
> To: gem5 users mailing list <gem5-users@gem5.org>
> Subject: Re: [gem5-users] Extending Garnet tester
>
> There are two possible ways to do this:
>
> (1) The correct way. The behavior you are trying to model is one that any
> coherence protocol would have. You can change the directory in
> Garnet_standalone protocol (src/mem/protocols/Garnet_standalone-*) to
> respond to the src (from the msg) after some delay. Right now it ignores
> the received message. You can look at other protocols (MI_example perhaps,
> or MOESI_hammer) for some reference on how to write the SLICC code for this.
>
> (2) The hack - When a NI receives a packet, you can see that it enqueues
> it into some message buffers for the coherence protocol. Here you can
> perhaps generate a new packet (by calling the flitisize function) and send
> it out to the sender of the original packet.
>
> - Tushar
>
>
> On Mar 31, 2017, at 10:50 AM, Stefano Esposito <stefano.espos...@polito.it>
> wrote:
>
> Hello list,
>
> I'm trying to understand what is the best way to extend the garnet
> standalone tester in order to add a different behavior. My intention is to
> have some nodes keeping track of the received packets and inject packets
> towards the sender, instead of injecting as specified by the traffic
> pattern. Other nodes should inject traffic according to the traffic
> pattern.
>
> I don't understand how to pass the information "packet received" to the
> tester class, could anyone point to relevant documentation and/or code?
>
> Thanks,
> Stefano.
> ----
>
> Stefano Esposito
> Ph.D. Student - IEEE Student Member
> DAUIN - Politecnico di Torino
> C.so Duca degli Abruzzi, 24
> 10129 - Torino
> Italy
> email: stefano.espos...@polito.it
> phone: +390110907091 <+39%20011%20090%207091>
> fax: +390110907099 <+39%20011%20090%207099>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
