[dpdk-dev] [PATCH] lpm: fix overflow issue

[Igor Ryzhov]

Hello again. Will anybody review this patch?
This is really critical issue, because it can lead to memory corruption and
break any program using LPM.

CCing this to Bruce Richardson, because he is maintainer of LPM.

Regards,
Igor Ryzhov

On Fri, Feb 20, 2015 at 4:16 PM, Igor Ryzhov  wrote:

> LPM table overflow may occur if table is full and added rule has the
> biggest depth that already have some rules.
>
> Signed-off-by: Igor Ryzhov 
> ---
>  lib/librte_lpm/rte_lpm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
> index 983e04b..cc51210 100644
> --- a/lib/librte_lpm/rte_lpm.c
> +++ b/lib/librte_lpm/rte_lpm.c
> @@ -298,6 +298,9 @@ rule_add(struct rte_lpm *lpm, uint32_t ip_masked,
> uint8_t depth,
> return rule_index;
> }
> }
> +
> +   if (rule_index == lpm->max_rules)
> +   return -ENOSPC;
> } else {
> /* Calculate the position in which the rule will be
> stored. */
> rule_index = 0;
> --
> 1.9.3 (Apple Git-50)
>
>


-- 
Regards,
Igor Ryzhov

[dpdk-dev] [PATCH v3 0/5] Integrate flex filter in igb driver to new API

[Thomas Monjalon]

2015-02-21 01:53, Pablo de Lara:
> The patch set uses new filter_ctrl API to replace old flex filter APIs.
> It uses new functions and structure to replace old ones in igb driver, new 
> commands to replace old ones in testpmd, and removes the old APIs.
> 
> v3 changes:
>  - fix testpmd documentation
> 
> v2 changes:
>  - split one patch to patch series
>  - change the command's format in testpmd.
>  - add doc changes in testpmd_funcs.rst
>  - correct the errors reported by checkpatch.pl
> 
> Jingjing Wu (5):
>   ethdev: define flex filter type and its structure
>   e1000: new functions replace old ones for flex filter
>   testpmd: new commands for flex filter
>   ethdev: remove old APIs and structures of flex filter
>   doc: commands changed in testpmd_funcs for flex filter

Applied, thanks.
I also updated version map to remove old API.

[dpdk-dev] [PATCH v2 0/6] Integrate syn filter in igb/ixgbe driver to new API

[Thomas Monjalon]

> v2 changes:
>  - split one patch to patch series
>  - change the command's format in testpmd.
>  - return -ENOENT when deleting a disabled syn filter.
>  - add doc changes in testpmd_funcs.rst
>  - correct the errors reported by checkpatch.pl
> 
> The patch set uses new filter_ctrl API to replace old syn filter APIs.
> It uses new functions and structure to replace old ones in igb/ixgbe driver,
> new commands to replace old ones in testpmd, and removes the old APIs.
> 
> Jingjing Wu (6):
>   ethdev: define syn filter type and its structure
>   ixgbe: new functions replace old ones for syn filter
>   e1000: new functions replace old ones for syn filter
>   testpmd: new commands for syn filter
>   ethdev: remove old APIs and structures of syn filter
>   doc: commands changed in testpmd_funcs for syn filter

Applied, thanks.
I removed the old API functions from the version map.

[dpdk-dev] [PATCH v10 13/14] eal/pci: Add rte_eal_dev_attach/detach() functions

[Tetsuya Mukawa]

On 2015/02/21 21:49, Maxime Leroy wrote:
> Hi Tetsuya,
>
> On Sat, Feb 21, 2015 at 4:49 AM, Tetsuya Mukawa  wrote:
>> On 2015/02/21 0:20, Maxime Leroy wrote:
> [...]
>>> Why you want to add devargs in the devargs_list, if there are no needs
>>> to store this information ?
>> In eal initialization code, virtual device names stored in devargs are
>> checked not to register a same device name twice.
>> And each init function of PMD just trust a device name received by eal.
>> So there is no code in PMD to check whether device name is unique.
>>
> I disagree with you. This check is not present in the master branch.
>
> You have added this check in your hotplug patchset, in this patch:
> [PATCH v10 10/14] eal/pci: Add a function to remove the entry of
> devargs list
> See: http://dpdk.org/ml/archives/dev/2015-February/013712.html
>
> Thus the problem should be already exist without your patches in the
> master branch.
>
> For example according to you, this testpmd command should create 2
> devices with the same name:
> testpmd -c 0xc --vdev eth_pcap0,iface=eth0 --vdev eth_pcap0,iface=eth1
> -n 2 -- -i
>
> But it's not the case:
> PMD: Initializing pmd_pcap for eth_pcap0
> PMD: Creating pcap-backed ethdev on numa socket 0
> PMD: Initializing pmd_pcap for eth_pcap0
> PMD: Creating pcap-backed ethdev on numa socket 0
> PMD: rte_eth_dev_allocate: Ethernet Device with name eth_pcap0 already
> allocated!
>
> In fact, it's not possible for any PMD_VDEV in the dpdk repo to create
> 2 devices with the same name.
> All the virtual device initialization functions use the
> rte_eth_dev_allocate function. This function prevents to create two
> ethernet devices with the same name:
>
>  if (rte_eth_dev_allocated(name) != NULL) {
> PMD_DEBUG_TRACE("Ethernet Device with name %s already
> allocated!\n", name);
> return NULL;
> }
>

Ah, You are right.

>> For example, according to your suggestion, how to prevent below case?
>> $ ./testpmd -c f -n 1 -- -i
>> testpmd> port attach eth_pcap0,iface=eth0
>> testpmd> port attach eth_pcap0,iface=eth1
>>
>> Also, type below, after doing above.
>> testpmd> port detach 0
>>
>> Probably port 0 will be "eth_pcap0,iface=eth0".
>> But uninit code of PMD only receives a device name like 'eth_pcap0'.
>> (We have 2 'eth_pcap0' devices in PMD.)
>>
>> To prevent above case, probably we have 2 options at least.
>> One is changing init code of all virtual PMDs not to register same
>> device name.
> There are no need to change init code of all virtual PMDs to not
> register the same device name 2 times.
> Because it's already not possible to create 2 virtual device with the
> same name. (see my point above)
>
>> The other is to use devargs_list in EAL, and call init code of PMD with
>> a unique device name.
> Thus there are no needs to use the devargs_list for that.
>
> [..]
>>> But you don't call rte_eal_devargs_add with RTE_DEVTYPE_WHILISTED_PCI
>>> in  rte_eal_dev_attach_pdev ?
>> Yes, I don't.
>> Hotplug functions should not change BLACKLIST and WHITELIST.
>> So not to touch the list is correct behavior.
> Yes the correct behaviour for Hotplug functions is to not use the
> devargs_list for physical and virtual devices !

I totally agree with you now.
It seems I have a missunderstanding about code not to duplicate a vdev name.
Thanks for your suggestions, I will fix it in next patches.

Regards,
Tetsuya


>
> Regards,
>
> Maxime

[dpdk-dev] [PATCH v3 0/6] new ntuple filter replaces 2tuple and 5tuple filters

[Thomas Monjalon]

2015-02-20 17:29, De Lara Guarch, Pablo:
> From: Wu, Jingjing
> > 
> > v2 changes:
> >   - remove the code which is already applied in patch "Integrate ethertype
> > filter in igb/ixgbe driver to new API".
> >   - modify commands' description in doc testpmd_funcs.rst.
> > 
> > v3 change:
> >   - remove the UINT32_BIT definition in ixgbe driver
> 
> Acked-by: Pablo de Lara 

Applied, thanks.
There were a lot of conflicts. Thanks for checking all is ok.
I also removed old functions from version map.

[dpdk-dev] Testpmd returns error.

[Tetsuya Mukawa]

Hi,

In my environment, testpmd in latest master branch returns error like below.

$ sudo ./tools/dpdk_nic_bind.py -b igb_uio :02:00.0
$ sudo ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 1 -- -i
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 6 on socket 0
EAL: Detected lcore 7 as core 7 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 8 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Setting up memory...
EAL: Ask a virtual area of 0x28000 bytes
EAL: Virtual area found at 0x7ffd4000 (size = 0x28000)
EAL: Requesting 10 pages of size 1024MB from socket 0
EAL: TSC frequency is ~3991450 KHz
EAL: Master core 0 is ready (tid=f7fd6840)
PMD: ENICPMD trace: rte_enic_pmd_init
EAL: Core 3 is ready (tid=f58e0700)
EAL: Core 2 is ready (tid=f60e1700)
EAL: Core 1 is ready (tid=f68e2700)
EAL: PCI device :02:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10b9 rte_em_pmd
EAL:   PCI memory mapped at 0x7fffc000
EAL: pci_map_resource(): cannot mmap(23, 0x7fffc002, 0x2,
0x1000): Invalid argument (0x)
EAL: Error - exiting with code: 1
  Cause: Requested device :02:00.0 cannot be used


I've run git-bisect, and it seems following commit cause this error.

commit 4a499c64959074ba6fa6a5a2b3a2a6aa10627fa1
Author: Danny Zhou 
Date:   Fri Feb 20 16:59:15 2015 +

eal/linux: enable uio_pci_generic support

Someone, could you please check it?

Thanks,
Tetsuya

[dpdk-dev] [PATCH] mk: add support for gdb debug info generation

[Marc Sune]

I don't like the proposed patch, but I am recovering this old thread 
because I agree on the problem statement.

On 04/04/14 11:57, Ananyev, Konstantin wrote:
> Hi Cyril,
> We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you can use to 
> enable debug, or any other compiler/linker options you need.
> Wonder, why that is not enough?

EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why 
setting individually:

diff --git a/config/common_linuxapp b/config/common_linuxapp
index 2f9643b..04adc0d 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y
  # Compile generic ethernet library
  #
  CONFIG_RTE_LIBRTE_ETHER=y
-CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
+CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y


to put an example, does not set -g and -O0 in that particular module 
only. No one would ever use something compiled in DEBUG in production 
anyway.

I always end up modifying manually Makefiles in the lib library that I 
am interested in having insides, overriding CFLAGS=-O3, which is not 
that nice.

Marc

> Thanks
> Konstantin
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cyril Chemparathy
> Sent: Thursday, April 03, 2014 6:31 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation
>
> It is often useful to build with debug enabled, we add a config
> (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so.
>
> Note: This patch does not include corresponding changes for ICC.  The author 
> pleads abject ignorance in this regard, and welcomes recommendations. :-)
>
> Signed-off-by: Cyril Chemparathy 
> ---
>   config/defconfig_x86_64-default-linuxapp-gcc | 1 +
>   mk/toolchain/gcc/rte.vars.mk | 5 +
>   2 files changed, 6 insertions(+)
>
> diff --git a/config/defconfig_x86_64-default-linuxapp-gcc 
> b/config/defconfig_x86_64-default-linuxapp-gcc
> index f11ffbf..3b36efd 100644
> --- a/config/defconfig_x86_64-default-linuxapp-gcc
> +++ b/config/defconfig_x86_64-default-linuxapp-gcc
> @@ -67,6 +67,7 @@ CONFIG_RTE_ARCH_X86_64=y  #  CONFIG_RTE_TOOLCHAIN="gcc"
>   CONFIG_RTE_TOOLCHAIN_GCC=y
> +CONFIG_RTE_TOOLCHAIN_DEBUG=n
>   
>   #
>   # Use intrinsics or assembly code for key routines diff --git 
> a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk index 
> 0edb93f..81ed3fa 100644
> --- a/mk/toolchain/gcc/rte.vars.mk
> +++ b/mk/toolchain/gcc/rte.vars.mk
> @@ -68,6 +68,11 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS)))  endif  endif
>   
> +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y)
> +TOOLCHAIN_CFLAGS += -g -ggdb
> +TOOLCHAIN_LDFLAGS += -g -ggdb
> +endif
> +
>   WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes  
> WERROR_FLAGS += -Wmissing-declarations -Wold-style-definition -Wpointer-arith 
>  WERROR_FLAGS += -Wcast-align -Wnested-externs -Wcast-qual
> --
> 1.8.3.1
>

