[dpdk-dev] [PATCH 0/4] virtio support for container

Hi Amit, On 1/14/2016 5:34 PM, Amit Tomer wrote: > Hello, > >> Can you send out how you start this l2fwd program? > This is how, I run l2fwd program. > > CMD ["/usr/src/dpdk/examples/l2fwd/build/l2fwd", "-c", "0x3", "-n", > "4","--no-pci", >

[dpdk-dev] [PATCH v4 14/14] vfio: Support for no-IOMMU mode

From: Anatoly Burakov This commit is adding a generic mechanism to support multiple IOMMU types. For now, it's only type 1 (x86 IOMMU) and no-IOMMU (a special VFIO mode that doesn't use IOMMU at all), but it's easily extended by adding necessary definitions into

[dpdk-dev] [PATCH v4 13/14] virtio: enable vfio in pmd driver

Using mapping api i.e. rte_eal_pci_map_device() to create vfio container, group id and get the vfio-dev-fd for virtio-net-pci interface. Later vfio_dev_fd used for virtio device rd/wr operation. Signed-off-by: Santosh Shukla --- v3->v4: - Per stephens comment, removed static driver flag

[dpdk-dev] [PATCH v4 12/14] eal: pci: export pci_[un]map_device

From: Yuanhan Liu Normally we could set RTE_PCI_DRV_NEED_MAPPING flag so that eal will invoke pci_map_device internally for us. From that point view, there is no need to export pci_map_device. However, for virtio pmd driver, which is designed to work without binding

[dpdk-dev] [PATCH v4 11/14] config: armv7/v8: Enable RTE_LIBRTE_VIRTIO_PMD

Enable RTE_LIBRTE_VIRTIO_PMD for armv7/v8 and setting RTE_VIRTIO_INC_VEC=n. Builds successfully for armv7/v8. Signed-off-by: Santosh Shukla --- v2->v4: - Removed explict setting of VIRTIO_PMD in configs (per review comment from Jiangbo) config/defconfig_arm-armv7a-linuxapp-gcc |4 +++-

[dpdk-dev] [PATCH v4 10/14] virtio: pci: add dummy func definition for in/outb for non-x86 arch

For non-x86 arch, Compiler will throw build error for in/out apis. Including dummy api function so to pass build. Note that: For virtio to work for non-x86 arch - RTE_EAL_VFIO is the only supported method. RTE_EAL_IGB_UIO is not supported for non-x86 arch. So, Virtio support for arch and

[dpdk-dev] [PATCH v4 09/14] virtio: ethdev: check for vfio interface

