> On July 24, 2012, 9:23 a.m., Ali Saidi wrote:
> > does it make sense to have schedSendTiming() return true always now so a 
> > derived version could return that the buffer was full if it desired?

I'd rather save that for a separate patch. If we have bounded queues (which 
definitely is a good idea and would be useful e.g. in the bridge) then we also 
need to have callbacks for when the queue is ready again. In other words, we 
end up with a handshake similar to sendTiming/sendRetry and I would rather not 
give the illusion that we can simply change the value to false and everything 
would just work.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1312/#review3138
-----------------------------------------------------------


On July 19, 2012, 2:15 p.m., Andreas Hansson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1312/
> -----------------------------------------------------------
> 
> (Updated July 19, 2012, 2:15 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Description
> -------
> 
> Changeset 9128:801a3197066a
> ---------------------------
> Port: Extend the QueuedPort interface and use where appropriate
> 
> This patch extends the queued port interfaces with methods for
> scheduling the transmission of a timing request/response. The methods
> are named similar to the corresponding sendTiming(Snoop)Req/Resp,
> replacing the "send" with "sched". As the queues are currently
> unbounded, the methods always succeed and hence do not return a value.
> 
> This functionality was previously provided in the subclasses by
> calling PacketQueue::schedSendTiming with the appropriate
> parameters. With this change, there is no need to introduce these
> extra methods in the subclasses, and the use of the queued interface
> is more uniform and explicit.
> 
> 
> Diffs
> -----
> 
>   src/dev/x86/intdev.cc 48eeef8a0997 
>   src/mem/cache/base.hh 48eeef8a0997 
>   src/mem/cache/cache_impl.hh 48eeef8a0997 
>   src/mem/packet_queue.cc 48eeef8a0997 
>   src/mem/qport.hh 48eeef8a0997 
>   src/mem/ruby/system/RubyPort.hh 48eeef8a0997 
>   src/mem/ruby/system/RubyPort.cc 48eeef8a0997 
>   src/mem/tport.cc 48eeef8a0997 
> 
> Diff: http://reviews.gem5.org/r/1312/diff/
> 
> 
> Testing
> -------
> 
> util/regress all passing (disregarding t1000 and eio)
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to