[dpdk-dev] Testpmd returns error.

[Thomas Monjalon]

Hi Tetsuya,

2015-02-22 14:30, Tetsuya Mukawa:
> Hi,
> 
> In my environment, testpmd in latest master branch returns error like below.
> 
> $ sudo ./tools/dpdk_nic_bind.py -b igb_uio :02:00.0
> $ sudo ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 1 -- -i
> EAL: Detected lcore 0 as core 0 on socket 0
> EAL: Detected lcore 1 as core 1 on socket 0
> EAL: Detected lcore 2 as core 2 on socket 0
> EAL: Detected lcore 3 as core 3 on socket 0
> EAL: Detected lcore 4 as core 4 on socket 0
> EAL: Detected lcore 5 as core 5 on socket 0
> EAL: Detected lcore 6 as core 6 on socket 0
> EAL: Detected lcore 7 as core 7 on socket 0
> EAL: Support maximum 128 logical core(s) by configuration.
> EAL: Detected 8 lcore(s)
> EAL: VFIO modules not all loaded, skip VFIO support...
> EAL: Setting up memory...
> EAL: Ask a virtual area of 0x28000 bytes
> EAL: Virtual area found at 0x7ffd4000 (size = 0x28000)
> EAL: Requesting 10 pages of size 1024MB from socket 0
> EAL: TSC frequency is ~3991450 KHz
> EAL: Master core 0 is ready (tid=f7fd6840)
> PMD: ENICPMD trace: rte_enic_pmd_init
> EAL: Core 3 is ready (tid=f58e0700)
> EAL: Core 2 is ready (tid=f60e1700)
> EAL: Core 1 is ready (tid=f68e2700)
> EAL: PCI device :02:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10b9 rte_em_pmd
> EAL:   PCI memory mapped at 0x7fffc000
> EAL: pci_map_resource(): cannot mmap(23, 0x7fffc002, 0x2,
> 0x1000): Invalid argument (0x)
> EAL: Error - exiting with code: 1
>   Cause: Requested device :02:00.0 cannot be used
> 
> 
> I've run git-bisect, and it seems following commit cause this error.
> 
> commit 4a499c64959074ba6fa6a5a2b3a2a6aa10627fa1
> Author: Danny Zhou 
> Date:   Fri Feb 20 16:59:15 2015 +
> 
> eal/linux: enable uio_pci_generic support

