Hi Andreas, You brought up a valid point. But from what I understand, Stefano is simply doing the following: Currently any synthetic traffic pattern is implemented by specifying source-destination pairs. The “sources” are CPUs, and “destinations” are directories. Each router has a CPU and directory connected to it, via their individual NICs. The NIC at the directory has a consumption assumption (it consumes all packets) and does not generate any response. Instead, now the CPUs will send to the directory in the request vnet via a user specified pattern (random/bit-complement/…), and the directory will create and send a response packet in the response vnet. There is of course a dependence now — if the output queue at the directory is full, then it cannot consume the requests from the CPU, i.e., the consumption assumption does not hold any more. To avoid deadlocks: (a) packets in the response vnet should have a consumption assumption back at the CPU NICs. i.e. , the only dependence is request_cpu_to_dir —> response_dir_to_cpu. (b) the CPU NICs should not send another response in response to this one (i.e, not create another dependence).
So 2 vnets should be enough. Note this is just a synthetic traffic pattern (random, bit-complement etc) with an additional set of reverse flows. For real coherence protocols, yes one needs 3-6 vnets as most coherence protocols in gem5 do. Cheers, Tushar On Apr 7, 2017, at 5:07 AM, Andreas Hansson <[email protected]<mailto:[email protected]>> wrote: Hi Stefano, With the construct described in the first mail you are creating a chain of at least length 3, so two vnets is not enough. Someone would have to actually look at the overall message-dependency graph. I would think you’re looking at 6-7 vnets, but that’s just a guess. Andreas From: gem5-users <[email protected]<mailto:[email protected]>> on behalf of Stefano Esposito <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Friday, 7 April 2017 at 09:53 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Subject: Re: [gem5-users] Extending Garnet tester 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: [email protected]<mailto:[email protected]> phone: +390110907091 fax: +390110907099 2017-04-07 9:43 GMT+02:00 Andreas Hansson <[email protected]<mailto:[email protected]>>: 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 <[email protected]<mailto:[email protected]>> on behalf of "Krishna, Tushar" <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Thursday, 6 April 2017 at 21:09 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> phone: +390110907091<tel:+39%20011%20090%207091> fax: +390110907099<tel:+39%20011%20090%207099> _______________________________________________ gem5-users mailing list [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
