Re: [Gems-users] Garnet: Does NetworkInterface_d not check protocol buffer availability?

[Niket Agarwal <niketa@xxxxxxxxxxxxx>]

Currently, I don't think this back pressure is modeled in Garnet. Thanks for pointing it out. But, you can easily add that. Basically, you need to delay the freeing of VCs till the message is enqueued in the outBuffer. 

Also, if we have 4/8 VCs and the protocol buffers being 32 (default in GEMS) this should not be an issue. This could show up at memory controllers where messages are queued longer. But, most gems protocols model fixed DRAM latency and for them this should not be an issue. 

-Niket

On Sat, Oct 31, 2009 at 3:18 PM, Ikhwan Lee <ikhwan@xxxxxxxxxxxxxxx> wrote:

Hi all,

 

In the NetworkInterface_d::wakeup() function, upon receiving a TAIL flit from the inNetLink, the message is enqueued into the corresponding protocol buffer without checking the availability (by calling areNSlotsAvailable). Can someone shed light on how and where the protocol buffer back pressure is modeled for in_ports?

 

Regards,

Ikhwan

 

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.