[dpdk-dev] [PATCH V2 2/2] virtio: support IOMMU platform
On 2016?10?11? 12:14, Yuanhan Liu wrote: > On Fri, Oct 07, 2016 at 07:24:44AM +0300, Michael S. Tsirkin wrote: >> On Wed, Sep 28, 2016 at 04:25:12PM +0800, Jason Wang wrote: >>> Negotiate VIRTIO_F_IOMMU_PLATFORM to have IOMMU support. >>> >>> Signed-off-by: Jason Wang >>> --- >>> Changes from v1: >>> - remove unnecessary NEED_MAPPING flag >> One thing we probably should do is enable this flag >> with VFIO but not with UIO or VFIO-noiommu. > Good suggestion. I think we could do that in another patch. Yes. > >>> --- >>> drivers/net/virtio/virtio_ethdev.h | 3 ++- >>> drivers/net/virtio/virtio_pci.h| 3 ++- >>> 2 files changed, 4 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/net/virtio/virtio_ethdev.h >>> b/drivers/net/virtio/virtio_ethdev.h >>> index 2ecec6e..04a06e2 100644 >>> --- a/drivers/net/virtio/virtio_ethdev.h >>> +++ b/drivers/net/virtio/virtio_ethdev.h >>> @@ -63,7 +63,8 @@ >>> 1u << VIRTIO_NET_F_CTRL_RX | \ >>> 1u << VIRTIO_NET_F_CTRL_VLAN | \ >>> 1u << VIRTIO_NET_F_MRG_RXBUF | \ >>> -1ULL << VIRTIO_F_VERSION_1) >>> +1ULL << VIRTIO_F_VERSION_1 | \ >>> +1ULL << VIRTIO_F_IOMMU_PLATFORM ) >> Space before ) looks kind of ugly. > Yes, a bit. I will remove it while apply. > >>> #define VIRTIO_TRANSPORT_F_START 28 >>> -#define VIRTIO_TRANSPORT_F_END 32 >>> +#define VIRTIO_TRANSPORT_F_END 34 >>> >> This seems unused. Drop it? > Indeed. I will submit a patch to remove both (_START and _END). > > --yliu Thanks
[dpdk-dev] [PATCH V2 2/2] virtio: support IOMMU platform
On 2016?10?07? 12:24, Michael S. Tsirkin wrote: > On Wed, Sep 28, 2016 at 04:25:12PM +0800, Jason Wang wrote: >> Negotiate VIRTIO_F_IOMMU_PLATFORM to have IOMMU support. >> >> Signed-off-by: Jason Wang >> --- >> Changes from v1: >> - remove unnecessary NEED_MAPPING flag > One thing we probably should do is enable this flag > with VFIO but not with UIO or VFIO-noiommu. Sounds good, will try do it in next version. >> --- >> drivers/net/virtio/virtio_ethdev.h | 3 ++- >> drivers/net/virtio/virtio_pci.h| 3 ++- >> 2 files changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/virtio/virtio_ethdev.h >> b/drivers/net/virtio/virtio_ethdev.h >> index 2ecec6e..04a06e2 100644 >> --- a/drivers/net/virtio/virtio_ethdev.h >> +++ b/drivers/net/virtio/virtio_ethdev.h >> @@ -63,7 +63,8 @@ >> 1u << VIRTIO_NET_F_CTRL_RX | \ >> 1u << VIRTIO_NET_F_CTRL_VLAN | \ >> 1u << VIRTIO_NET_F_MRG_RXBUF | \ >> - 1ULL << VIRTIO_F_VERSION_1) >> + 1ULL << VIRTIO_F_VERSION_1 | \ >> + 1ULL << VIRTIO_F_IOMMU_PLATFORM ) > Space before ) looks kind of ugly. Will fix this. > >> >> /* >>* CQ function prototype >> diff --git a/drivers/net/virtio/virtio_pci.h >> b/drivers/net/virtio/virtio_pci.h >> index 3430a39..0aa0015 100644 >> --- a/drivers/net/virtio/virtio_pci.h >> +++ b/drivers/net/virtio/virtio_pci.h >> @@ -138,6 +138,7 @@ struct virtnet_ctl; >> #define VIRTIO_RING_F_INDIRECT_DESC28 >> >> #define VIRTIO_F_VERSION_1 32 >> +#define VIRTIO_F_IOMMU_PLATFORM 33 >> >> /* >>* Some VirtIO feature bits (currently bits 28 through 31) are >> @@ -145,7 +146,7 @@ struct virtnet_ctl; >>* rest are per-device feature bits. >>*/ >> #define VIRTIO_TRANSPORT_F_START 28 >> -#define VIRTIO_TRANSPORT_F_END 32 >> +#define VIRTIO_TRANSPORT_F_END 34 >> > This seems unused. Drop it? Ok. > >> /* The Guest publishes the used index for which it expects an interrupt >>* at the end of the avail ring. Host should ignore the avail->flags >> field. */ >> -- >> 2.7.4
[dpdk-dev] [PATCH 2/2] virtio: support IOMMU platform
On 2016?09?06? 15:46, Yuanhan Liu wrote: > Oops, seems I failed to send it out (I happened to know it when > I was checking the patchwork status: I didn't find my comment). > > I also happened to find out that I failed to receive quite many > emails, including some patches. Seems something went wrong :( > > --yliu > > On Mon, Sep 05, 2016 at 03:16:26PM +0800, Yuanhan Liu wrote: >> On Fri, Sep 02, 2016 at 02:37:00PM +0800, Jason Wang wrote: >>> Virtio pmd doesn't support VFIO in the past since devices bypass IOMMU >>> completely. But recently, the work of making virtio device work with >>> IOMMU is near to complete. So this patch make pmd support IOMMU by: >>> >>> - Allow VFIO mapping by setting RTE_PCI_DRV_NEED_MAPPING flag >> I think that's not needed, since virtio_read_caps() invokes >> rte_eal_pci_map_device(). >> >> --yliu Right. Thanks.
[dpdk-dev] [PATCH 1/2] net/virtio: support modern device id
On 2016?09?02? 20:57, Thomas Monjalon wrote: > 2016-09-02 14:36, Jason Wang: >> Spec said "The PCI Device ID is calculated by adding 0x1040 to the >> Virtio Device ID". So this patch makes pmd can recognize modern virtio >> net id. > Please could you describe what is a modern virtio-net? I think it means the device that only support virtio 1.0. > >> #define VIRTIO_PCI_DEVICEID_MIN 0x1000 >> #define VIRTIO_PCI_DEVICEID_MAX 0x103F >> +#define VIRTIO_PCI_MODERN_DEVICEID_NET 0x1041 > It doesn't match the sentence above: 1000 + 1040 = 2040 According to the spec (5.1.1), Virtio Device id (not pci device id) is 1. > > By the way, VIRTIO_PCI_DEVICEID_MAX is not used in the code. > Yes, we can remove this. Thanks
[dpdk-dev] [PATCH 2/2] virtio: support IOMMU platform
On 2016?09?04? 16:08, Alejandro Lucero wrote: > I know RedHat is working on a vIOMMU so I guess this work is related > to that effort, but it is a surprise virtio using IOMMU. I thought > IOMMU just made sense when using SRIOV. My second guess is using IOMMU > with virtio is a matter of security, but by other hand, virtio + IOMMU > could imply serious performance degradation when multiple VMs are in use. We will use qemu vIOMMU for virito, so there's no such issue. > I'm talking about IOMMU contention, exactly about IOTLB contention. I thought device IOTLB (ATS) was just designed to solve this contention. > This performance issue is complex to describe or even analyze as there > are several factors having an impact on it. For example, 1GB hugepages > can avoid most of it and the same if TX & RX rings are not bigger than > 256. So, my question: is RedHat aware of this potential IOMMU > contention which can limit scalability? For virtio, we use vIOMMU per VM and implement a device IOTLB in vhost side. Technically, it does not have such issue I think. Thanks > > On Fri, Sep 2, 2016 at 6:26 PM, Michael S. Tsirkin <mailto:mst at redhat.com>> wrote: > > On Fri, Sep 02, 2016 at 03:04:56PM +0200, Thomas Monjalon wrote: > > 2016-09-02 14:37, Jason Wang: > > > Virtio pmd doesn't support VFIO in the past since devices > bypass IOMMU > > > completely. But recently, the work of making virtio device > work with > > > IOMMU is near to complete. > > > > Good news! > > What are the requirements for Qemu and Linux version numbers please? > > I expect QEMU 2.8 and Linux 4.8 to have the support. > >
[dpdk-dev] [PATCH 2/2] virtio: support IOMMU platform
On 2016?09?02? 21:04, Thomas Monjalon wrote: > 2016-09-02 14:37, Jason Wang: >> Virtio pmd doesn't support VFIO in the past since devices bypass IOMMU >> completely. But recently, the work of making virtio device work with >> IOMMU is near to complete. > Good news! > What are the requirements for Qemu and Linux version numbers please? Linux 4.8 has support for this. For qemu, it will support this for 2.8. Thanks
[dpdk-dev] [PATCH 2/2] virtio: support IOMMU platform
On 2016?09?02? 21:04, Thomas Monjalon wrote: > 2016-09-02 14:37, Jason Wang: >> Virtio pmd doesn't support VFIO in the past since devices bypass IOMMU >> completely. But recently, the work of making virtio device work with >> IOMMU is near to complete. > Good news! > What are the requirements for Qemu and Linux version numbers please? Linux(vhost) support was in 4.8. Qemu support will be ready at 2.8 Thanks
[dpdk-dev] [PATCH 2/2] virtio: support IOMMU platform
Virtio pmd doesn't support VFIO in the past since devices bypass IOMMU
completely. But recently, the work of making virtio device work with
IOMMU is near to complete. So this patch make pmd support IOMMU by:
- Allow VFIO mapping by setting RTE_PCI_DRV_NEED_MAPPING flag
- Negotiate feature VIRTIO_F_IOMMU_PLATFORM
Signed-off-by: Jason Wang
---
drivers/net/virtio/virtio_ethdev.c | 2 +-
drivers/net/virtio/virtio_ethdev.h | 3 ++-
drivers/net/virtio/virtio_pci.h| 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index f48e037..0d6d4d2 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1307,7 +1307,7 @@ static struct eth_driver rte_virtio_pmd = {
.pci_drv = {
.name = "rte_virtio_pmd",
.id_table = pci_id_virtio_map,
- .drv_flags = RTE_PCI_DRV_DETACHABLE,
+ .drv_flags = RTE_PCI_DRV_DETACHABLE | RTE_PCI_DRV_NEED_MAPPING,
},
.eth_dev_init = eth_virtio_dev_init,
.eth_dev_uninit = eth_virtio_dev_uninit,
diff --git a/drivers/net/virtio/virtio_ethdev.h
b/drivers/net/virtio/virtio_ethdev.h
index 2ecec6e..04a06e2 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -63,7 +63,8 @@
1u << VIRTIO_NET_F_CTRL_RX | \
1u << VIRTIO_NET_F_CTRL_VLAN | \
1u << VIRTIO_NET_F_MRG_RXBUF | \
-1ULL << VIRTIO_F_VERSION_1)
+1ULL << VIRTIO_F_VERSION_1 | \
+1ULL << VIRTIO_F_IOMMU_PLATFORM )
/*
* CQ function prototype
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index d3bdfa0..dd74c0f 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -139,6 +139,7 @@ struct virtnet_ctl;
#define VIRTIO_RING_F_INDIRECT_DESC28
#define VIRTIO_F_VERSION_1 32
+#define VIRTIO_F_IOMMU_PLATFORM33
/*
* Some VirtIO feature bits (currently bits 28 through 31) are
@@ -146,7 +147,7 @@ struct virtnet_ctl;
* rest are per-device feature bits.
*/
#define VIRTIO_TRANSPORT_F_START 28
-#define VIRTIO_TRANSPORT_F_END 32
+#define VIRTIO_TRANSPORT_F_END 34
/* The Guest publishes the used index for which it expects an interrupt
* at the end of the avail ring. Host should ignore the avail->flags field. */
--
2.7.4
[dpdk-dev] [PATCH 1/2] net/virtio: support modern device id
Spec said "The PCI Device ID is calculated by adding 0x1040 to the
Virtio Device ID". So this patch makes pmd can recognize modern virtio
net id.
Signed-off-by: Jason Wang
---
drivers/net/virtio/virtio_ethdev.c | 1 +
drivers/net/virtio/virtio_pci.h| 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 07d6449..f48e037 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -104,6 +104,7 @@ static int virtio_dev_queue_stats_mapping_set(
*/
static const struct rte_pci_id pci_id_virtio_map[] = {
{ RTE_PCI_DEVICE(VIRTIO_PCI_VENDORID, VIRTIO_PCI_DEVICEID_MIN) },
+ { RTE_PCI_DEVICE(VIRTIO_PCI_VENDORID, VIRTIO_PCI_MODERN_DEVICEID_NET) },
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index dd7693f..d3bdfa0 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -46,6 +46,7 @@ struct virtnet_ctl;
#define VIRTIO_PCI_VENDORID 0x1AF4
#define VIRTIO_PCI_DEVICEID_MIN 0x1000
#define VIRTIO_PCI_DEVICEID_MAX 0x103F
+#define VIRTIO_PCI_MODERN_DEVICEID_NET 0x1041
/* VirtIO ABI version, this must match exactly. */
#define VIRTIO_PCI_ABI_VERSION 0
--
2.7.4
[dpdk-dev] [PATCH v4 08/14] virtio: pci: extend virtio pci rw api for vfio interface
On 01/14/2016 09:28 PM, Santosh Shukla wrote:
> So far virtio handle rw access for uio / ioport interface, This patch to
> extend
> the support for vfio interface. For that introducing private struct
> virtio_vfio_dev{
> - is_vfio
> - pci_dev
> };
> Signed-off-by: Santosh Shukla
> ---
> v3->v4:
> - Removed #indef RTE_EAL_VFIO and made it arch agnostic such now virtio_pci
> rd/wr api to handle both vfio and ig_uio/ioport interfaces, depending upon
> is_vfio flags set or unset.
> - Tested for x86 for igb_uio and vfio interface, also tested for arm64 for
> vfio
> interface.
>
> drivers/net/virtio/virtio_pci.h | 84 ---
> 1 file changed, 70 insertions(+), 14 deletions(-)
Interesting. I'm working on IOMMU cooperation with virtio[1]. For pmd,
it looks like the only thing missed is RTE_PCI_DRV_NEED_MAPPING for
virito-net pmd.
So I'm curious whether this is still necessary if IOMMU can work with
virito in the future.
[1] https://www.mail-archive.com/qemu-devel at nongnu.org/msg337079.html
Thanks
>
> diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
> index 8b5b031..8526c07 100644
> --- a/drivers/net/virtio/virtio_pci.h
> +++ b/drivers/net/virtio/virtio_pci.h
> @@ -46,6 +46,8 @@
> #endif
>
> #include
> +#include
> +#include "virtio_vfio_rw.h"
>
> struct virtqueue;
>
> @@ -165,6 +167,14 @@ struct virtqueue;
> */
> #define VIRTIO_MAX_VIRTQUEUES 8
>
> +/* For vfio only */
> +struct virtio_vfio_dev {
> + boolis_vfio;/* True: vfio i/f,
> + * False: not a vfio i/f
> + */
> + struct rte_pci_device *pci_dev; /* vfio dev */
> +};
> +
> struct virtio_hw {
> struct virtqueue *cvq;
> uint32_tio_base;
> @@ -176,6 +186,7 @@ struct virtio_hw {
> uint8_t use_msix;
> uint8_t started;
> uint8_t mac_addr[ETHER_ADDR_LEN];
> + struct virtio_vfio_dev dev;
> };
>
> /*
> @@ -231,20 +242,65 @@ outl_p(unsigned int data, unsigned int port)
> #define VIRTIO_PCI_REG_ADDR(hw, reg) \
> (unsigned short)((hw)->io_base + (reg))
>
> -#define VIRTIO_READ_REG_1(hw, reg) \
> - inb((VIRTIO_PCI_REG_ADDR((hw), (reg
> -#define VIRTIO_WRITE_REG_1(hw, reg, value) \
> - outb_p((unsigned char)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
> -
> -#define VIRTIO_READ_REG_2(hw, reg) \
> - inw((VIRTIO_PCI_REG_ADDR((hw), (reg
> -#define VIRTIO_WRITE_REG_2(hw, reg, value) \
> - outw_p((unsigned short)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
> -
> -#define VIRTIO_READ_REG_4(hw, reg) \
> - inl((VIRTIO_PCI_REG_ADDR((hw), (reg
> -#define VIRTIO_WRITE_REG_4(hw, reg, value) \
> - outl_p((unsigned int)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
> +#define VIRTIO_READ_REG_1(hw, reg) \
> +({ \
> + uint8_t ret;\
> + struct virtio_vfio_dev *vdev; \
> + (vdev) = (&(hw)->dev); \
> + (((vdev)->is_vfio) ?\
> + (ioport_inb(((vdev)->pci_dev), reg, )) :\
> + ((ret) = (inb((VIRTIO_PCI_REG_ADDR((hw), (reg))); \
> + ret;\
> +})
> +
> +#define VIRTIO_WRITE_REG_1(hw, reg, value) \
> +({ \
> + struct virtio_vfio_dev *vdev; \
> + (vdev) = (&(hw)->dev); \
> + (((vdev)->is_vfio) ?\
> + (ioport_outb_p(((vdev)->pci_dev), reg, (uint8_t)(value))) : \
> + (outb_p((unsigned char)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg)); \
> +})
> +
> +#define VIRTIO_READ_REG_2(hw, reg) \
> +({ \
> + uint16_t ret; \
> + struct virtio_vfio_dev *vdev; \
> + (vdev) = (&(hw)->dev); \
> + (((vdev)->is_vfio) ?\
> + (ioport_inw(((vdev)->pci_dev), reg, )) :\
> + ((ret) = (inw((VIRTIO_PCI_REG_ADDR((hw), (reg))); \
> + ret;\
> +})
> +
> +#define VIRTIO_WRITE_REG_2(hw, reg, value) \
> +({ \
> + struct virtio_vfio_dev *vdev; \
> + (vdev) = (&(hw)->dev);
[dpdk-dev] [PATCH v7 4/8] vhost: rxtx: use queue id instead of constant ring index
On 11/17/2015 04:23 PM, Michael S. Tsirkin wrote: > On Mon, Nov 16, 2015 at 02:20:57PM -0800, Flavio Leitner wrote: >> > On Wed, Oct 28, 2015 at 11:12:25PM +0200, Michael S. Tsirkin wrote: >>> > > On Wed, Oct 28, 2015 at 06:30:41PM -0200, Flavio Leitner wrote: > > > On Sat, Oct 24, 2015 at 08:47:10PM +0300, Michael S. Tsirkin wrote: > > > > > On Sat, Oct 24, 2015 at 12:34:08AM -0200, Flavio Leitner wrote: >> > > > > > On Thu, Oct 22, 2015 at 02:32:31PM +0300, Michael S. Tsirkin >> > > > > > wrote: >>> > > > > > > On Thu, Oct 22, 2015 at 05:49:55PM +0800, Yuanhan Liu wrote: > > > > > > > On Wed, Oct 21, 2015 at 05:26:18PM +0300, Michael S. > > > > > > > Tsirkin wrote: > > > > > > > > > On Wed, Oct 21, 2015 at 08:48:15PM +0800, Yuanhan Liu > > > > > > > > > wrote: >>> > > > > > > > > > > Please note that for virtio devices, guest is >>> > > > > > > > > > > supposed to >>> > > > > > > > > > > control the placement of incoming packets in RX >>> > > > > > > > > > > queues. >> > > > > > > > > > >> > > > > > > > > > I may not follow you. >> > > > > > > > > > >> > > > > > > > > > Enqueuing packets to a RX queue is done at vhost >> > > > > > > > > > lib, outside the >> > > > > > > > > > guest, how could the guest take the control here? >> > > > > > > > > > >> > > > > > > > > >--yliu > > > > > > > > > > > > > > > > > > vhost should do what guest told it to. > > > > > > > > > > > > > > > > > > See virtio spec: > > > > > > > > > 5.1.6.5.5 Automatic receive steering in > > > > > > > > > multiqueue mode > > > > > > > > > > > > > > Spec says: > > > > > > > > > > > > > > After the driver transmitted a packet of a flow on > > > > > > > transmitqX, > > > > > > > the device SHOULD cause incoming packets for that > > > > > > > flow to be > > > > > > > steered to receiveqX. > > > > > > > > > > > > > > > > > > > > > Michael, I still have no idea how vhost could know the > > > > > > > flow even > > > > > > > after discussion with Huawei. Could you be more specific > > > > > > > about > > > > > > > this? Say, how could guest know that? And how could > > > > > > > guest tell > > > > > > > vhost which RX is gonna to use? > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > --yliu >>> > > > > > > >>> > > > > > > I don't really understand the question. >>> > > > > > > >>> > > > > > > When guests transmits a packet, it makes a decision >>> > > > > > > about the flow to use, and maps that to a tx/rx pair of >>> > > > > > > queues. >>> > > > > > > >>> > > > > > > It sends packets out on the tx queue and expects device to >>> > > > > > > return packets from the same flow on the rx queue. >> > > > > > >> > > > > > Why? I can understand that there should be a mapping between >> > > > > > flows and queues in a way that there is no re-ordering, but >> > > > > > I can't see the relation of receiving a flow with a TX queue. >> > > > > > >> > > > > > fbl > > > > > > > > > > That's the way virtio chose to program the rx steering logic. > > > > > > > > > > It's low overhead (no special commands), and > > > > > works well for TCP when user is an endpoint since rx and tx > > > > > for tcp are generally tied (because of ack handling). >> > >> > It is low overhead for the control plane, but not for the data plane. > Well, there's zero data plane overhead within the guest. > You can't go lower :) > > > > > > We can discuss other ways, e.g. special commands for guests to > > > > > program steering. > > > > > We'd have to first see some data showing the current scheme > > > > > is problematic somehow. >> > >> > The issue is that the spec assumes the packets are coming in >> > a serialized way and the distribution will be made by vhost-user >> > but that isn't necessarily true. >> > > Making the distribution guest controlled is obviously the right > thing to do if guest is the endpoint: we need guest scheduler to > make the decisions, it's the only entity that knows > how are tasks distributed across VCPUs. > > It's possible that this is not the right thing for when guest > is just doing bridging between two VNICs: > are you saying packets should just go from RX queue N > on eth0 to TX queue N on eth1, making host make all > the queue selection decisions? The problem looks like current automatic steering policy is not flexible for all kinds of workload in guest. So we can implement the feature of ntuple filters and export the interfaces to let guest/drivers to decide. > > This sounds reasonable. Since
[dpdk-dev] Poor Virtio PMD TX Performance
On 06/12/2015 05:35 PM, Zhou, Tianlin wrote: > Hi Changchun, > > Thanks for your response. > Please see my embedded comments. > > What kind of vhost in your test? Linux vhost or dpdk user space vhost? > [tzhou] We use Linux vhost. > > Do you enable the dump/log in your test? It will decrease perf of vritio. > [tzhou] No, I did not enable dump/log in the performance testing. > I just opened log to debug why drop packets and then close it for higher > performance. > > > Which version of dpdk codes are you using? The tip codes in dpdk.org? > [tzhou] I used DPDK 2.0.0 and l2fwd in DPDK 2.0.0. > l2fwd start command: ./l2fwd -c 0x2 -n 1 --p 0x1 > > qemu start command (I used the virtio interface for RX/TX in GUEST): > sudo kvm -m 4096M -smp 4 -hda /home/geo/yanghe/fedora20.qcow2 -boot d > -daemonize -monitor \ telnet::10024,server,nowait,nodelay \ -cpu host \ > -device e1000,netdev=public0,mac=00:0c:29:e1:f3:ff -netdev > user,id=public0,hostfwd=tcp::11022-:22 \ -device > virtio-net-pci,netdev=public1,mac=00:0c:29:e1:ff:ff,ioeventfd=on -netdev > tap,id=public1,ifname=tapvm02,script=/home/geo/tzhou/kvm-image/tup.sh,downscript=no,vhost=on To enable vhost for pmd I believe you need use vhostforce=on here. > > The qemu version? > [tzhou] > root at dw-2:/home/geo/tzhou/kvm-image# kvm -version QEMU emulator version > 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.3), Copyright (c) 2003-2008 Fabrice Bellard > > -Tianlin > > -Original Message- > From: Ouyang, Changchun [mailto:changchun.ouyang at intel.com] > Sent: Monday, June 08, 2015 10:13 AM > To: Zhou, Tianlin > Cc: Ouyang, Changchun > Subject: RE: Poor Virtio PMD TX Performance > > Hi tianlin, > > What kind of vhost in your test? Linux vhost or dpdk user space vhost? > > Do you enable the dump/log in your test? It will decrease perf of vritio. > > Which version of dpdk codes are you using? The tip codes in dpdk.org? > > The qemu version? > > Thanks for inputs > Changchun > > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhou, Tianlin >> Sent: Friday, June 5, 2015 5:23 PM >> To: dev at dpdk.org >> Subject: [dpdk-dev] Poor Virtio PMD TX Performance >> >> Hi there, >> >> We tested TX performance of Virtio PMD by DPDK l2fwd, but found even >> at 60KPPS (720B packet length) TX rate, there is 1/1000 packet dropping rate. >> The log shows "No free tx descriptors to transmit" in Virtio PMD. >> Increasing TX queues by modifying DPDK l2fwd can decreases packet >> dropping rate, but can't ensure no packet dropping unless >> retransmitting packets that can't be sent successfully. >> Oppositely, RX rate can be 600KPPS without packet dropping. >> >> Test Env >> - Host CPU: 4 cores, 2127.770MHz >> - Host Memory: 8G >> - Host OS: Linux dw-2 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 >> 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >> - Guest CPU: 4 cores, 2127.770MHz >> - Guest Memory: 4G >> - Guest OS: fedora20 >> >> Anybody here face the same problem? >> >> -Tianlin