Thank you Tetsuya for reporting and sorry to disturb you with this new problem.
Please ignore this patchset in your hotplug development.

> Someone, could you please check it?

It is possible that this patchset was not correctly tested.
We might revert it or try to fix it.
I think the decision should be done by its authors (Danny, Bruce),
or the Linux EAL maintainer (David).

David, any opinion?

[dpdk-dev] Testpmd returns error.

[David Marchand]

Hello,

On Sun, Feb 22, 2015 at 3:17 PM, Thomas Monjalon 
wrote:

> Hi Tetsuya,
>
> > Someone, could you please check it?
>
> It is possible that this patchset was not correctly tested.
> We might revert it or try to fix it.
> I think the decision should be done by its authors (Danny, Bruce),
> or the Linux EAL maintainer (David).
>

Well, I need to have a deeper look at this change.
I did not find time before my holidays.

- I think there may be an issue with the use of resource0 instead of
/dev/uio.
I am not sure uio mmap will be happy or I overlooked something trivial.

- Testing proc type in pci_uio_map_resource() looks wrong to me, since we
validated earlier in this same function that we are in primary process.

- uio_res->maps indexes are not the same as the pci resources, might
trigger problems (and it clearly does not make it easy to read ...).
And now we are reading sysfs twice.
I would prefer this code is reworked so that we avoid those loops in
eal_pci_uio.c.