Introducing api to check interface type is vfio or not, if interface is vfio then update struct virtio_vfio_dev {}. Those two apis are: - virtio_chk_for_vfio - virtio_hw_init_by_vfio Signed-off-by: Santosh Shukla --- v3->v4: - Removed RTE_PCI_DRV_NEED_MAPPING drv flag (as per Review comment

[dpdk-dev] [PATCH v4 08/14] virtio: pci: extend virtio pci rw api for vfio interface

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

[dpdk-dev] [PATCH v4 07/14] virtio: vfio: add api support to rd/wr ioport bar

For vfio case - Use pread/pwrite api to access virtio ioport space. Signed-off-by: Santosh Shukla Signed-off-by: Rizwan Ansari Signed-off-by: Rakesh Krishnamurthy --- v3->v4: - Corrected debug error message for oub_ class of apis - renamed file from virtio_vfio.h to virtio_vfio_rw.h - Removed

[dpdk-dev] [PATCH v4 06/14] eal: pci: vfio: add rd/wr func for pci bar space

Introducing below api for pci bar space rd/wr. Currently used for pci iobar rd/wr. Api's are: - rte_eal_pci_read_bar - rte_eal_pci_write_bar virtio when used for vfio-mode then virtio driver will use these api to do rd/wr operation on ioport pci bar. Signed-off-by: Santosh Shukla --- v3->v4: -

[dpdk-dev] [PATCH v4 05/14] virtio_pci.h: build fix for sys/io.h for non-x86 arch

make sure sys/io.h used only for x86 archs. This fixes build error arm64/arm case. Signed-off-by: Santosh Shukla --- drivers/net/virtio/virtio_pci.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h index 47f722a..8b5b031

[dpdk-dev] [PATCH v4 04/14] linuxapp/vfio: ignore mapping for ioport region

vfio_pci_mmap() try to map all pci bars. ioport region are not mapped in vfio/kernel so ignore mmaping for ioport. Signed-off-by: Santosh Shukla --- v3->v4: per review comment from Stephen and Yuan. - removed ioport_bar var declaration with in func to top of func - rearrange log message to fit

[dpdk-dev] [PATCH v4 03/14] linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init()

iopl() syscall not supported in linux-arm/arm64 so always return 0 value. Signed-off-by: Santosh Shukla Suggested-by: Stephen Hemminger Acked-by: Jan Viktorin --- v3->v4: - moved #ifdef to elseif -> suggested by Stephen. lib/librte_eal/linuxapp/eal/eal.c |2 ++ 1 file changed, 2

[dpdk-dev] [PATCH v4 02/14] config: i686: set RTE_VIRTIO_INC_VECTOR=n

i686 target config example: config/defconfig_i686-native-linuxapp-gcc says "Vectorized PMD is not supported on 32-bit". So setting RTE_VIRTIO_INC_VECTOR to 'n'. Signed-off-by: Santosh Shukla --- config/defconfig_i686-native-linuxapp-gcc |1 + config/defconfig_i686-native-linuxapp-icc |

[dpdk-dev] [PATCH v4 01/14] virtio: Introduce config RTE_VIRTIO_INC_VECTOR

virtio_recv_pkts_vec and other virtio vector friend apis are written for sse/avx instructions. For arm64 in particular, virtio vector implementation does not exist(todo). So virtio pmd driver wont build for targets like i686, arm64. By making RTE_VIRTIO_INC_VECTOR=n, Driver can build for

[dpdk-dev] [PATCH v4 00/14] Add virtio support for arm/arm64

Hi, This v4 patch uses vfio-noiommu-way to access virtio-net pci interface. Tested for arm64 thunderX platform. Patch builds for x86/i386/arm/armv8/thunderX. Tested with testpmd application. Refer v3 [1] cover letter for dependancy description: Step to enable vfio-noiommu mode: - modprobe

[dpdk-dev] [RFC v2 1/2] ethdev: add packet filter flow and new behavior switch to fdir

Hi Jingjing, On Thursday, January 01/14/16, 2016 at 00:48:17 -0800, Wu, Jingjing wrote: > Hi, Rahul > > Just another thought, please consider about it: > > Add a new flow type like > > #define RTE_ETH_FLOW_IPV6_UDP_EX17 > +#define RTE_ETH_FLOW_RAW_PKT 18 > > Then add a new

[dpdk-dev] Problem with Intel i40e XL710 dpdk driver

Hi, I am seeing a "Failed to init adminq: -54" or admin queue timeouts while initializing the admin queue for i40e xl710 intel nic. (Intel server is a E5-2670) First things first. I am running the latest firmware. The kernel module is not loaded and yes, it works with the i40e kernel

[dpdk-dev] [PATCH 0/4] virtio support for container

Hello, > > Not necessary. But if you want to use hugepages inside Docker, use -v option > to map a hugetlbfs into containers. I modified Docker command line in order to make use of Hugetlbfs: CMD ["/usr/src/dpdk/examples/l2fwd/build/l2fwd", "-c", "0x3", "-n", "4","--no-pci",

[dpdk-dev] Getting error while running DPDK test app on X-Gene1

On Thu, Jan 14, 2016 at 9:45 AM, Jerin Jacob wrote: > On Wed, Jan 13, 2016 at 03:52:01PM +0530, Ankit Jindal wrote: >> Hi, >> >> We are trying to run dpdk on our arm64 based SOC having Intel 10G >> ixgbe PCIe card plugged. While running any test app, we are getting >> following error. >> >> EAL:

[dpdk-dev] [PATCH v2 7/7] virtio: add 1.0 support

Sigh... I have just send out v3 ... On Thu, Jan 14, 2016 at 07:50:00AM +, Xie, Huawei wrote: > On 1/12/2016 2:58 PM, Yuanhan Liu wrote: > > +static inline void > > +modern_write64_twopart(uint64_t val, uint32_t *lo, uint32_t *hi) > > +{ > > + modern_write32((uint32_t)val, lo); > > +

[dpdk-dev] [PATCH v2 7/7] virtio: add 1.0 support

On Thu, Jan 14, 2016 at 08:08:28AM +, Xie, Huawei wrote: > On 1/14/2016 3:58 PM, Yuanhan Liu wrote: > > On Thu, Jan 14, 2016 at 07:51:08AM +, Xie, Huawei wrote: > >> On 1/14/2016 3:49 PM, Yuanhan Liu wrote: > >>> On Thu, Jan 14, 2016 at 07:47:17AM +, Xie, Huawei wrote: > On

[dpdk-dev] VFIO no-iommu

On Thu, Jan 14, 2016 at 2:52 PM, Alex Williamson wrote: > On Thu, 2016-01-14 at 14:03 +0800, Jike Song wrote: >> On Wed, Dec 16, 2015 at 12:38 PM, Alex Williamson >> wrote: >> > >> > So it works. Is it acceptable? Useful? Sufficiently complete? Does >> > it imply deprecating the uio

[dpdk-dev] [PATCH v2 7/7] virtio: add 1.0 support

On Thu, Jan 14, 2016 at 07:51:08AM +, Xie, Huawei wrote: > On 1/14/2016 3:49 PM, Yuanhan Liu wrote: > > On Thu, Jan 14, 2016 at 07:47:17AM +, Xie, Huawei wrote: > >> On 1/12/2016 2:58 PM, Yuanhan Liu wrote: > >>> Modern (v1.0) virtio pci device defines several pci capabilities. > >> [snip]

[dpdk-dev] [PATCH v2 7/7] virtio: add 1.0 support

On Thu, Jan 14, 2016 at 07:47:17AM +, Xie, Huawei wrote: > On 1/12/2016 2:58 PM, Yuanhan Liu wrote: > > Modern (v1.0) virtio pci device defines several pci capabilities. > [snip] > > +static void > > +modern_notify_queue(struct virtio_hw *hw __rte_unused, struct virtqueue > > *vq) > > +{ > >

[dpdk-dev] [PATCH v3 6/8] eal: pci: export pci_[un]map_device

On Thu, Jan 14, 2016 at 03:42:50PM +0800, Yuanhan Liu wrote: > Normally we could set RTE_PCI_DRV_NEED_MAPPING flag so that eal will > invoke pci_map_device internally for us. From that point view, there > is no need to export pci_map_device. > > However, for virtio pmd driver, which is designed

[dpdk-dev] [PATCH v3 8/8] virtio: move VIRTIO_READ/WRITE_REG_X into virtio_pci.c

virtio_pci.c become the only file references those macros; move them there. Signed-off-by: Yuanhan Liu --- drivers/net/virtio/virtio_pci.c | 19 +++ drivers/net/virtio/virtio_pci.h | 18 -- 2 files changed, 19 insertions(+), 18 deletions(-) diff --git

[dpdk-dev] [PATCH v3 7/8] virtio: add 1.0 support

Modern (v1.0) virtio pci device defines several pci capabilities. Each cap has a configure structure corresponding to it, and the cap.bar and cap.offset fields tell us where to find it. Firstly, we map the pci resources by rte_eal_pci_map_device(). We then could easily locate to a cfg structure

[dpdk-dev] [PATCH v3 6/8] eal: pci: export pci_[un]map_device

Normally we could set RTE_PCI_DRV_NEED_MAPPING flag so that eal will invoke pci_map_device internally for us. From that point view, there is no need to export pci_map_device. However, for virtio pmd driver, which is designed to work without binding UIO (or something similar first),

[dpdk-dev] [PATCH v3 5/8] virtio: retrieve hdr_size from hw->vtnet_hdr_size

The mergeable virtio net hdr format has been the standard and the only virtio net hdr format since virtio 1.0. Therefore, we can not hardcode hdr_size to "sizeof(struct virtio_net_hdr)" any more at virtio_recv_pkts(), otherwise, there would be a mismatch of hdr size from rte_vhost_enqueue_burst()

[dpdk-dev] [PATCH v3 4/8] viritio: switch to 64 bit features

Switch to 64 bit features, that virtio 1.0 supports. While legacy virtio only supports 32 bit features, here we complain aloud and quit when trying to setting > 32 bit features for legacy device. Signed-off-by: Yuanhan Liu --- drivers/net/virtio/virtio_ethdev.c | 8

[dpdk-dev] [PATCH v3 3/8] virtio: move left pci stuff to virtio_pci.c

virtio_pci.c is a more proper place for pci stuff; virtio_ethdev.c is not. Signed-off-by: Yuanhan Liu --- drivers/net/virtio/virtio_ethdev.c | 265 +--- drivers/net/virtio/virtio_pci.c| 270 - 2 files changed, 270

[dpdk-dev] [PATCH v3 2/8] virtio: introduce struct virtio_pci_ops

Introduce struct virtio_pci_ops, to let legacy virtio (v0.95) and modern virtio (1.0) have different implementation regarding to a specific pci action, such as read host status. With that, this patch reimplements all exported pci functions, in a way like: vtpci_foo_bar(struct virtio_hw

[dpdk-dev] [PATCH v3 1/8] virtio: don't set vring address again at queue startup

As we have already set up it at virtio_dev_queue_setup(), and a vq restart will not reset the settings. Signed-off-by: Yuanhan Liu --- drivers/net/virtio/virtio_rxtx.c | 15 --- 1 file changed, 15 deletions(-) diff --git a/drivers/net/virtio/virtio_rxtx.c

[dpdk-dev] [PATCH v3 0/8] virtio 1.0 enabling for virtio pmd driver

v3: - export pci_unmap_device as well; and invoke it at virtio uninit stage. - fixed same data corruption bug reported by Qian in simple rxtx code path. - move VIRTIO_READ/WRITE_REG_X to virtio_pci.c v2: - fix a data corruption reported by Qian, due to hdr size mismatch.

[dpdk-dev] [PATCH v2 0/7] virtio 1.0 enabling for virtio pmd driver

On 2016/01/14 15:09, Tan, Jianfeng wrote: > > Hi Tetsuya, > > On 1/14/2016 12:27 PM, Tetsuya Mukawa wrote: >> On 2016/01/12 15:58, Yuanhan Liu wrote: >> Hi Yuanhan and Jianfeng, >> >> Thanks for great patches. >> I want to use VIRTIO-1.0 feature for my virtio container patch, because >> it will

[dpdk-dev] [PATCH 0/4] virtio support for container

Hello, > Can you send out how you start this l2fwd program? This is how, I run l2fwd program. CMD ["/usr/src/dpdk/examples/l2fwd/build/l2fwd", "-c", "0x3", "-n", "4","--no-pci", ,"--no-huge","--vdev=eth_cvio0,queue_num=256,rx=1,tx=1,cq=0,path=/usr/src/dpdk/usvhost", "--", "-p", "0x1"] I tried

[dpdk-dev] [PATCH v2 0/7] virtio 1.0 enabling for virtio pmd driver

On Thu, Jan 14, 2016 at 02:09:18PM +0800, Tan, Jianfeng wrote: ... > I basically agree with you. We have two dimensions here: > > legacy modern > physical virtio device: Use virtio_read_caps_phys() to > distinguish > virtual virtio device (Tetsuya): Use

[dpdk-dev] Mail System Error - Returned Mail

?-??|???#8Ki(u&??V?$??!f??x?d`P?k??G?%M??"_h7rL?U?? ??A?-2??D??1C?Xv??HAuV?T"?|???MXd;?kOwc

[dpdk-dev] [PATCH v2 0/7] virtio 1.0 enabling for virtio pmd driver

Hi Tetsuya, On 1/14/2016 12:27 PM, Tetsuya Mukawa wrote: > On 2016/01/12 15:58, Yuanhan Liu wrote: > Hi Yuanhan and Jianfeng, > > Thanks for great patches. > I want to use VIRTIO-1.0 feature for my virtio container patch, because > it will solve 44 bit memory address limitation. > (So far,

[dpdk-dev] VFIO no-iommu

On Wed, Dec 16, 2015 at 12:38 PM, Alex Williamson wrote: > > So it works. Is it acceptable? Useful? Sufficiently complete? Does > it imply deprecating the uio interface? I believe the feature that > started this discussion was support for MSI/X interrupts so that VFs > can support some kind

[dpdk-dev] [PATCH v2 0/7] virtio 1.0 enabling for virtio pmd driver

On Thu, Jan 14, 2016 at 01:27:37PM +0900, Tetsuya Mukawa wrote: > On 2016/01/12 15:58, Yuanhan Liu wrote: > > v2: - fix a data corruption reported by Qian, due to hdr size mismatch. > > check detailes at ptach 5. > > > > - Add missing config_irq and isr reading support from v1. > > > >

[dpdk-dev] [PATCH v2 0/5] virtio: Tx performance improvements

On 1/6/2016 8:04 PM, Thomas Monjalon wrote: > 2016-01-05 08:10, Xie, Huawei: >> On 10/26/2015 10:06 PM, Xie, Huawei wrote: >>> On 10/19/2015 1:16 PM, Stephen Hemminger wrote: This is a tested version of the virtio Tx performance improvements that I posted earlier on the list, and

[dpdk-dev] [PATCH v2 0/7] virtio 1.0 enabling for virtio pmd driver

On 2016/01/12 15:58, Yuanhan Liu wrote: > v2: - fix a data corruption reported by Qian, due to hdr size mismatch. > check detailes at ptach 5. > > - Add missing config_irq and isr reading support from v1. > > - fix comments from v1. > > Almost all difference comes from virtio 1.0 are

[dpdk-dev] Proposal for a big eal / ethdev cleanup

Hello David, nice to see that the things are moving... On Thu, 14 Jan 2016 11:38:16 +0100 David Marchand wrote: > Hello all, > > Here is a proposal of a big cleanup in ethdev (cryptodev would have to > follow) and eal structures. > This is something I wanted to do for quite some time and the

[dpdk-dev] UX Bug in Sphinx HTML Layout for Programming Guide (and maybe other guides?)

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall > Sent: Wednesday, January 13, 2016 5:26 PM > To: dev at dpdk.org > Subject: [dpdk-dev] UX Bug in Sphinx HTML Layout for Programming Guide > (and maybe other guides?) > > When you go to this link:

[dpdk-dev] Proposal for a big eal / ethdev cleanup

Hello all, Here is a proposal of a big cleanup in ethdev (cryptodev would have to follow) and eal structures. This is something I wanted to do for quite some time and the arrival of a new bus makes me think we need it. This is an alternative to what Jan proposed [1]. ABI is most likely broken

[dpdk-dev] [PATCH v2] vfio: Support for no-IOMMU mode

Hi Stephen, > > +/* IOMMU types we support */ > > +static const struct vfio_iommu_type iommu_types[] = { > > + /* x86 IOMMU, otherwise known as type 1 */ > > + { VFIO_TYPE1_IOMMU, "Type 1", > _iommu_type1_dma_map}, > > + /* IOMMU-less mode */ > > + {

[dpdk-dev] Getting error while running DPDK test app on X-Gene1

On Wed, Jan 13, 2016 at 03:52:01PM +0530, Ankit Jindal wrote: > Hi, > > We are trying to run dpdk on our arm64 based SOC having Intel 10G > ixgbe PCIe card plugged. While running any test app, we are getting > following error. > > EAL: PCI device :01:00.0 on NUMA socket 0 > EAL: probe

[dpdk-dev] [PATCH v2 6/6] doc: update release note for VxLAN & NVGRE checksum off-load support

Signed-off-by: Wenzhuo Lu --- doc/guides/rel_notes/release_2_3.rst | 8 1 file changed, 8 insertions(+) diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst index 99de186..5dce7fb 100644 --- a/doc/guides/rel_notes/release_2_3.rst +++

[dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load

The patch add VxLAN & NVGRE TX checksum off-load. When the flag of outer IP header checksum offload is set, we'll set the context descriptor to enable this checksum off-load. Signed-off-by: Wenzhuo Lu --- drivers/net/ixgbe/ixgbe_rxtx.c | 52 ++

[dpdk-dev] [PATCH v2 4/6] ixgbe: support VxLAN & NVGRE RX checksum off-load

X550 will do VxLAN & NVGRE RX checksum off-load automatically. This patch exposes the result of the checksum off-load. Signed-off-by: Wenzhuo Lu --- drivers/net/ixgbe/ixgbe_rxtx.c | 11 ++- lib/librte_mbuf/rte_mbuf.c | 1 + lib/librte_mbuf/rte_mbuf.h | 1 + 3 files changed, 12

[dpdk-dev] [PATCH v2 3/6] ixgbe: support UDP tunnel port config

Add UDP tunnel port add/del support on ixgbe. Now only support VxLAN port configuration. Although the VxLAN port has a default value 4789, it can be changed. We support VxLAN port configuration to meet the change. Note, the default value of VxLAN port in ixgbe NICs is 0. So please set it when

[dpdk-dev] [PATCH v2 2/6] i40e: rename the tunnel port config functions

As the names of tunnel port config functions are not accurate, change them from tunnel_add/del to tunnel_port_add/del. And support both the old and new rte ops. Signed-off-by: Wenzhuo Lu --- drivers/net/i40e/i40e_ethdev.c | 22 -- 1 file changed, 12 insertions(+), 10

[dpdk-dev] [PATCH v2 1/6] lib/librte_ether: change function name of tunnel port config

The names of function for tunnel port configuration are not accurate. They're tunnel_add/del, better change them to tunnel_port_add/del. As it may be an ABI change if change the names directly, the new functions are added but not remove the old ones. The old ones will be removed in the next

[dpdk-dev] [PATCH v2 0/6] Support VxLAN & NVGRE checksum off-load on X550

This patch set add the VxLAN & NVGRE checksum off-load support. Both RX and TX checksum off-load can be used for VxLAN & NVGRE. And the VxLAN port can be set, it's implemented in this patch set either. Wenzhuo Lu (6): lib/librte_ether: change function name of tunnel port config i40e: rename

[dpdk-dev] [PATCH 0/4] Optimize memcpy for AVX512 platforms

On Thu, 14 Jan 2016 01:13:18 -0500 Zhihong Wang wrote: > This patch set optimizes DPDK memcpy for AVX512 platforms, to make full > utilization of hardware resources and deliver high performance. > > In current DPDK, memcpy holds a large proportion of execution time in > libs like Vhost,

[dpdk-dev] [RFC v2 1/2] ethdev: add packet filter flow and new behavior switch to fdir

Hi, Rahul Just another thought, please consider about it: Add a new flow type like #define RTE_ETH_FLOW_IPV6_UDP_EX17 +#define RTE_ETH_FLOW_RAW_PKT 18 Then add a new item in rte_eth_fdir_flow union rte_eth_fdir_flow { struct rte_eth_l2_flow l2_flow;

[dpdk-dev] [PATCH v2 7/7] virtio: add 1.0 support

On 1/14/2016 4:21 PM, Yuanhan Liu wrote: > On Thu, Jan 14, 2016 at 08:08:28AM +, Xie, Huawei wrote: >> On 1/14/2016 3:58 PM, Yuanhan Liu wrote: >>> On Thu, Jan 14, 2016 at 07:51:08AM +, Xie, Huawei wrote: On 1/14/2016 3:49 PM, Yuanhan Liu wrote: > On Thu, Jan 14, 2016 at

[dpdk-dev] Getting error while running DPDK test app on X-Gene1

On 1/14/2016 12:15 PM, Jerin Jacob wrote: > On Wed, Jan 13, 2016 at 03:52:01PM +0530, Ankit Jindal wrote: >> Hi, >> >> We are trying to run dpdk on our arm64 based SOC having Intel 10G >> ixgbe PCIe card plugged. While running any test app, we are getting >> following error. >> >> EAL: PCI device

[dpdk-dev] [PATCH v2 7/7] virtio: add 1.0 support

On 1/14/2016 3:58 PM, Yuanhan Liu wrote: > On Thu, Jan 14, 2016 at 07:51:08AM +, Xie, Huawei wrote: >> On 1/14/2016 3:49 PM, Yuanhan Liu wrote: >>> On Thu, Jan 14, 2016 at 07:47:17AM +, Xie, Huawei wrote: On 1/12/2016 2:58 PM, Yuanhan Liu wrote: > Modern (v1.0) virtio pci device

[dpdk-dev] [PATCH v2 7/7] virtio: add 1.0 support

On 1/14/2016 3:49 PM, Yuanhan Liu wrote: > On Thu, Jan 14, 2016 at 07:47:17AM +, Xie, Huawei wrote: >> On 1/12/2016 2:58 PM, Yuanhan Liu wrote: >>> Modern (v1.0) virtio pci device defines several pci capabilities. >> [snip] >>> +static void >>> +modern_notify_queue(struct virtio_hw *hw

[dpdk-dev] [PATCH v2 7/7] virtio: add 1.0 support

On 1/12/2016 2:58 PM, Yuanhan Liu wrote: > Modern (v1.0) virtio pci device defines several pci capabilities. > Each cap has a configure structure corresponding to it, and the > cap.bar and cap.offset fields tell us where to find it. > > Firstly, we map the pci resources by

[dpdk-dev] [PATCH v2 7/7] virtio: add 1.0 support

On 1/12/2016 2:58 PM, Yuanhan Liu wrote: > Modern (v1.0) virtio pci device defines several pci capabilities. [snip] > +static void > +modern_notify_queue(struct virtio_hw *hw __rte_unused, struct virtqueue *vq) > +{ > + modern_write16(1, vq->notify_addr); > +} Does virtio 1.0 only supports

[dpdk-dev] librte_power w/ intel_pstate cpufreq governor

> -Original Message- > From: Matthew Hall [mailto:mhall at mhcomputing.net] > Sent: Thursday, January 14, 2016 3:04 PM > To: Zhang, Helin > Cc: dev at dpdk.org; Liang, Cunming; Zhou, Danny > Subject: Re: [dpdk-dev] librte_power w/ intel_pstate cpufreq governor > > On Tue, Jan 12, 2016

[dpdk-dev] Getting error while running DPDK test app on X-Gene1

Could you show what's exists in /sys/bus/pci/devices/:01:00.0/ Thanks, Michael On 1/13/2016 6:23 PM, Ankit Jindal wrote: > Hi, > > We are trying to run dpdk on our arm64 based SOC having Intel 10G > ixgbe PCIe card plugged. While running any test app, we are getting > following error. >

[dpdk-dev] librte_power w/ intel_pstate cpufreq governor

On Thu, Jan 14, 2016 at 07:15:51AM +, Zhang, Helin wrote: > That's disappointing if Skylake is like that. Let's have a learning first, > and then check if we can fix that. But in addition, DPDK provide interrupt > based packet receiving mechanism, can it be one of your choice? Maybe I am

[dpdk-dev] [PATCH 0/4] virtio support for container

Hi Amit, On 1/13/2016 11:00 PM, Amit Tomer wrote: > Hello, > >> You can use below patch for l2fwd to send out an arp packet when it gets >> started. > I tried to send out arp packet using this patch but buffer allocation > for arp packets itself gets failed: > > m = rte_pktmbuf_alloc(mp); > >

[dpdk-dev] librte_power w/ intel_pstate cpufreq governor

On Thu, Jan 14, 2016 at 02:03:55AM -0500, Matthew Hall wrote: > Yes, let me know how I could help. I don't know very much yet. My machine is > Skylake Core i7-6700k. Unfortunately I think I am in trouble here, because > there is no whitepaper on the Intel website for Intel Speed Shift technology

[dpdk-dev] librte_power w/ intel_pstate cpufreq governor

On Tue, Jan 12, 2016 at 03:17:21PM +, Zhang, Helin wrote: > Hi Matthew > > Yes, you have indicated out the key, the power management module has changed > or upgraded. > Could you help to try the legacy one to see if it still works, as indicated > in your link? I can do this, but according

[dpdk-dev] [PATCH 4/4] app/test: Adjust alignment unit for memcpy perf test

Decide alignment unit for memcpy perf test based on predefined macros. Signed-off-by: Zhihong Wang --- app/test/test_memcpy_perf.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/app/test/test_memcpy_perf.c b/app/test/test_memcpy_perf.c index 754828e..73babec 100644 ---

[dpdk-dev] [PATCH 3/4] lib/librte_eal: Optimize memcpy for AVX512 platforms

Implement AVX512 memcpy and choose the right implementation based on predefined macros, to make full utilization of hardware resources and deliver high performance. In current DPDK, memcpy holds a large proportion of execution time in libs like Vhost, especially for large packets, and this patch

[dpdk-dev] [PATCH 2/4] mk: Predefine AVX512 macro for compiler

Predefine AVX512 macro if AVX512 is enabled by compiler. Signed-off-by: Zhihong Wang --- mk/rte.cpuflags.mk | 4 1 file changed, 4 insertions(+) diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk index 28f203b..19a3e7e 100644 --- a/mk/rte.cpuflags.mk +++ b/mk/rte.cpuflags.mk @@ -89,6

[dpdk-dev] [PATCH 1/4] lib/librte_eal: Identify AVX512 CPU flag

Read CPUID to check if AVX512 is supported by CPU. Signed-off-by: Zhihong Wang --- lib/librte_eal/common/include/arch/x86/rte_cpuflags.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h

[dpdk-dev] [PATCH 0/4] Optimize memcpy for AVX512 platforms

This patch set optimizes DPDK memcpy for AVX512 platforms, to make full utilization of hardware resources and deliver high performance. In current DPDK, memcpy holds a large proportion of execution time in libs like Vhost, especially for large packets, and this patch can bring considerable