> On Jan. 21, 2016, 8:59 p.m., Steve Reinhardt wrote:
> > So here's an alternative design that would be a lot simpler and I think
> > just as accurate (modulo the caveat about external link scheduling at the
> > end):
> >
> > Each Interface has
> > - an outputFifo (no inputFifo) with <timestamp, packet> pairs
> > - an outputFifoOccupancy variable tracking the number of bytes in
> > outputFifo
> > - an enqueue() method
> >
> > Then on each packet received, in recvPacket(), basically put what is now
> > inside the loop in forwardingEngine(), only much stripped down:
> >
> > // could make this more complicated, but
> > // probably no need
> > done_tick = curTick() + switchDelay;
> >
> > receiver = lookupDestPort();
> > if (!receiver etc.) {
> > for (auto it : interfaces)
> > if (it != this)
> > it->enqueue(pkt, done_tick);
> > } else {
> > receiver->enqueue(pkt, done_tick);
> > }
> >
> > and then the enqueue looks like
> >
> > void
> > Interface::enqueue(pkt, done_tick)
> > {
> > int new_occ = outputFifoOccupancy + pkt->size();
> >
> > if (new_occ > outputFifoSize) {
> > // output buffer full, drop packet
> > // do we need to delete the packet here?
> > return;
> > }
> >
> > // assuming per-interface transmission events,
> > // if outputFifo is empty then we need to schedule
> > // an event at done_tick to send this packet
> > // out the external link
> > if (outputFifo.empty())
> > xmitEvent.schedule(done_tick);
> >
> > outputFifo.push_back(pkt, done_tick);
> > outputFifoOccupancy = new_occ;
> > }
> >
> >
> > and then the transmit event just:
> > - pulls a packet off the front of outputFifo
> > - sends it on the connected external link
> > - updates outputFifoOccupancy
> > - if outputFifo is not empty, reschedules the xmit event based on the
> > done_tick at the head of the fifo, the current tick, and when the external
> > link is next free
> >
> > I have to look at the code a little more to remember how to handle the
> > outgoing link congestion... if I try to transmit on the link and it's busy,
> > do I get a callback when it's free like I do with memory ports? Can I
> > query the link to find out when it's free next, or do I need to track that
> > directly? So that'll be a minor complication, but really only effects when
> > the transmission events are scheduled.
> >
> > Does this make sense? It would get rid of FabricLink, forwardingEngine()
> > and transmissionEngine() (and thus all the tick events), the inputFifos,
> > and the partial retries of broadcasts, but yet I don't think we would lose
> > any appreciable modeling accuracy.
This patch is based on an old patch which never gets commited to gem5 tree, so
I didn't change the basic design descisions.
Apparently you are not happy with the current implementation, so I reflect what
you proposed here into the new revision. It's up to the respected reviewers to
decide which implementation is better to get commited. If you decided to go for
the previous implementation, I'll address the open issues with that approach.
- Mohammad
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3230/#review7943
-----------------------------------------------------------
On Jan. 24, 2016, 8:35 p.m., Mohammad Alian wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3230/
> -----------------------------------------------------------
>
> (Updated Jan. 24, 2016, 8:35 p.m.)
>
>
> Review request for Default.
>
>
> Repository: gem5
>
>
> Description
> -------
>
> Changeset 11292:9ed37b34da3a
> ---------------------------
> dist,dev: add an ethernet switch model
>
>
> Diffs
> -----
>
> src/dev/net/Ethernet.py 9d2364203316
> src/dev/net/SConscript 9d2364203316
> src/dev/net/etherswitch.hh PRE-CREATION
> src/dev/net/etherswitch.cc PRE-CREATION
>
> Diff: http://reviews.gem5.org/r/3230/diff/
>
>
> Testing
> -------
>
> several testing done with different benchmarks and different switch sizes
>
>
> Thanks,
>
> Mohammad Alian
>
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
