On Thursday, November 24, 2016 04:54 AM, Srinivas, Raghavendra
(IntlAssoc) wrote:
Replacing is very channel dependent. It can only happen on certain
data and certain state of the channel. Not generally. It needs to be
fine tuned for each channel. And it needs to happen at the input side
of the RTIO FIFO. In DRTIO we can't have such channel dependent
gateware close to the kernel CPU. Whether a channel supports
replacing is done by adding to the RTIO CSR API a logical "address"
that discriminates replaceable "register data". That additional
address field directly impacts and increases the amount of data that
is written on each RTIO event submission. We expect a significant
speed up in event rate by removing it. It also bloats DRTIO packets.
Well there is nothing unmanageable there.
* If we keep your "reset address CSR on timestamp modification" feature,
those writes that always have address zero (e.g. set TTL level) can use
a different syscall that ignores the address and saves the associated
CPU overhead.
* In DRTIO packets, the address field can be transmitted in a handful of
nanoseconds.
* For replacements in DRTIO, we can just do it on the remote side. The
inefficiency of sending multiple packets is fine as the throughput will
be limited by the CPU anyway. For DMA, we can optimize the sequences in
advance to remove internal replacements.
* The remote side also has a synchronous FIFO which is easier to handle
than the asynchronous FIFO of local RTIO.
Sébastien
_______________________________________________
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
