[dpdk-dev] [PATCH v2 2/2] vhost: Add VHOST PMD

2015-11-06 Thread Tetsuya Mukawa
On 2015/11/06 11:22, Yuanhan Liu wrote:
> On Mon, Nov 02, 2015 at 12:58:57PM +0900, Tetsuya Mukawa wrote:
> ...
>> +
>> +static uint16_t
>> +eth_vhost_rx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
>> +{
>> +struct vhost_queue *r = q;
>> +uint16_t nb_rx = 0;
>> +
>> +if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0))
>> +return 0;
>> +
>> +rte_atomic32_set(&r->while_queuing, 1);
>> +
>> +if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0))
>> +goto out;
>> +
>> +/* Dequeue packets from guest TX queue */
>> +nb_rx = (uint16_t)rte_vhost_dequeue_burst(r->device,
>> +VIRTIO_TXQ, r->mb_pool, bufs, nb_bufs);
>> +
>> +r->rx_pkts += nb_rx;
>> +
>> +out:
>> +rte_atomic32_set(&r->while_queuing, 0);
>> +
>> +return nb_rx;
>> +}
>> +
>> +static uint16_t
>> +eth_vhost_tx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
>> +{
>> +struct vhost_queue *r = q;
>> +uint16_t i, nb_tx = 0;
>> +
>> +if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0))
>> +return 0;
>> +
>> +rte_atomic32_set(&r->while_queuing, 1);
>> +
>> +if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0))
>> +goto out;
>> +
>> +/* Enqueue packets to guest RX queue */
>> +nb_tx = (uint16_t)rte_vhost_enqueue_burst(r->device,
>> +VIRTIO_RXQ, bufs, nb_bufs);
>> +
> Michael, I'm wondering here might be the better place to do "automatic
> receive steering in multiqueue mode". I mean, as a library function,
> queueing/dequeueing packets to/from a specific virt queue is reasonable
> to me. It's upto the caller to pick the right queue, doing the queue
> steering.

Hi Liu,

Oops, I've found a bug here.
To support multiple queues in vhost PMD, I needed to store "queue_id" in
"vhost_queue" structure.
Then, I should call rte_vhost_enqueue_burst() with the value.

> As an eth dev, I guess that's the proper place to do things like that.
>
> Or, I'm thinking we could introduce another vhost function, for not
> breaking current API, to do that, returning the right queue, so that
> other applications (instead of the vhost pmd only) can use that as well.

I may not understand the steering function enough, but If we support the
steering function in vhost library or vhost PMD, how can we handle
"queue_id" parameter of TX functions?
Probably, we need to ignore the value In some cases.
This may confuse the users because they cannot observe the packets in
their specified queue.

So I guess it may be application responsibility to return packets to the
correct queue.
(But we should write a correct documentation about it)

> Tetsuya, just in case you missed the early discussion about automic
> receive steering, here is a link:
>
>   http://dpdk.org/ml/archives/dev/2015-October/025779.html
>

Thanks, I've checked it!

Tetsuya



[dpdk-dev] [PATCH v2 2/2] vhost: Add VHOST PMD

2015-11-06 Thread Yuanhan Liu
On Mon, Nov 02, 2015 at 12:58:57PM +0900, Tetsuya Mukawa wrote:
...
> +
> +static uint16_t
> +eth_vhost_rx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
> +{
> + struct vhost_queue *r = q;
> + uint16_t nb_rx = 0;
> +
> + if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0))
> + return 0;
> +
> + rte_atomic32_set(&r->while_queuing, 1);
> +
> + if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0))
> + goto out;
> +
> + /* Dequeue packets from guest TX queue */
> + nb_rx = (uint16_t)rte_vhost_dequeue_burst(r->device,
> + VIRTIO_TXQ, r->mb_pool, bufs, nb_bufs);
> +
> + r->rx_pkts += nb_rx;
> +
> +out:
> + rte_atomic32_set(&r->while_queuing, 0);
> +
> + return nb_rx;
> +}
> +
> +static uint16_t
> +eth_vhost_tx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
> +{
> + struct vhost_queue *r = q;
> + uint16_t i, nb_tx = 0;
> +
> + if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0))
> + return 0;
> +
> + rte_atomic32_set(&r->while_queuing, 1);
> +
> + if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0))
> + goto out;
> +
> + /* Enqueue packets to guest RX queue */
> + nb_tx = (uint16_t)rte_vhost_enqueue_burst(r->device,
> + VIRTIO_RXQ, bufs, nb_bufs);
> +

