Review Board 2.0.15


network: generalized bw for basic links

Review Request #661 - Created April 27, 2011 and submitted

Information
Brad Beckmann
gem5
Reviewers
Default
ali, gblack, nate, stever 
network: generalized bw for basic links

Generalized the specification of bw for basic links.  This value is then
translated to the specific value used by the simple and Garnet networks.

   

  


 


 

  

  









  
 


  

 
















 



 

  


 


  



   

   
Tushar Krishna

   
Posted  (April 27, 2011, 9:03 a.m.)


  


  


  

   



  

   

   
    
    
   


  




   







    

     
     
    

    


     
In garnet, the link width is actually equal to flit size (i.e. the entire flit is injected into the link). [bigger packets such as data are thereby broken into multiple flits]. 
So not sure if having both a "bandwidth_factor" and a "flit_size" parameter inside BaseGarnetNetwork.py will work. 
Perhaps we should set flit_size equal to bandwidth_factor there? 
"link_bandwidth" is a clearer term but I understand that is not true for simple network where the endpoint bandwidth comes into play...




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    Yeah, I don't want to call it link_bandwidth or simply bandwidth because the multipliers do impact the final bandwidth for the simple network.

The confusion I have, and the reason why I changed it, is before Garnet links could be of only one width, even though one would specify links of different widths in the topology.  Can we remove the flit _size parameter in BaseGarnetNetwork and just rely on the per link bandwidths (i.e. channel_width)?  Right now, only the NetworkInterfaces use the flit_size parameter and it seems more natural to have that be a configuration parameter for just the NIs and not the entire network.  Maybe that is a good reason to make the NIs sim_objects.

What do you think?  That seems like the right solution to me, but I would like to know your thoughts before I spend time implementing it.

    
    
    
   
    2. 


   
  2. 
    
    
     
    
      
     
    
     
    Garnet actually does not use the bw parameters from the topology files at all, and just uses the latency ones. You are right in that only the NI needs the flit size parameter when creating flits. 
However, the routers inject the complete flit into the link. The number of cycles it takes in the link depends upon link_latency. 
If we use the channel bandwidth parameter, then a flit size of 16, and a channel width of 8 (=> phit), requires that the flit should take 2 cycles to cross the link. 
But if the link latency is say 3 cycles, then the flit should take 2x3 = 6 cycles. Currently Garnet does not implement this. The flit would take 3-cycles in this case. 
Do you want me to modify garnet to implement this?
    
    
    
   
    3. 


   
  3. 
    
    
     
    
      
     
    
     
    Yes, non-uniformed link widths definitely complicate things.  I don't want to give you a bunch of work and I don't think it is necessary that Garnet needs to support multiple link widths.  I just don't want someone modifying the link bandwidths, expecting that to change the Garnet model, when it does not.  Instead, we could simply modify the current topologies to only use links of the same widths and add a check in Garent that verifies all links are the same width during initialization.  If they don't, we could generate a fatal message saying that only the simple network supports non-uniform link bandwidth.  It is up to you which direction we go down.  I just don't like the current implementation.

By the way, in your example shouldn't the flit take 4 cycles if we assume the links are pipelined?
    
    
    
   
    4. 


   
  4. 
    
    
     
    
      
     
    
     
    Yeah 4 cycles if links are pipelined.

Your solution makes sense. The links should use the bw parameter. We should use flit width only at the NI (which is what is done right now, I checked that the flit width parameter is not used by garnet anywhere else, though Router_d's constructor just initializes it). 
So not sure why we need the NI to be a simobject? It can just use flit_size from BaseGarnetNetwork.py as it does currently.
I can add a fatal message inside the network to make sure that flit size is equal to channel width in a separate patch.
    
    
    
   
    5.