Anyway, I am still on holiday (I should have kept my laptop away ...), I
will be back tomorrow.
I suppose Bruce or Danny will come with a fix, let's decide what the best
solution is at this moment.


-- 
David Marchand

[dpdk-dev] [PATCH v2 00/11] qemu vhost-user support

[Thomas Monjalon]

2015-02-16 17:19, Tetsuya Mukawa:
> On 2015/02/12 14:07, Huawei Xie wrote:
> > vhost-user supports passing vring information to a seperate vhost enabled
> > user space process, normally a user space vSwitch, through unix domain 
> > socket.
> >
> > In previous DPDK version, we implement a user space character device driver
> > vhost-cuse in user space DPDK process. vring information is passed to the
> > cuse driver through ioctl call, including eventfds for interrupt injection 
> > and
> > host notification. A kernel module is developed to copy these fds from
> > qemu process into our process. We also need some trick to map guest memory.
> > (TODO: kickfd/callfd is reversed which causes confusion)
> >
> > known issue in vhost-user implementation in QEMU, reported by haifeng.lin 
> > at huawei.com
> > * QEMU doesn't send correct memory region information with multiple numa 
> > node configuration
> > http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg01454.html
> >
> > Thanks Tetsuya for reporting the issue that "FD_ISSET would crash when 
> > receive -1
> > as fd on Ubuntu 14.04".
> >
> > Huawei Xie (11):
> >  enable VIRTIO_NET_F_CTRL_RX
> >  create vhost_cuse directory and move vhost-net-cdev.c into vhost_cuse
> >  rename vhost-net-cdev.h to vhost-net.h
> >  move fd copying(from qemu process into vhost process) to eventfd_copy.c
> >  copy host_memory_map from virtio-net.c to a new file virtio-net-cdev.c
> >  make host_memory_map a more generic function.
> >  implement cuse_set_memory_table in virtio-net-cdev.c
> >  add select based event driven processing
> >  vhost user support
> >  support dev->ifname
> >  support calling rte_vhost_driver_register after 
> > rte_vhost_driver_session_start
> 
> Hi Xie,
> 
> I have 2 questions about v2 patches.
> Could you please check my other emails?