Michael, I'm wondering here might be the better place to do "automatic
receive steering in multiqueue mode". I mean, as a library function,
queueing/dequeueing packets to/from a specific virt queue is reasonable
to me. It's upto the caller to pick the right queue, doing the queue
steering.

As an eth dev, I guess that's the proper place to do things like that.

Or, I'm thinking we could introduce another vhost function, for not
breaking current API, to do that, returning the right queue, so that
other applications (instead of the vhost pmd only) can use that as well.

Tetsuya, just in case you missed the early discussion about automic
receive steering, here is a link:

  http://dpdk.org/ml/archives/dev/2015-October/025779.html


--yliu


[dpdk-dev] [PATCH v2 2/2] vhost: Add VHOST PMD

2015-11-02 Thread Tetsuya Mukawa
The patch introduces a new PMD. This PMD is implemented as thin wrapper
of librte_vhost. It means librte_vhost is also needed to compile the PMD.
The vhost messages will be handled only when a port is started. So start
a port first, then invoke QEMU.

The PMD has 2 parameters.
 - iface:  The parameter is used to specify a path to connect to a
   virtio-net device.
 - queues: The parameter is used to specify the number of the queues
   virtio-net device has.
   (Default: 1)

Here is an example.
$ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i

To connect above testpmd, here is qemu command example.

$ qemu-system-x86_64 \

-chardev socket,id=chr0,path=/tmp/sock0 \
-netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \
-device virtio-net-pci,netdev=net0

Signed-off-by: Tetsuya Mukawa 
---
 config/common_linuxapp  |   6 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/nics/vhost.rst   |  82 +++
 doc/guides/rel_notes/release_2_2.rst|   2 +
 drivers/net/Makefile|   4 +
 drivers/net/vhost/Makefile  |  62 +++
 drivers/net/vhost/rte_eth_vhost.c   | 765 
 drivers/net/vhost/rte_eth_vhost.h   |  65 +++
 drivers/net/vhost/rte_pmd_vhost_version.map |   8 +
 mk/rte.app.mk   |   8 +-
 10 files changed, 1002 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/nics/vhost.rst
 create mode 100644 drivers/net/vhost/Makefile
 create mode 100644 drivers/net/vhost/rte_eth_vhost.c
 create mode 100644 drivers/net/vhost/rte_eth_vhost.h
 create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map

diff --git a/config/common_linuxapp b/config/common_linuxapp
index c1d4bbd..fd103e7 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -457,6 +457,12 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n
 CONFIG_RTE_LIBRTE_VHOST_DEBUG=n

 #
+# Compile vhost PMD
+# To compile, CONFIG_RTE_LIBRTE_VHOST should be enabled.
+#
+CONFIG_RTE_LIBRTE_PMD_VHOST=y
+
+#
 #Compile Xen domain0 support
 #
 CONFIG_RTE_LIBRTE_XEN_DOM0=n
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 2d4936d..57d1041 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -47,6 +47,7 @@ Network Interface Controller Drivers
 mlx4
 mlx5
 virtio
+vhost
 vmxnet3
 pcap_ring

diff --git a/doc/guides/nics/vhost.rst b/doc/guides/nics/vhost.rst
new file mode 100644
index 000..2ec8d79
--- /dev/null
+++ b/doc/guides/nics/vhost.rst
@@ -0,0 +1,82 @@
+..  BSD LICENSE
+Copyright(c) 2015 IGEL Co., Ltd.. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of IGEL Co., Ltd. nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Poll Mode Driver that wraps vhost library
+=
+
+This PMD is a thin wrapper of the DPDK vhost library.
+The User can handle virtqueues as one of normal DPDK port.
+
+Vhost Implementation in DPDK
+
+
+Please refer to Chapter "Vhost Library" of Programmer's Guide to know detail 
of vhost.
+
+Features and Limitations of vhost PMD
+-
+
+In this release, the vhost PMD provides the basic functionality of packet 
reception and transmission.
+
+*   It provides the function to convert port_id to a pointer of virtio_net 
device.
+It allows the user to use vhost library with the PMD in parallel.
+
+*   It