Port: Extend the QueuedPort interface and use where appropriate

Information
Submitter:	Andreas Hansson
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Changeset 9155:eb11628d78be
---------------------------
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.

Testing Done

util/regress all passing (disregarding t1000 and eio)

Issue Summary

Description	From	Last Updated	Status
It seems asymmetric that you got rid of sendNextCycle() here but kept it below for PioHandler... at some point it ...	Steve Reinhardt	Aug. 6, 2012, 8:39 p.m.	Resolved

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?

Andreas Hansson July 24, 2012, 5:50 p.m. (July 24, 2012, 5:50 p.m.)

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.

Ship It!

Looks good in general, just one minor tangential issue...

src/mem/ruby/system/RubyPort.hh (Diff revision 1)

It seems asymmetric that you got rid of sendNextCycle() here but kept it below for PioHandler... at some point it would be nice to see the ClockedObject code come in and clean all this up!  In the meantime though it seems like the two cases should be consistent one way or another.

Show all issues

Description:

~		Changeset 9128:801a3197066a
	~	Changeset 9155:eb11628d78be

		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.

Diff:

Revision 2 (+42 -49)

Show changes

	src/dev/x86/intdev.cc
	src/mem/packet_queue.cc
	src/mem/qport.hh
	src/mem/tport.cc
	src/mem/cache/base.hh
	src/mem/cache/cache_impl.hh
	src/mem/ruby/system/RubyPort.hh
	src/mem/ruby/system/RubyPort.cc

Ship It!

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Issue Summary

Description:

Changeset 9128:801a3197066a

Changeset 9155:eb11628d78be

Diff:

Status: Closed (submitted)