I tried to locally applied the patches, waiting comments are closed.
But I stopped after patch 04/11 which makes compilation failing.
I'm so sorry that we still don't have a vhost-user support integrated in DPDK.
I feel it won't be ready in next days to be able to enter in 2.0 version.

[dpdk-dev] [PATCH] lpm: fix overflow issue

[Richardson, Bruce]

Sorry I missed this Friday. I'll look at it  shortly.



On 21 Feb 2015, at 22:56, Igor Ryzhov mailto:iryzhov at 
nfware.com>> wrote:

Hello again. Will anybody review this patch?
This is really critical issue, because it can lead to memory corruption and 
break any program using LPM.

CCing this to Bruce Richardson, because he is maintainer of LPM.

Regards,
Igor Ryzhov

On Fri, Feb 20, 2015 at 4:16 PM, Igor Ryzhov mailto:iryzhov at nfware.com>> wrote:
LPM table overflow may occur if table is full and added rule has the biggest 
depth that already have some rules.

Signed-off-by: Igor Ryzhov mailto:iryzhov at nfware.com>>
---
 lib/librte_lpm/rte_lpm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index 983e04b..cc51210 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -298,6 +298,9 @@ rule_add(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t 
depth,
return rule_index;
}
}
+
+   if (rule_index == lpm->max_rules)
+   return -ENOSPC;
} else {
/* Calculate the position in which the rule will be stored. */
rule_index = 0;
--
1.9.3 (Apple Git-50)




--
Regards,
Igor Ryzhov

[dpdk-dev] [PATCH] lpm: fix overflow issue

[Igor Ryzhov]

Great. The easiest way to reproduce the issue is to fill LPM table with
rules using only one depth and try to add another one rule with same depth.
Rule will be successfully added and memory will be corrupted.

???, 22 ??? 2015 ?.  Richardson, Bruce ???:

> Sorry I missed this Friday. I'll look at it  shortly.
>
>
>
> On 21 Feb 2015, at 22:56, Igor Ryzhov 
> > wrote:
>
> Hello again. Will anybody review this patch?
> This is really critical issue, because it can lead to memory corruption
> and break any program using LPM.
>
> CCing this to Bruce Richardson, because he is maintainer of LPM.
>
> Regards,
> Igor Ryzhov
>
> On Fri, Feb 20, 2015 at 4:16 PM, Igor Ryzhov  > wrote:
> LPM table overflow may occur if table is full and added rule has the
> biggest depth that already have some rules.
>
> Signed-off-by: Igor Ryzhov  iryzhov at nfware.com >>
> ---
>  lib/librte_lpm/rte_lpm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
> index 983e04b..cc51210 100644
> --- a/lib/librte_lpm/rte_lpm.c
> +++ b/lib/librte_lpm/rte_lpm.c
> @@ -298,6 +298,9 @@ rule_add(struct rte_lpm *lpm, uint32_t ip_masked,
> uint8_t depth,
> return rule_index;
> }
> }
> +
> +   if (rule_index == lpm->max_rules)
> +   return -ENOSPC;
> } else {
> /* Calculate the position in which the rule will be
> stored. */
> rule_index = 0;
> --
> 1.9.3 (Apple Git-50)
>
>
>
>
> --
> Regards,
> Igor Ryzhov
>

[dpdk-dev] Testpmd returns error.

[Richardson, Bruce]

On 22 Feb 2015, at 16:19, David Marchand mailto:david.marchand at 6wind.com>> wrote:

Hello,

On Sun, Feb 22, 2015 at 3:17 PM, Thomas Monjalon mailto:thomas.monjalon at 6wind.com>> wrote:
Hi Tetsuya,

> Someone, could you please check it?

It is possible that this patchset was not correctly tested.
We might revert it or try to fix it.
I think the decision should be done by its authors (Danny, Bruce),
or the Linux EAL maintainer (David).

Well, I need to have a deeper look at this change.
I did not find time before my holidays.

- I think there may be an issue with the use of resource0 instead of /dev/uio.
I am not sure uio mmap will be happy or I overlooked something trivial.

- Testing proc type in pci_uio_map_resource() looks wrong to me, since we 
validated earlier in this same function that we are in primary process.

- uio_res->maps indexes are not the same as the pci resources, might trigger 
problems (and it clearly does not make it easy to read ...).
And now we are reading sysfs twice.
I would prefer this code is reworked so that we avoid those loops in 
eal_pci_uio.c.


Anyway, I am still on holiday (I should have kept my laptop away ...), I will 
be back tomorrow.
I suppose Bruce or Danny will come with a fix, let's decide what the best 
solution is at this moment.



I'll take another look at this but unfortunately I don't think I can 
necessarily reproduce this issue as it seems to occur with enic driver, but I 
will try.

--
David Marchand

[dpdk-dev] [PATCH] lpm: fix overflow issue

[Bruce Richardson]

On Fri, Feb 20, 2015 at 04:16:46PM +0300, Igor Ryzhov wrote:
> LPM table overflow may occur if table is full and added rule has the biggest 
> depth that already have some rules.
> 
> Signed-off-by: Igor Ryzhov 
Acked-by: Bruce Richardson 

> ---
>  lib/librte_lpm/rte_lpm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
> index 983e04b..cc51210 100644
> --- a/lib/librte_lpm/rte_lpm.c
> +++ b/lib/librte_lpm/rte_lpm.c
> @@ -298,6 +298,9 @@ rule_add(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t 
> depth,
>   return rule_index;
>   }
>   }
> +
> + if (rule_index == lpm->max_rules)
> + return -ENOSPC;
>   } else {
>   /* Calculate the position in which the rule will be stored. */
>   rule_index = 0;
> -- 
> 1.9.3 (Apple Git-50)
> 

[dpdk-dev] Testpmd returns error.

[Bruce Richardson]

On Sun, Feb 22, 2015 at 06:51:58PM +, Richardson, Bruce wrote:
> 
> 
> 
> 
> On 22 Feb 2015, at 16:19, David Marchand  6wind.com> wrote:
> 
> Hello,
> 
> On Sun, Feb 22, 2015 at 3:17 PM, Thomas Monjalon  6wind.com> wrote:
> Hi Tetsuya,
> 
> > Someone, could you please check it?
> 
> It is possible that this patchset was not correctly tested.
> We might revert it or try to fix it.
> I think the decision should be done by its authors (Danny, Bruce),
> or the Linux EAL maintainer (David).
> 
> Well, I need to have a deeper look at this change.
> I did not find time before my holidays.
> 
> - I think there may be an issue with the use of resource0 instead of /dev/uio.
> I am not sure uio mmap will be happy or I overlooked something trivial.
> 
> - Testing proc type in pci_uio_map_resource() looks wrong to me, since we 
> validated earlier in this same function that we are in primary process.
> 
> - uio_res->maps indexes are not the same as the pci resources, might trigger 
> problems (and it clearly does not make it easy to read ...).
> And now we are reading sysfs twice.
> I would prefer this code is reworked so that we avoid those loops in 
> eal_pci_uio.c.
> 
> 
> Anyway, I am still on holiday (I should have kept my laptop away ...), I will 
> be back tomorrow.
> I suppose Bruce or Danny will come with a fix, let's decide what the best 
> solution is at this moment.
> 
> 
> 
> I'll take another look at this but unfortunately I don't think I can 
> necessarily reproduce this issue as it seems to occur with enic driver, but I 
> will try.

Please ignore above from me, now that I'm able to read my mail on more than a 
phone
screen, I can actually read things properly... :-)

