> I was trying to better understand the workings of the
> MOSI_SMP_bcast protocol and have a couple of
> questions.
>
> What exactly happens when a request is recycled on the
> network queue i.e. action zz_recycleMandatoryQueue in
> MOSI_SMP_bcast.sm.
>
Recycling a request pops it from the head of the queue and places it at
the end of the queue, and schedules a wakeup in case the controller
doesn't wake up the next cycle anyways. Essentially recycling a request
allows our queues to be non-FIFO and allows one request for cache line to
block while others are serviced.
> What parameter can be used to limit the number of
> outstanding cache requests?
>
The number of requests issued to the memory system can be controlled by
the g_SEQUENCER_OUTSTANDING_REQUESTS parameter. However the L1 cache
controller itself can control how many MSHRs are available with the
NUMBER_OF_TBES parameter.
> What is the equivalent of the mshr in ruby?
>
a TBE. Each protocol will have a TBETable in the cache controller.
> Finally unrelated to the MOSI_SMP_bcast protocol - are
> there any SMP protocols which are part of your release
> which can handle retry requests?
>
We've certainly implemented Nack/Retry directory protocols before. But it
doesn't appear that the SMP protocols we include with the release do this.
The token coherence protocols retry requests.
|