On Wed, Sep 28, 2016 at 05:08:24PM +0800, Gonglei wrote:
> +For scatter/gather list support, a buffer can be represented by
> virtio_crypto_iovec structure.
> +
> +The structure is defined as follows:
> +
> +\begin{lstlisting}
> +struct virtio_crypto_iovec {
> + /* Guest physical address */
> + le64 addr;
> + /* Length of guest physical address */
> + le32 len;
> +/* This marks a buffer as continuing via the next field */
> +#define VIRTIO_CRYPTO_IOVEC_F_NEXT 1
> + /* The flags as indicated above VIRTIO_CRYPTO_IOVEC_F_*. */
> + le32 flags;
> + /* Pointer to next struct virtio_crypto_iovec if flags & NEXT */
> + le64 next_iovec;
> +};
> +\end{lstlisting}The vring already provides scatter-gather I/O. It is usually not necessary to define scatter-gather I/O at the device level. Addresses can be translated by the virtio transport (PCI, MMIO, CCW). For example PCI bus addresses with IO-MMU. Therefore it's messy to use guest physical addresses in the device specification. > +Each data request uses virtio_crypto_hash_data_req structure to store > information > +used to run the HASH operations. The request only occupies one entry > +in the Vring Descriptor Table in the virtio crypto device's dataq, which > improves > +the throughput of data transmitted for the HASH service, so that the virtio > crypto > +device can be better accelerated. Indirect vrings also only require one entry in the descriptor table. I don't understand why you are reinventing scatter-gather I/O. Am I missing something? Stefan
signature.asc
Description: PGP signature