I'll look into this now, see if it's something simple I can spot to fix.

/Bruce
> 
> --
> David Marchand

[dpdk-dev] Testpmd returns error.

[Bruce Richardson]

On Sun, Feb 22, 2015 at 02:30:02PM +0900, Tetsuya Mukawa wrote:
> Hi,
> 
> In my environment, testpmd in latest master branch returns error like below.
> 
> $ sudo ./tools/dpdk_nic_bind.py -b igb_uio :02:00.0
> $ sudo ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 1 -- -i
> EAL: Detected lcore 0 as core 0 on socket 0
> EAL: Detected lcore 1 as core 1 on socket 0
> EAL: Detected lcore 2 as core 2 on socket 0
> EAL: Detected lcore 3 as core 3 on socket 0
> EAL: Detected lcore 4 as core 4 on socket 0
> EAL: Detected lcore 5 as core 5 on socket 0
> EAL: Detected lcore 6 as core 6 on socket 0
> EAL: Detected lcore 7 as core 7 on socket 0
> EAL: Support maximum 128 logical core(s) by configuration.
> EAL: Detected 8 lcore(s)
> EAL: VFIO modules not all loaded, skip VFIO support...
> EAL: Setting up memory...
> EAL: Ask a virtual area of 0x28000 bytes
> EAL: Virtual area found at 0x7ffd4000 (size = 0x28000)
> EAL: Requesting 10 pages of size 1024MB from socket 0
> EAL: TSC frequency is ~3991450 KHz
> EAL: Master core 0 is ready (tid=f7fd6840)
> PMD: ENICPMD trace: rte_enic_pmd_init
> EAL: Core 3 is ready (tid=f58e0700)
> EAL: Core 2 is ready (tid=f60e1700)
> EAL: Core 1 is ready (tid=f68e2700)
> EAL: PCI device :02:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10b9 rte_em_pmd
> EAL:   PCI memory mapped at 0x7fffc000
> EAL: pci_map_resource(): cannot mmap(23, 0x7fffc002, 0x2,
> 0x1000): Invalid argument (0x)
> EAL: Error - exiting with code: 1
>   Cause: Requested device :02:00.0 cannot be used
> 
> 
> I've run git-bisect, and it seems following commit cause this error.
> 
> commit 4a499c64959074ba6fa6a5a2b3a2a6aa10627fa1
> Author: Danny Zhou 
> Date:   Fri Feb 20 16:59:15 2015 +
> 
> eal/linux: enable uio_pci_generic support
> 
> Someone, could you please check it?
> 
> Thanks,
> Tetsuya
> 

