> On May 13, 2016, 2:30 p.m., Gabor Dozsa wrote: > > src/dev/net/etherswitch.hh, line 122 > > <http://reviews.gem5.org/r/3465/diff/1/?file=55325#file55325line122> > > > > I would suggest to use a std::set instead of std::list for the fifo. > > You can define a compare object that uses the recvTick and the sourceId as > > the primary and secondary key, respectively. The fifo.push() method could > > then be much simpler. (See my futher commnents there.)
Thanks for the suggestion. I change the implementation like what you suggest. > On May 13, 2016, 2:30 p.m., Gabor Dozsa wrote: > > src/dev/net/etherswitch.hh, line 147 > > <http://reviews.gem5.org/r/3465/diff/1/?file=55325#file55325line147> > > > > The preferred way for serializing child objects is using > > 'serializeSection' from the parent. PortFifo should derive from > > 'Serializable' and then you can drop the extra 'base' argument here and for > > 'unserialize()', too. I fixed them all. Plz let me know if there is any issues left. > On May 13, 2016, 2:30 p.m., Gabor Dozsa wrote: > > src/dev/net/etherswitch.cc, line 77 > > <http://reviews.gem5.org/r/3465/diff/1/?file=55326#file55326line77> > > > > If the fifo were a std::set with a custom comparator (using recvTick as > > primary and sourceId as secondary key) then you could simply call > > 'fifo.insert(entry)'. All entries would be kept in the correct order by the > > container. If the size of fifo is too big after the insert then you could > > simply erase the last element (i.e. at fifo.rbegin()) to drop a single > > packet (instead of dropping potentially many packets with the current > > code). Does that make sense? I think we still need to drop as many packet as enough to make space for the new pakcet with higher priority to push in to the fifo. E.g. if there are two packets with size 10 Bytes at the end of fifo and we receive a new packet with size 20 Bytes while fifo is full (and the newly arrived packet has arrived at the same tick as the already pushed packets but has higher priority), then we should drop two small packets and push one large packet. Does that make sense? So I still keep the code which drop multiple packets. - Mohammad ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3465/#review8298 ----------------------------------------------------------- On May 17, 2016, 3:22 a.m., Mohammad Alian wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3465/ > ----------------------------------------------------------- > > (Updated May 17, 2016, 3:22 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11472:c7242a550140 > --------------------------- > dist, dev: Fixed the packet ordering in etherswitch > This patch fixes the order that packets gets pushed into the output fifo > of etherswitch. If two packets arrive at the same tick to the etherswitch, > we sort and push them based on their source port id. > In dist-gem5 simulations, if there is no ordering inforced while two > packets arrive at the same tick, it can lead to non-deterministic simulations > > > Diffs > ----- > > src/dev/net/etherswitch.hh 954d3014f7f0 > src/dev/net/etherswitch.cc 954d3014f7f0 > > Diff: http://reviews.gem5.org/r/3465/diff/ > > > Testing > ------- > > > Thanks, > > Mohammad Alian > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
