Let's follow the same convention we've been using with other components that are being used outside of mainline and deprecate the WireBuffer. It should be removed because it performs the same functionality and has same API as an ordered MessageBuffer. AMD should shift over to using the MessageBuffer instead. We can simply add a run-time warning when a WireBuffer is instantiated that states that the component is deprecated and will be removed. We can set a horizon date on the WireBuffer's inclusion in mainline, and remove it on that date.
Is that agreeable to both parties? Joel On Thu, Jun 25, 2015 at 1:43 PM, Steve Reinhardt <[email protected]> wrote: > > > > On June 19, 2015, 10:07 a.m., Steve Reinhardt wrote: > > > yYes, we use the wire buffer in our protocols and oppose its removal. > (What's the opposite of the "Ship It" button?) Brad is on vacation today so > I'll comment on his behalf :). > > > > Brad Beckmann wrote: > > Nilay **please** when commenting on a patch, use Reviewboard rather > than directly replying to an email. It is very hard to keep track of your > comments over email. > > > > On 6/19 Nilay said "Steve, can you spell out the difference between > the WireBuffer and the MessageBuffer classes?" > > > > The wire buffer is not a virtual channel buffer, rather it mimics an > actual wired communication between to controllers. As Jason points oout, > it allows us to closely tie controllers together and take advantage of > ordering properties not provided by MessageBuffers. > > > > Nilay Vaish wrote: > > You write what you think the WireBuffer is doing. Have you read the > code? How do you make sense of a data structure that has queue-like > semantics for inserts and heap-like for deletes and recycles? What > > wire behaves in this fashion? Or for that matter what wire has > buffering associated with it? > > > > Nilay Vaish wrote: > > One more thing that you may not be aware of. You can connect two > controllers > > directly using message buffers without going through the network. > So, you > > probably do not require WireBuffer anyway. > > > > Nilay Vaish wrote: > > Is AMD further interested in arguing about this data structure? > > I am completely confident whatever Brad claimed is not what this > > data structure does. And MessageBuffer with ordered=true would > > serve the purpose as long as two controllers are directly connnected. > > Unless anyone speaks on this issue soon enough (end of next week or > so), > > I am going assume this debate has concluded and commit this patch. > > We are not interested in further argument. We are using this structure > and it should not be removed. We believe that should be sufficient > argument for not committing this patch. > > > - Steve > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2896/#review6527 > ----------------------------------------------------------- > > > On June 18, 2015, 9:09 p.m., Nilay Vaish wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviews.gem5.org/r/2896/ > > ----------------------------------------------------------- > > > > (Updated June 18, 2015, 9:09 p.m.) > > > > > > Review request for Default. > > > > > > Repository: gem5 > > > > > > Description > > ------- > > > > Changeset 10881:4962564c4ce6 > > --------------------------- > > ruby: remove wire buffer > > > > The structure is not being used anywhere. > > > > > > Diffs > > ----- > > > > src/mem/protocol/RubySlicc_Types.sm ebb3d0737aa7 > > src/mem/ruby/SConscript ebb3d0737aa7 > > src/mem/ruby/structures/SConscript ebb3d0737aa7 > > src/mem/ruby/structures/WireBuffer.hh ebb3d0737aa7 > > src/mem/ruby/structures/WireBuffer.cc ebb3d0737aa7 > > src/mem/ruby/structures/WireBuffer.py ebb3d0737aa7 > > src/mem/slicc/symbols/StateMachine.py ebb3d0737aa7 > > > > Diff: http://reviews.gem5.org/r/2896/diff/ > > > > > > Testing > > ------- > > > > > > Thanks, > > > > Nilay Vaish > > > > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- Joel Hestness PhD Candidate, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
