From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Zhihong Wang <zhihong.wang@intel.com>
Cc: dev@dpdk.org, bruce.richardson@intel.com, john.mcnamara@intel.com
Subject: Re: [dpdk-dev] [PATCH v2] doc: virtio pmd versions
Date: Wed, 29 Jun 2016 11:27:02 +0800 [thread overview]
Message-ID: <20160629032702.GB23111@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <1465948397-142613-1-git-send-email-zhihong.wang@intel.com>
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@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
next prev parent reply other threads:[~2016-06-29 3:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-21 3:55 [dpdk-dev] [PATCH] " Zhihong Wang
2016-06-09 12:35 ` Mcnamara, John
2016-06-09 12:52 ` Richardson, Bruce
2016-06-09 12:56 ` Mcnamara, John
2016-06-15 6:59 ` Wang, Zhihong
2016-06-14 23:53 ` [dpdk-dev] [PATCH v2] " Zhihong Wang
2016-06-24 16:03 ` Mcnamara, John
2016-06-29 3:27 ` Yuanhan Liu [this message]
2016-07-01 3:28 ` [dpdk-dev] [PATCH v3] doc: virtio PMD Rx/Tx callbacks Zhihong Wang
2016-07-04 2:56 ` Yuanhan Liu
2016-07-04 3:00 ` Wang, Zhihong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160629032702.GB23111@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=john.mcnamara@intel.com \
--cc=zhihong.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).