[dpdk-dev] [PATCH v2 0/4] fix the issue that DPDK takes over virtio device blindly

On 1/5/2016 1:25 AM, Stephen Hemminger wrote: > On Mon, 4 Jan 2016 01:56:09 +0800 > Huawei Xie wrote: > >> v2 changes: >> Remove unnecessary assignment of NULL to dev->data->mac_addrs >> Ajust one comment's position >> change LOG level from ERR to INFO >> >> virtio PMD doesn't set RTE_PCI_DRV_

[dpdk-dev] [PATCH v2 0/4] fix the issue that DPDK takes over virtio device blindly

On Tue, Jan 12, 2016 at 8:32 AM, Xie, Huawei wrote: > > On 1/5/2016 1:25 AM, Stephen Hemminger wrote: > > On Mon, 4 Jan 2016 01:56:09 +0800 > > Huawei Xie wrote: > > > >> v2 changes: > >> Remove unnecessary assignment of NULL to dev->data->mac_addrs > >> Ajust one comment's position > >> chan

[dpdk-dev] [PATCH v2 0/4] fix the issue that DPDK takes over virtio device blindly

On 1/12/2016 12:24 PM, Santosh Shukla wrote: > On Tue, Jan 12, 2016 at 8:32 AM, Xie, Huawei wrote: >> On 1/5/2016 1:25 AM, Stephen Hemminger wrote: >>> On Mon, 4 Jan 2016 01:56:09 +0800 >>> Huawei Xie wrote: >>> v2 changes: Remove unnecessary assignment of NULL to dev->data->mac_addrs

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

On 2016/01/10 20:42, Jianfeng Tan wrote: > This patchset is to provide high performance networking interface (virtio) > for container-based DPDK applications. The way of starting DPDK apps in > containers with ownership of NIC devices exclusively is beyond the scope. > The basic idea here is to pre

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

Hi Tetsuya, > Hi Jianfeng and Xie, > > I guess my implementation and yours have a lot of common code, so I will > try to rebase my patch on yours. We also think so. And before you rebase your code, I think we can rely on Yuanhan's struct virtio_pci_ops to make the code structure brief and clea

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

On 2016/01/12 14:46, Tan, Jianfeng wrote: > > Hi Tetsuya, > > >> Hi Jianfeng and Xie, >> >> I guess my implementation and yours have a lot of common code, so I will >> try to rebase my patch on yours. > > We also think so. And before you rebase your code, I think we can rely > on Yuanhan's > stru

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

On Tue, Jan 12, 2016 at 03:01:01PM +0900, Tetsuya Mukawa wrote: > On 2016/01/12 14:46, Tan, Jianfeng wrote: > > > > Hi Tetsuya, > > > > > >> Hi Jianfeng and Xie, > >> > >> I guess my implementation and yours have a lot of common code, so I will > >> try to rebase my patch on yours. > > > > We als

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

On 2016/01/12 15:14, Yuanhan Liu wrote: > On Tue, Jan 12, 2016 at 03:01:01PM +0900, Tetsuya Mukawa wrote: >> On 2016/01/12 14:46, Tan, Jianfeng wrote: >>> Hi Tetsuya, >>> >>> Hi Jianfeng and Xie, I guess my implementation and yours have a lot of common code, so I will try to r

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

On Tue, Jan 12, 2016 at 03:26:47PM +0900, Tetsuya Mukawa wrote: > On 2016/01/12 15:14, Yuanhan Liu wrote: > > On Tue, Jan 12, 2016 at 03:01:01PM +0900, Tetsuya Mukawa wrote: > >> On 2016/01/12 14:46, Tan, Jianfeng wrote: > >>> Hi Tetsuya, > >>> > >>> > Hi Jianfeng and Xie, > > I gu

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

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 the PCI layout change: the major configuration struct

[dpdk-dev] [PATCH v2 1/7] 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 b/drivers/net/virtio/virtio

[dpdk-dev] [PATCH v2 2/7] 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 *h

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

