Re: [Qemu-devel] [RFC] QOMification of AXI stream

[Edgar E. Iglesias]

On Tue, Jun 12, 2012 at 10:33:51AM +1000, Peter Crosthwaite wrote:
> >
> > Hi,
> >
> > IIRC the word array thing is device specific, not really AXI stream.
> > I think the whole connection to AXI is a bit unfortunate,
> 
> Yes, so I think we can summaries the confusion here with AXI stream is
> completely unreleated to AXI. The connection between the two comes
> with the way low level signalling is handled. (e.g. the SRC_RDY and
> DST_RDY pins etc. etc.), thats common between AXI and AXI stream hence
> the shared name. This is of course completely irrelevant to QEMU.
> 
> these devices
> > are pretty much the same devices that in other contexts where connected
> > to other bus standards. Xilinx choose to name them AXI-xxx and I used
> > the name in our models but I didn't really model anything that is AXI
> > stream specific..
> >
> 
> Theres not a lot to model. With the signalling stuff taken away, its
> pretty much just a unidirectional point-to-point data bus. There is
> the T_LAST bit, and the extended capabilities PMM mentioned.

IMO:
Yes, the end-of-packet needs to be modeled,
(e.g one function-call -> one packet). The exteneded stuff is AFAICS just
optimization, the abstract concept is still data moving. We are not modeling
AXI Stream, we should be modeling the common abstraction between DMA ctrls
and devices. Error reporting from the sink/device might be needed in some cases
(overrun/underrun etc).

Another issue is that these data paths are typically high-speed. So a zerocopy
approach might be worth looking at. For example, if all the chunks in
a packet are backed by host memory, we could just pass pointers to
the final sink, which in turn can do the equivalent of a writev() without
memory_rw into temporary linear bufs etc. maybe...

Cheers