Hi Konstantin,
On 1/6/2016 12:49 AM, Ananyev, Konstantin wrote:
> Hi Jianfeng,
>
+static int
+check_packet_type_ok(int portid)
+{
+ int i;
+ int ret;
+ uint32_t ptypes[RTE_PTYPE_L3_MAX_NUM];
+ int ptype_l3_ipv4 = 0, ptype_l3_ipv6 = 0;
+
+ ret = rt
On Tue, Jan 05, 2016 at 02:14:09PM -0800, Rich Lane wrote:
> The common vhost code only supported a single mmap per device. vhost-user
> worked around this by saving the address/length/fd of each mmap after the end
> of the rte_virtio_memory struct. This only works if the vhost-user code frees
> de
On Tue, Jan 05, 2016 at 09:07:42AM +0800, Jianfeng Tan wrote:
> Fix the issue that virtio device cannot be started after stopped.
>
> The field, hw->started, should be changed by virtio_dev_start/stop instead
> of virtio_dev_close.
>
> Signed-off-by: Jianfeng Tan
Acked-by: Yuanhan Liu
BTW, if
Hi All,
While trying call load with virtio_pmd/vmxnet3_pmd , I am
seeing that at around 100Mbps, we are having tx_burst errors. We are currently
using DPDK 2.1 and send 1 packet at a time. When we try the same with ixgbe_vf
we are not seeing similar drops. Is there any issues wi
Hi Jasvinder,
Below is my system configuration
Hugepages:
--
[root at qos_sched]# grep -i huge /proc/meminfo
AnonHugePages: 4096 kB
HugePages_Total:8000
HugePages_Free: 7488
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize: 2048 kB
NUMA Nodes:
---
On 1/7/2016 10:27 AM, Yuanhan Liu wrote:
> On Tue, Jan 05, 2016 at 02:14:09PM -0800, Rich Lane wrote:
>> The common vhost code only supported a single mmap per device. vhost-user
>> worked around this by saving the address/length/fd of each mmap after the end
>> of the rte_virtio_memory struct. Thi
Hi Souvik,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dey, Souvik
> Sent: Thursday, January 7, 2016 2:15 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] tx_burst errors seen with virtual pmds
>
> Hi All,
> While trying call load with vir
On 05/01/2016 09:37, Ralf Hoffmann wrote:
> with only one hugepage or already sorted hugepage addresses, the sort
> function called memcpy with same src and dst pointer. Debugging with
> valgrind will issue a warning about overlapping area. This patch
> changes the sort method to qsort to avoid thi
So is there no resolution to this issue ?
-Original Message-
From: Tan, Jianfeng [mailto:jianfeng@intel.com]
Sent: Thursday, January 07, 2016 2:18 PM
To: Dey, Souvik ; dev at dpdk.org
Subject: RE: tx_burst errors seen with virtual pmds
Hi Souvik,
> -Original Message-
> From
Hi Jianfeng,
> -Original Message-
> From: Tan, Jianfeng
> Sent: Thursday, January 07, 2016 1:20 AM
> To: Ananyev, Konstantin; dev at dpdk.org
> Cc: Zhang, Helin
> Subject: Re: [PATCH 12/12] examples/l3fwd: add option to parse ptype
>
>
> Hi Konstantin,
>
> On 1/6/2016 12:49 AM, Ananyev,
On 07/01/2016 09:33, Sergio Gonzalez Monroy wrote:
> On 05/01/2016 09:37, Ralf Hoffmann wrote:
>> with only one hugepage or already sorted hugepage addresses, the sort
>> function called memcpy with same src and dst pointer. Debugging with
>> valgrind will issue a warning about overlapping area. Th
Hi Uday,
> -Original Message-
> From: ravulakollu.kumar at wipro.com [mailto:ravulakollu.kumar at wipro.com]
> Sent: Thursday, January 7, 2016 6:29 AM
> To: Singh, Jasvinder
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] Traffic scheduling in DPDK
>
> Hi Jasvinder,
>
> Below is my syst
Thanks Jasvinder for your quick response.
-Original Message-
From: Singh, Jasvinder [mailto:jasvinder.si...@intel.com]
Sent: Thursday, January 07, 2016 3:44 PM
To: Ravulakollu Udaya Kumar (WT01 - Product Engineering Service)
Cc: dev at dpdk.org
Subject: RE: [dpdk-dev] Traffic scheduling in
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Wednesday, January 06, 2016 5:23 PM
> To: Ananyev, Konstantin
> Cc: N?lio Laranjeiro; Tan, Jianfeng; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 01/12] ethdev: add API to query what/if packet
On 07/01/2016 09:51, Sergio Gonzalez Monroy wrote:
> On 07/01/2016 09:33, Sergio Gonzalez Monroy wrote:
>> On 05/01/2016 09:37, Ralf Hoffmann wrote:
>>> with only one hugepage or already sorted hugepage addresses, the sort
>>> function called memcpy with same src and dst pointer. Debugging with
>>>
On Mon, Jan 04, 2016 at 05:56:49PM +, Xie, Huawei wrote:
> On 1/5/2016 1:24 AM, Stephen Hemminger wrote:
> > On Mon, 4 Jan 2016 01:56:13 +0800
> > Huawei Xie wrote:
> >
> >> + if (pci_dev->kdrv != RTE_KDRV_NONE) {
> >> + PMD_INIT_LOG(INFO,
> >> + "kernel driver is m
On Thu, Jan 07, 2016 at 10:24:19AM +, Ananyev, Konstantin wrote:
>
>
> > -Original Message-
> > From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> > Sent: Wednesday, January 06, 2016 5:23 PM
> > To: Ananyev, Konstantin
> > Cc: N?lio Laranjeiro; Tan, Jianfeng; dev at dpdk.
Hi Sergio,
On 07.01.2016 11:38, Sergio Gonzalez Monroy wrote:
>> Forgot to mention that there is a checkpatch warning:
>> WARNING:LONG_LINE: line over 90 characters
>> #113: FILE: lib/librte_eal/linuxapp/eal/eal_memory.c:1167:
>> + qsort(&tmp_hp[hp_offset], hpi->num_pages[0],
>> size
with only one hugepage or already sorted hugepage addresses, the sort
function called memcpy with same src and dst pointer. Debugging with
valgrind will issue a warning about overlapping area. This patch changes
the sort method to qsort to avoid this behavior. The separate sort
function is no longe
On 01/03/2016 07:56 PM, Huawei Xie wrote:
> v2 changes:
> change LOG level from ERR to INFO
>
> virtio PMD could use IO port to configure the virtio device without
> using uio driver.
>
> There are two issues with previous implementation:
> 1) virtio PMD will take over each virtio device blindly
Hi Ralf,
It seems like the title update you did for v3 is missing in this patch.
On 07/01/2016 13:59, Ralf Hoffmann wrote:
> with only one hugepage or already sorted hugepage addresses, the sort
> function called memcpy with same src and dst pointer. Debugging with
> valgrind will issue a warning
with only one hugepage or already sorted hugepage addresses, the sort
function called memcpy with same src and dst pointer. Debugging with
valgrind will issue a warning about overlapping area. This patch changes
the sort method to qsort to avoid this behavior. The separate sort
function is no longe
This v3 patch uses vfio-noiommu-way to access virtio-net pci interface.
Tested for arm64 thunderX platform. Patch builds for
x86/i386/arm/armv8/thunderX.
The patchset has below dependancy:
- Kernel should be patched with Alex vfio-noiommu patch, available at linuz-next
[1].
- Anatoly's dpdk patch
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 non-sse/
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 |1
iopl() syscall not supported in linux-arm/arm64 so always return 0 value.
Signed-off-by: Santosh Shukla
Acked-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
i
vfio_pci_mmap() try to map all pci bars. ioport region ar not mapped in
vfio/kernel so ignore mmaping for ioport.
Signed-off-by: Santosh Shukla
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 20
1 file changed, 20 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/e
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 1
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
---
lib/librt
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
---
drivers/net/virtio/virtio_vfio.h | 146 ++
1 file changed, 146 insertions(+)
create mode
- adding pci_dev member in struct virtio_hw{} to track
vfio_dev_fd per virtio interface, required for ioport
rd/wr operation.
- Masked default VIRTIO_READ/WRITE for vfio case.
Signed-off-by: Santosh Shukla
Signed-off-by: Rizwan Ansari
Signed-off-by: Rakesh Krishnamurhty
---
drivers/net/virtio
Flag required for vfio case, It helps to update vfio_dev_fd for each
virtio net interface.
Signed-off-by: Santosh Shukla
---
drivers/net/virtio/virtio_ethdev.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
inde
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
---
config/defconfig_arm-armv7a-linuxapp-gcc |6 +-
config/defconfig_arm64-armv8a-linuxapp-gcc |6 +-
2 files changed, 10 insertions(+), 2
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 eal_pci_init.h and a DMA
mapping f
From: Rizwan Ansari
Patch fixes below build error:
/home/mv/work/thunder/santosh/dpdk/santosh/dpdk/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c:
In function ?pci_vfio_set_iommu_type?:
/home/mv/work/thunder/santosh/dpdk/santosh/dpdk/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c:243:2:
error: ?for? loop
Hi Santosh,
> Patch fixes below build error:
> /home/mv/work/thunder/santosh/dpdk/santosh/dpdk/lib/librte_eal/linuxa
> pp/eal/eal_pci_vfio.c:
> In function ?pci_vfio_set_iommu_type?:
> /home/mv/work/thunder/santosh/dpdk/santosh/dpdk/lib/librte_eal/linuxa
> pp/eal/eal_pci_vfio.c:243:2:
> error: ?fo
On Thu, 7 Jan 2016 22:03:00 +0530
Santosh Shukla wrote:
> #else
> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> + return 0; /* iopl syscall not supported for ARM/ARM64 */
> +#endif
> return -1;
> #endif
Minor net why not:
#elif defined(RTE_ARCH_ARM) || defined(RTE_ARCH_AR
This looks like the right thing to do. Minor nits.
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> index 74f91ba..4077eb6 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> @@ -7
On Thu, 7 Jan 2016 22:03:03 +0530
Santosh Shukla wrote:
>
> +int rte_eal_pci_read_bar(const struct rte_pci_device *device __rte_unused,
> + void *buf __rte_unused,
> + size_t len __rte_unused,
> + off_t offset __rte_unused,
> +
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_DETACHABLE,
> +#else
> .drv_flags = RTE_PCI_DRV_DETACHABLE,
> +#endif
Since VFIO is determined at runtime not compile time, the flags
On 1/7/16, 12:19 PM, "dev on behalf of Stephen Hemminger" wrote:
>On Thu, 7 Jan 2016 22:03:03 +0530
>Santosh Shukla wrote:
>
>>
>> +int rte_eal_pci_read_bar(const struct rte_pci_device *device __rte_unused,
>> + void *buf __rte_unused,
>> + size_t len _
On Thu, 7 Jan 2016 18:26:30 +
"Wiles, Keith" wrote:
> On 1/7/16, 12:19 PM, "dev on behalf of Stephen Hemminger" dpdk.org on behalf of stephen at networkplumber.org> wrote:
>
> >On Thu, 7 Jan 2016 22:03:03 +0530
> >Santosh Shukla wrote:
> >
> >>
> >> +int rte_eal_pci_read_bar(const struc
42 matches
Mail list logo
