-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3230/#review7943
-----------------------------------------------------------
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.
- Steve Reinhardt
On Jan. 10, 2016, 9:58 p.m., Mohammad Alian wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3230/
> -----------------------------------------------------------
>
> (Updated Jan. 10, 2016, 9:58 p.m.)
>
>
> Review request for Default.
>
>
> Repository: gem5
>
>
> Description
> -------
>
> Changeset 11292:ed7527fcc338
> ---------------------------
> 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