Hi Tetsuya,

trying to reproduce the problem here, with no success so far with a mix of 1G
and 10G ports. Is there anything special about your environment that might 
especially trigger this issue? Is it a VM or running on the host machine etc.?

Regards,
/Bruce

[dpdk-dev] [PATCH v2 0/7] unified flow types and RSS offload types

[Thomas Monjalon]

> > It unifies the flow types and RSS offload types for all PMDs. Previously 
> > flow
> > types are defined specifically for i40e, and there has different RSS 
> > offloads
> > tyeps for 1/10G and 40G seperately. This is not so convenient for 
> > application
> > development, and not good for adding new PMDs.
> > In addition, it enables new RSS offloads of 'tcp' and 'all' in testpmd.
> > 
> > v2 changes:
> > * Integrated with configuring hash functions.
> > * Corrected the wrong help string of flow director parameters.
> > * Renamed the flow types from ETH_FLOW_TYPE_ to RTE_ETH_FLOW_.
> > * Removed useless annotations for flow type elements in rte_eth_ctrl.h.
> > 
> > Helin Zhang (7):
> >   app/test-pmd: code style fix
> >   ethdev: code style fix
> >   i40e: code style fix
> >   ethdev: fix of calculating the size of flow type mask array
> >   ethdev: unification of flow types
> >   ethdev: unification of RSS offload types
> >   app/testpmd: support new rss offloads
> 
> Acked-by: Jingjing Wu 

Applied, thanks
There were some difficult merges with new flow director API and fm10K.
Please check everything is OK.

[dpdk-dev] [PATCH 0/8] Improve build process

[Neil Horman]