virtio_pci.c is a more proper place for pci stuff; virtio_ethdev 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 insertions(+

[dpdk-dev] [PATCH v2 4/7] viritio: switch to 64 bit features

Switch to 64 bit features, which virtio 1.0 supports. While legacy virtio only supports 32 bit features, it complains aloud and quit when trying to setting > 32 bit features. Signed-off-by: Yuanhan Liu --- drivers/net/virtio/virtio_ethdev.c | 8 drivers/net/virtio/virtio_pci.c| 15

[dpdk-dev] [PATCH v2 5/7] 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 could 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 v2 6/7] eal: pci: export pci_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), pci_map_device(

[dpdk-dev] [PATCH v2 7/7] 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 by

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

On Tue, Jan 12, 2016 at 02:58:57PM +0800, 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 co

[dpdk-dev] [PATCH v3 09/12] virtio: vfio: Enable RTE_PCI_DRV_NEED_MAPPING flag in driver

On Sat, Jan 09, 2016 at 06:08:46PM +0530, Santosh Shukla wrote: > On Thu, Jan 7, 2016 at 11:50 PM, Stephen Hemminger > wrote: > > On Thu, 7 Jan 2016 22:03:06 +0530 > > Santosh Shukla wrote: > > > >> +#ifdef RTE_EAL_VFIO > >> + .drv_flags = RTE_PCI_DRV_NEED_MAPPING | > >> RTE_PCI_DRV

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

Hello! > > b) With --single-file - ovs runs, but doesn't get any packets at all. When > > i try to ping > the container from within host side, it > > counts drops on vhost-user port. > Can you check the OVS in host side, if it prints out message of "virtio > is now ready for processing"? No, i

[dpdk-dev] [PATCH 4/4] virtio/vdev: add a new vdev named eth_cvio

Hello! See inline > -Original Message- > From: Jianfeng Tan [mailto:jianfeng.tan at intel.com] > Sent: Sunday, January 10, 2016 2:43 PM > To: dev at dpdk.org > Cc: rich.lane at bigswitch.com; yuanhan.liu at linux.intel.com; mst at > redhat.com; > nakajima.yoshihiro at lab.ntt.co.jp; hu

[dpdk-dev] [PATCH 4/4] virtio/vdev: add a new vdev named eth_cvio

On Tue, Jan 12, 2016 at 10:45:59AM +0300, Pavel Fedin wrote: > Hello! > > See inline Hi, Please strip unrelated context, so that people could reach to your comments as quick as possible, otherwise, people could easily get lost from the long patch. > > > -Original Message- > > From: J

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

See my reply to "mem: add API to obstain memory-backed file info" for a workaround. With fixes for that and the TUNSETVNETHDRSZ issue I was able to get traffic running over vhost-user.

[dpdk-dev] [PATCH v2 6/7] eal: pci: export pci_map_device

On Tue, Jan 12, 2016 at 7:59 AM, 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 to work wi

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

Hello! > See my reply to "mem: add API to obstain memory-backed file info" for a > workaround. With fixes for that and the TUNSETVNETHDRSZ issue I was able to > get traffic running over vhost-user. With ovs or test apps? I still have problems with ovs after this. Packets go from host to conta

[dpdk-dev] [PATCH 4/4] virtio/vdev: add a new vdev named eth_cvio

Hi Fedin, On 1/12/2016 3:45 PM, Pavel Fedin wrote: > Hello! > > See inline > >> ... >> } >> >> +struct rte_mbuf *m = NULL; >> +if (dev->dev_type == RTE_ETH_DEV_PCI) >> +vq->offset = (uintptr_t)&m->buf_addr; >> +#ifdef RTE_VIRTIO_VDEV >> +else { >> +vq->

[dpdk-dev] [PATCH v2 6/7] eal: pci: export pci_map_device

On Tue, Jan 12, 2016 at 09:31:05AM +0100, David Marchand wrote: > On Tue, Jan 12, 2016 at 7:59 AM, 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 expor

[dpdk-dev] [PATCH 03/11] i40e: move pci device ids to driver

