On Tue, Jun 14, 2016 at 07:53:17PM -0400, Zhihong Wang wrote:
> This patch explains all the versions of current virtio pmd implementation,
> what's the difference, and how to choose the right version.
>
> --------------
> Changes in v2:
>
> 1. Changes on format and few descriptions.
Change log should go ...
>
>
> Signed-off-by: Zhihong Wang <zhihong.wang at intel.com>
> ---
here..
> doc/guides/nics/virtio.rst | 64
> +++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 58 insertions(+), 6 deletions(-)
>
> diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
> index 06ca433..a4fef89 100644
> --- a/doc/guides/nics/virtio.rst
> +++ b/doc/guides/nics/virtio.rst
> @@ -73,7 +73,7 @@ In this release, the virtio PMD driver provides the basic
> functionality of packe
>
> * It supports multicast packets and promiscuous mode.
>
> -* The descriptor number for the RX/TX queue is hard-coded to be 256 by
> qemu.
> +* The descriptor number for the Rx/Tx queue is hard-coded to be 256 by
> qemu.
> If given a different descriptor number by the upper application,
> the virtio PMD generates a warning and fall back to the hard-coded value.
>
> @@ -163,8 +163,8 @@ Host2VM communication example
> which means received packets come from vEth0, and transmitted packets is
> sent to vEth0.
>
> #. In the guest, bind the virtio device to the uio_pci_generic kernel
> module and start the forwarding application.
> - When the virtio port in guest bursts rx, it is getting packets from the
> raw socket's receive queue.
> - When the virtio port bursts tx, it is sending packet to the tx_q.
> + When the virtio port in guest bursts Rx, it is getting packets from the
> raw socket's receive queue.
> + When the virtio port bursts Tx, it is sending packet to the tx_q.
>
> .. code-block:: console
>
> @@ -183,7 +183,7 @@ Host2VM communication example
>
> The packet reception and transmission flow path is:
>
> - IXIA packet generator->82599 PF->KNI rx queue->KNI raw socket
> queue->Guest VM virtio port 0 rx burst->Guest VM virtio port 0 tx burst-> KNI
> tx queue->82599 PF-> IXIA packet generator
> + IXIA packet generator->82599 PF->KNI Rx queue->KNI raw socket
> queue->Guest VM virtio port 0 Rx burst->Guest VM virtio port 0 Tx burst-> KNI
> Tx queue->82599 PF-> IXIA packet generator
>
> Virtio with qemu virtio Back End
> --------------------------------
> @@ -206,8 +206,60 @@ Virtio with qemu virtio Back End
>
> In this example, the packet reception flow path is:
>
> - IXIA packet generator->82599 PF->Linux Bridge->TAP0's socket queue->
> Guest VM virtio port 0 rx burst-> Guest VM 82599 VF port1 tx burst-> IXIA
> packet generator
> + IXIA packet generator->82599 PF->Linux Bridge->TAP0's socket queue->
> Guest VM virtio port 0 Rx burst-> Guest VM 82599 VF port1 Tx burst-> IXIA
> packet generator
>
> The packet transmission flow is:
>
> - IXIA packet generator-> Guest VM 82599 VF port1 rx burst-> Guest VM
> virtio port 0 tx burst-> tap -> Linux Bridge->82599 PF-> IXIA packet generator
> + IXIA packet generator-> Guest VM 82599 VF port1 Rx burst-> Guest VM
> virtio port 0 Tx burst-> tap -> Linux Bridge->82599 PF-> IXIA packet generator
> +
> +
> +Virtio PMD Versions
> +-------------------
Using "versions" here is a bit confusing to me, especially virtio PMD
supports spec version 0.95 and 1.0. Apparently, that's not what you
are talking about, virtio pmd Rx/Tx callbacks is.
So, something like "Virtio PMD Rx/Tx callbacks" is what I would suggest.
> +
> +Virtio driver has 3 versions of Rx functions and 2 versions of Tx functions.
And I will avoid using "versions".
> +
> +Rx functions:
> +
> +#. ``virtio_recv_pkts``:
> + Regular version without mergeable Rx buffer support.
> +
> +#. ``virtio_recv_mergeable_pkts``:
> + Regular version with mergeable Rx buffer support.
> +
> +#. ``virtio_recv_pkts_vec``:
> + Simple version without mergeable Rx buffer support, also fixes the
> available ring indexes and uses vector instructions to optimize performance.
Just like coding and writing commit log, don't write long lines over 80
chars here.
Also I will use "vector" instead of "simple" here, as "vector" is more
easier to understand.
> +
> +Tx functions:
> +
> +#. ``virtio_xmit_pkts``:
> + Regular version.
> +
> +#. ``virtio_xmit_pkts_simple``:
> + Simple version fixes the available ring indexes to optimize performance.
> +
> +
> +By default, the non-vector versions are used:
> +
> +* For Rx: If mergeable Rx buffers is disabled then ``virtio_recv_pkts`` is
> used; otherwise ``virtio_recv_mergeable_pkts``.
> +
> +* For Tx: ``virtio_xmit_pkts``.
> +
> +
> +Setting ``txq_flags`` to ``VIRTIO_SIMPLE_FLAGS`` (0xF01) enables the simple
> version of the virtio poll mode driver:
> +
> +* For Rx: ``virtio_recv_pkts_vec``.
> +
> +* For Tx: ``virtio_xmit_pkts_simple``.
> +
This paragraph says that vector Rx/Tx will be enabled when 0xf01 txq
flags is set.
> +
> +The simple version will only be enabled when:
> +
> +* Mergeable Rx buffers is disabled.
> +
> +* Single segment is specified.
> +
> +* No offload support is needed.
However, you are making another statement that vector Rx/Tx will be used
when ....
That's confusing.
I'd combine the two together, to something like below:
Vector Rx/Tx callbacks will be used when:
* ``txq_flags`` is set to 0xf01, which implies
* No multiple segments
* No offload support
* Mergeable Rx buffers is disabled.
--yliu
> +
> +Example of using the simple version of the virtio poll mode driver in
> ``testpmd``::
> +
> + testpmd -c 0x7 -n 4 -- -i --txqflags=0xF01 --rxq=1 --txq=1 --nb-cores=1
> --
> 2.5.0
