On Tue, January 29, 2013 6:12 pm, Steve Reinhardt wrote: > Hi Nilay, > > On Tue, Jan 29, 2013 at 3:50 PM, Nilay <ni...@cs.wisc.edu> wrote: > >> There are two things here about the etherlink that I think are not what >> they should be -- >> >> 1. As I understand, if there is a transmission delay (which I think >> means >> moving bits from the interface to the transmission medium), then there >> should be a reception delay involved as well. You might say that the two >> delays can be combined in to, but that does not seem fine to me. >> > > Why is that not fine? Just think of it as a single end-to-end delay. > There's no point in adding the overhead of an event in the middle that > merely schedules another event a fixed time later. >
I had incorrectly understood the code. You can forget about this. But one thing to note is that, not one but two events are scheduled by the link. One for to simulate the link's delay and one for simulating the bandwidth. > >> 2. The absence of the delay mentioned above means that the etherlink >> object calls directly into the etherint object instead of scheduling an >> event. It seems kind of unnatural that a simobject operates upon another >> simobject through a function call, when the two simobjects have a >> sibling >> relationship in the hierarchy of simobjects. >> > > This is how ports work in gem5. When one object calls sendTiming(), it > ends up as a direct call into the object on the other side of the port > interface. The ports provide decoupling in terms of which function gets > called on the receiver, but it's still a direct function call. > > If there's a specific reason why this is giving you difficulties, please > explain further and we can discuss a solution. > I am trying to parallelize a simulation which has two systems connected by an ethernet link. As of now, the sender calls a function in the link to transfer the packet, and some time later the link calls a function in the receiver for transferring the packet. In a parallelized simulation, assume that we have three threads, one thread each for the two systems and one for the link and each thread has its event queue. When the sender thread wants to send a packet, it would call a function in the link object which is owned by the thread for the link. It is possible that the two threads might end up changing the state of the link concurrently. I can think of following ways to avoid this concurrent access to the link -- * An event is scheduled by the sender for the link on the link's event queue. * Have a queue between the sender and link. The queue would be protected by a lock, so that the sender and the link threads do not access it concurrently. * The link object does not have a thread associated to it at all. Instead, it can schedule events on the queues of the systems associated with its two ends. When one system wants to send a packet to the other, it invokes a function in the link object which schedules an event in the other system. As of now, I am leaning towards this final way that I suggested. But it seems that the two events that I mentioned way above would need to be fused in to one. I am hoping that my description is lucid enough. -- Nilay _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