On Sun, Jan 10, 2016 at 9:02 PM, Stephen Hemminger < stephen at networkplumber.org> wrote: > On Sun, 10 Jan 2016 13:50:46 +0100 > David Marchand wrote: > > > +{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_XL710) }, > > +{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QEMU) }, > > +{ R

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

Hi Fedin, On 1/12/2016 4:39 PM, Pavel Fedin wrote: > Hello! > >> See my reply to "mem: add API to obstain memory-backed file info" for a >> workaround. With fixes for that and the TUNSETVNETHDRSZ issue I was able to >> get traffic running over vhost-user. > With ovs or test apps? I still have

[dpdk-dev] [PATCH v2 6/7] eal: pci: export pci_map_device

On Tue, Jan 12, 2016 at 04:40:43PM +0800, Yuanhan Liu wrote: > On Tue, Jan 12, 2016 at 09:31:05AM +0100, David Marchand wrote: > > On Tue, Jan 12, 2016 at 7:59 AM, Yuanhan Liu > linux.intel.com> > > wrote: > > > > Normally we could set RTE_PCI_DRV_NEED_MAPPING flag so that eal will > > in

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hi! On 1/12/2016 4:26 AM, Rich Lane wrote: > On Sun, Jan 10, 2016 at 3:43 AM, Jianfeng Tan > wrote: > > @@ -1157,6 +1180,20 @@ rte_eal_hugepage_init(void) > mcfg->memseg[0].len = internal_config.memory; > mcfg->memseg[

[dpdk-dev] [PATCH 4/4] virtio/vdev: add a new vdev named eth_cvio

Hi Fedin, On 1/12/2016 4:39 PM, Tan, Jianfeng wrote: > Hi Fedin, > > On 1/12/2016 3:45 PM, Pavel Fedin wrote: >> Hello! >> >> See inline >> >>> ... >>> } >>> >>> +struct rte_mbuf *m = NULL; >>> +if (dev->dev_type == RTE_ETH_DEV_PCI) >>> +vq->offset = (uintptr_t)&m->buf_a

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! >> Should this be "hugepage->size = internal_config.memory"? Otherwise the >> vhost-user >> memtable entry has a size of only 2MB. > I don't think so. See the definition: > 47 struct hugepage_file { > 48 void *orig_va; /**< virtual addr of first mmap() */ > 49 void

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > But in this case host gets this page size for total region size, therefore > qva_to_vva() fails. > I haven't worked with hugepages, but i guess that with real hugepages we > get one file per page, therefore page size == mapping size. With newly > introduced --single-file we now hav

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

Hello! > Your guess makes sense because current implementation does not support > multi-queues. > > From you log, only 0 and 1 are "ready for processing"; others are "not > ready for processing". Yes, and if study it even more carefully, we see that we initialize all tx queues but only a sin

[dpdk-dev] [PATCH v2 0/3] ABI change for RETA, cmdline

Previous version of commit "cmdline: increase command line buffer", had side effects and was breaking some commands. In this version, I only applied John McNamara's solution which consists in increasing only RDLINE_BUF_SIZE define from 256 to 512 bytes [1]. [1] http://dpdk.org/ml/archives/dev/201

[dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer

Allow long command lines in testpmd (like flow director with IPv6, ...). Signed-off-by: John McNamara Signed-off-by: Nelio Laranjeiro --- doc/guides/rel_notes/deprecation.rst | 5 - lib/librte_cmdline/cmdline_rdline.h | 2 +- 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/do

[dpdk-dev] [PATCH v2 2/3] ethdev: change RETA type in rte_eth_rss_reta_entry64

Several NICs can handle 512 entries/queues in their RETA table, an 8 bit field is not large enough for them. Signed-off-by: Nelio Laranjeiro --- app/test-pmd/cmdline.c | 4 ++-- doc/guides/rel_notes/deprecation.rst | 5 - lib/librte_ether/rte_ethdev.c| 2 +- lib/librte_

[dpdk-dev] [PATCH v2 3/3] mlx5: increase RETA table size

ConnectX-4 NICs can handle at most 512 entries in RETA table. Signed-off-by: Nelio Laranjeiro --- drivers/net/mlx5/mlx5_defs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/mlx5/mlx5_defs.h b/drivers/net/mlx5/mlx5_defs.h index bb82c9a..ae5eda9 100644 --- a/drive

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > > BTW, i'm still unhappy about ABI breakage here. I think we could easily > > add --shared-mem > option, which would simply change mapping mode to SHARED. So, we could use it > with both > hugepages (default) and plain mmap (with --no-hugepages). > > You mean, use "--no-hugepages --

[dpdk-dev] [PATCH] doc: add a further ACL example

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Antonio Fischetti > Sent: Monday, January 11, 2016 5:45 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: add a further ACL example > > Add a further ACL example where the elements of the search key ar

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hi Pavel, On 12/01/2016 11:00, Pavel Fedin wrote: > Hello! > >>>BTW, i'm still unhappy about ABI breakage here. I think we could easily >>> add --shared-mem >> option, which would simply change mapping mode to SHARED. So, we could use >> it with both >> hugepages (default) and plain mmap (

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > Oh I get it and recognize the problem here. The actual problem lies in > the API rte_eal_get_backfile_info(). > backfiles[i].size = hugepage_files[i].size; > Should use statfs or hugepage_files[i].size * hugepage_files[i].repeated > to calculate the total size. .repeated depends on CON

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On 12/01/2016 11:22, Pavel Fedin wrote: > Hello! > >> Oh I get it and recognize the problem here. The actual problem lies in >> the API rte_eal_get_backfile_info(). >> backfiles[i].size = hugepage_files[i].size; >> Should use statfs or hugepage_files[i].size * hugepage_files[i].repeated >> to cal

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > So are you suggesting to not introduce --single-file option but instead > --shared-mem? > AFAIK --single-file was trying to workaround the limitation of just > being able to map 8 fds. Heh, yes, you're right... Indeed, sorry, i was not patient enough, i see it uses hpi->hugedir instea

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On 12/01/2016 11:07, Sergio Gonzalez Monroy wrote: > Hi Pavel, > > On 12/01/2016 11:00, Pavel Fedin wrote: >> Hello! >> BTW, i'm still unhappy about ABI breakage here. I think we could easily add --shared-mem Could you elaborate a bit more on your concerns regarding ABI breakage ?

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > > .repeated depends on CONFIG_RTE_EAL_SIGLE_FILE_SEGMENTS. By the way, > > looks like it does > the same thing as you are trying to do with --single-file, but with > hugepages, doesn't it? I > see it's currently used by ivshmem (which is AFAIK very immature and > half-abandoned). >

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On 12/01/2016 11:37, Pavel Fedin wrote: > Hello! > >> So are you suggesting to not introduce --single-file option but instead >> --shared-mem? >> AFAIK --single-file was trying to workaround the limitation of just >> being able to map 8 fds. > Heh, yes, you're right... Indeed, sorry, i was not

[dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del

Hi, 2016-01-11 08:28, Lu, Wenzhuo: > [Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed. I just > use them. Honestly I agree with you they are not accurate name. Better change > them to udp_tunnel_port_add and udp_tunnel_port_del. But it should be a ABI > change if I?m not wro

[dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer

On 01/12/2016 12:49 PM, Nelio Laranjeiro wrote: > Allow long command lines in testpmd (like flow director with IPv6, ...). > > Signed-off-by: John McNamara > Signed-off-by: Nelio Laranjeiro > --- > doc/guides/rel_notes/deprecation.rst | 5 - > lib/librte_cmdline/cmdline_rdline.h | 2 +- >

[dpdk-dev] [PATCH 1/2] fm10k: Add Atwood Channel Support

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu > Sent: Monday, January 11, 2016 7:28 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 1/2] fm10k: Add Atwood Channel Support > > Atwood Channel is intel 25G NIC, and this patch add the support

[dpdk-dev] [PATCH 2/2] fm10k: update doc for Atwood Channel

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu > Sent: Monday, January 11, 2016 7:28 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 2/2] fm10k: update doc for Atwood Channel > > Atwood Channel is 20GbE NIC and belongs to Intel FM10K family

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On 12/01/2016 12:01, Pavel Fedin wrote: > Hello! > >>>.repeated depends on CONFIG_RTE_EAL_SIGLE_FILE_SEGMENTS. By the way, >>> looks like it does >> the same thing as you are trying to do with --single-file, but with >> hugepages, doesn't it? I >> see it's currently used by ivshmem (which i

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

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu > Sent: Monday, January 11, 2016 7:07 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 4/4] doc: update release note for VxLAN & NVGRE > checksum off-load support > +* **Support VxLAN & NVGRE ch

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > I might be missing something obvious here but, aside from having memory > SHARED which most DPDK apps using hugepages will have anyway, what is > the backward compatibility issues that you see here? Heh, sorry once again for confusing. Indeed, with hugepages we always get MAP_SHARED.

[dpdk-dev] [PATCH 09/11] doc: refresh headers list

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand > Sent: Sunday, January 10, 2016 12:51 PM > To: dev at dpdk.org > Cc: thomas.monjalon at dpdk.org > Subject: [dpdk-dev] [PATCH 09/11] doc: refresh headers list > > Since we are going to remove a h

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On 12/01/2016 13:57, Pavel Fedin wrote: > Hello! > >> I might be missing something obvious here but, aside from having memory >> SHARED which most DPDK apps using hugepages will have anyway, what is >> the backward compatibility issues that you see here? > Heh, sorry once again for confusing. I

[dpdk-dev] [RFC PATCH 3/3] doc: add introduction for fm10k FTAG based forwarding

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wang Xiao W > Sent: Tuesday, January 5, 2016 12:32 PM > To: Chen, Jing D; Richardson, Bruce > Cc: dev at dpdk.org > Subject: [dpdk-dev] [RFC PATCH 3/3] doc: add introduction for fm10k FTAG > based forwarding > >

[dpdk-dev] [PATCH] i40e: fix VLAN bitmasks for hash/fdir input sets for tunnels

This patch adds missing VLAN bitmask for inner frame in case of tunneling and fixes VLAN tags bitmasks for single or outer frame in case of tunneling. Signed-off-by: Andrey Chilikin --- drivers/net/i40e/i40e_ethdev.c | 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-) diff --g

[dpdk-dev] [PATCH] vhost_user: Make sure that memory map is set before attempting address translation

Malfunctioning virtio clients may not send VHOST_USER_SET_MEM_TABLE for some reason. This causes NULL dereference in qva_to_vva(). Change-Id: Ibc8f6637fb5fb9885b02c316adf18afd45e0d49a Signed-off-by: Pavel Fedin --- lib/librte_vhost/virtio-net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(

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

Hello, I run l2fwd from inside docker with following logs: But, don't see Port statistics gets updated ? #/home/ubuntu/dpdk# sudo docker run -i -t -v /home/ubuntu/dpdk/usvhost:/usr/src/dpdk/usvhost l4 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 1 on socket 0 EAL: De

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

Hello! > Could anyone please point out, how it can be tested further(how can > traffic be sent across host and container) ? Have you applied all three fixes discussed here? Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia

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

Hello! On 1/12/2016 10:45 PM, Amit Tomer wrote: > Hello, > > I run l2fwd from inside docker with following logs: > > But, don't see Port statistics gets updated ? > In vhost-switch, it judges if a virtio device is ready for processing after receiving a pkt from virtio device. So you'd better con

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

Hello, > Have you applied all three fixes discussed here? I am running it with, only RFC patches applied with "--no-huge" in l2fwd. Thanks Amit.

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

Hello, > In vhost-switch, it judges if a virtio device is ready for processing after > receiving > a pkt from virtio device. So you'd better construct a pkt, and send it out > firstly > in l2fwd. I tried to ping the socket interface from host for the same purpose but it didn't work. Could you pl

[dpdk-dev] librte_power w/ intel_pstate cpufreq governor

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? Taking control of the governor from kernel to user space, might need one more checks before that. But i

[dpdk-dev] [RFC] cryptodev: Change burst APIs to crypto operation oriented

In this rfc I'm looking to get some feedback on a proposal to change the cryptodev burst API from the current implementation of accepting burst of rte_mbuf's to a burst API based on rte_crypto_op's. -static inline uint16_t -rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id, -

[dpdk-dev] [PATCH v4 6/6] vmxnet3: announce device offload capability

Signed-off-by: Yong Wang --- drivers/net/vmxnet3/vmxnet3_ethdev.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c index d90e62f..8a40127 100644 --- a/drivers/net/vmxnet3/vmxnet3_ethdev.

[dpdk-dev] [PATCH v4 0/6] vmxnet3 TSO, tx cksum offload and cleanups

v4: * moved cleanups to separate patches * correctly handled multi-seg pkts with data ring used v3: * fixed comments from Stephen * added performance number for tx data ring v2: * fixed some logging issues when debug option turned on * updated the txq_flags check in vmxnet3_dev_tx_queue_setup()

[dpdk-dev] [PATCH v4 3/6] vmxnet3: cleanup txNumDeferred usage

Signed-off-by: Yong Wang --- drivers/net/vmxnet3/vmxnet3_rxtx.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c index 4ccab0e..f3af2f2 100644 --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c +++ b/dri

[dpdk-dev] [PATCH v4 2/6] vmxnet3: restore tx data ring support

Tx data ring support was removed in a previous change that added multi-seg transmit. This change adds it back. According to the original commit (2e849373), 64B pkt rate with l2fwd improved by ~20% on an Ivy Bridge server at which point we start to hit some bottleneck on the rx side. I also re-di

[dpdk-dev] [PATCH v4 4/6] vmxnet3: add tx l4 cksum offload

Support TCP/UDP checksum offload. Signed-off-by: Yong Wang --- doc/guides/rel_notes/release_2_3.rst | 3 +++ drivers/net/vmxnet3/vmxnet3_rxtx.c | 26 +++--- 2 files changed, 26 insertions(+), 3 deletions(-) diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/r

[dpdk-dev] [PATCH v4 1/6] vmxnet3: fix typos and remove unused struct

Signed-off-by: Yong Wang --- drivers/net/vmxnet3/base/includeCheck.h | 39 - drivers/net/vmxnet3/base/vmxnet3_defs.h | 9 +--- drivers/net/vmxnet3/vmxnet3_ethdev.c| 2 +- drivers/net/vmxnet3/vmxnet3_ring.h | 13 --- drivers/net/vmxnet3/vmxnet

[dpdk-dev] [PATCH v4 5/6] vmxnet3: add TSO support

This commit adds vmxnet3 TSO support. Verified with test-pmd (set fwd csum) that both tso and non-tso pkts can be successfully transmitted and all segmentes for a tso pkt are correct on the receiver side. Signed-off-by: Yong Wang --- doc/guides/rel_notes/release_2_3.rst | 3 + drivers/net/vmx

[dpdk-dev] [PATCH v3 1/4] vmxnet3: restore tx data ring support

On Wed, 13 Jan 2016 02:20:01 + Yong Wang wrote: > >Good idea to use a local region which optmizes the copy in the host, > >but this implementation needs to be more general. > > > >As written it is broken for multi-segment packets. A multi-segment > >packet will have a pktlen >= datalen as in:

[dpdk-dev] [PATCH] ixgbe: fix whitespace

Normally, I ignore random minor whitespace issues, but this driver seems to have some authors that don't understand the conventions of putting whitespace after keywords. Signed-off-by: Stephen Hemminger --- drivers/net/ixgbe/ixgbe_bypass.c | 4 ++-- drivers/net/ixgbe/ixgbe_ethdev.c | 50 +++

[dpdk-dev] [PATCH v4 0/6] vmxnet3 TSO, tx cksum offload and cleanups

On Tue, 12 Jan 2016 18:08:31 -0800 Yong Wang wrote: > v4: > * moved cleanups to separate patches > * correctly handled multi-seg pkts with data ring used > > v3: > * fixed comments from Stephen > * added performance number for tx data ring > > v2: > * fixed some logging issues when debug option