On Fri, Feb 20, 2015 at 02:31:36PM +, Gonzalez Monroy, Sergio wrote:
> On 13/02/2015 12:51, Neil Horman wrote:
> >On Fri, Feb 13, 2015 at 11:08:02AM +, Gonzalez Monroy, Sergio wrote:
> >>On 13/02/2015 10:14, Panu Matilainen wrote:
> >>>On 02/12/2015 05:52 PM, Neil Horman wrote:
> On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote:
> >On 02/12/2015 02:23 PM, Neil Horman wrote:
> >>>[...snip...]
> >So I just realized that I was not having into account a possible
> >scenario, where
> >we have an app built with static dpdk libs then loading a dso
> >with -d
> >option.
> >
> >In such case, because the pmd would have DT_NEEDED entries,
> >dlopen will
> >fail.
> >So to enable such scenario we would need to build PMDs without
> >DT_NEEDED
> >entries.
> Hmm, for that to be a problem you'd need to have the PMD built
> against
> shared dpdk libs and while the application is built against
> static dpdk
> libs. I dont think that's a supportable scenario in any case.
> 
> Or is there some other scenario that I'm not seeing?
> 
> - Panu -
> 
> >>>I agree with you. I suppose it comes down to, do we want to
> >>>support such
> >>>scenario?
> >>>
> >>> From what I can see, it seems that we do currently support such
> >>>scenario by
> >>>building dpdk apps against all static dpdk libs using
> >>>--whole-archive (all
> >>>libs and not only PMDs).
> >>>http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8
> >>>
> >>>
> >>>Am I misunderstanding this?
> >>>
> >>Shoot, you're right, I missed the static build aspect to this.  Yes,
> >>if we do the following:
> >>
> >>1) Build the DPDK as a static library
> >>2) Link an application against (1)
> >>3) Use the dlopen mechanism to load a PMD built as a DSO
> >>
> >>Then the DT_NEEDED entries in the DSO will go unsatisfied, because
> >>the shared
> >>objects on which it (the PMD) depends will not exist in the file
> >>system.
> >I think its even more twisty:
> >
> >1) Build the DPDK as a static library
> >2) Link an application against (1)
> >3) Do another build of DPDK as a shared library
> >4) In app 2), use the dlopen mechanism to load a PMD built as a part
> >of or
> >against 3)
> >
> >Somehow I doubt this would work very well.
> >
> Ideally it should, presuming the ABI is preserved between (1) and (3),
> though I
> agree, up until recently, that was an assumption that was unreliable.
> >>>Versioning is a big and important step towards reliability but there are
> >>>more issues to solve. This of course getting pretty far from the original
> >>>topic, but at least one such issue is that there are some cases where a
> >>>config value affects what are apparently public structs (rte_mbuf wrt
> >>>RTE_MBUF_REFCNT for example), which really is a no-go.
> >>>
> >>Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap.
> >>I'll look into it.
> >>
> >>I think the problem is a little bit orthogonal to the libdpdk_core
> >>problem you
> >>were initially addressing.  That is to say, this problem of
> >>dlopen-ed PMD's
> >>exists regardless of weather you build the DPDK as part of a static
> >>or dynamic
> >>library.  The problems just happen to intersect in their
> >>manipulation of the
> >>DT_NEEDED entries.
> >>
> >>Ok, so, given the above, I would say your approach is likely
> >>correct, just
> >>prevent DT_NEEDED entries from getting added to PMD's. Doing so will
> >>sidestep
> >>loading issue for libraries that may not exist in the filesystem,
> >>but thats ok,
> >>because by all rights, the symbols codified in those needed
> >>libraries should
> >>already be present in the running application (either made available
> >>by the
> >>application having statically linked them, or having the linker load
> >>them from
> >>the proper libraries at run time).
> >My 5c is that I'd much rather see the common case (all static or all
> >shared)
> >be simple and reliable, which in case of DSOs includes no lying
> >(whether by
> >omission or otherwise) about DT_NEEDED, ever. That way the issue is
> >dealt
> >once where it belongs. If somebody wants to go down the rabbit hole of
> >mixed
> >shared + static linkage, let them dig the hole by themselves :)
> >
> This is a fair point.  Can DT_NEEDED sections be stripped via tools like
> objcopy
> after the build is complete?  If so, end users can hack this corner case
> to work
> as needed.
> >>>Patchelf (http://nixos.org/patchelf.html) appears to support that, but
> >>>given that source is available it'd be

[dpdk-dev] Appropriate DPDK data structures for TCP sockets

[Stephen Hemminger]

On Sat, 21 Feb 2015 16:38:45 -0800
Matthew Hall  wrote:

> So far I was using rte_hash, but it's single writer multi reader, which is 
> eventually going to need some more complicated locking and probably run kind 
> of slow. Also, I need some timer functions to delete dead sockets and so 
> forth, and rte_hash doesn't have any iteration API.

Use userspace RCU? or BSD RB_TREE

The existing rte_hash is too limited for many use cases.

[dpdk-dev] Appropriate DPDK data structures for TCP sockets

[Matthew Hall]

On Feb 22, 2015, at 4:02 PM, Stephen Hemminger  
wrote:
> Use userspace RCU? or BSD RB_TREE

Thanks Stephen,

I think the RB_TREE stuff is single threaded mostly.

But user-space RCU looks quite good indeed, I didn't know somebody ported it 
out of the kernel. I'll check it out.

Matthew.