[dpdk-dev] [dpdk-announce] release candidate 16.07-rc5
A new DPDK release candidate is ready for testing: http://dpdk.org/browse/dpdk/tag/?id=v16.07-rc5 There are some fixes which require a small new release candidate. We must avoid touching the code from now. Please let's complete the documentation and check that everything is OK before releasing the 16.07 in few days. Thank you
[dpdk-dev] [PATCH v2] doc: add known issue about promiscuous mode for I40e VF
When use i40e linux kernel driver as host driver and DPDK handler the i40e VF, the promiscuous mode doesn't work in i40e VF. It is not supported by DPDK i40e VF driver right now. Signed-off-by: Jeff Guo --- v1->v2: - add singned-off and modify some format doc/guides/rel_notes/known_issues.rst | 22 ++ 1 file changed, 22 insertions(+) diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst index 5ec1987..e907c22 100644 --- a/doc/guides/rel_notes/known_issues.rst +++ b/doc/guides/rel_notes/known_issues.rst @@ -620,3 +620,25 @@ The last EAL argument is replaced by the program name in argv[] **Driver/Module**: Environment Abstraction Layer (EAL). + + +I40e VF can't receive the promiscuous unicast/multicast/broadcast packet. +- + +**Description**: + Use i40e linux kernel driver PF generate VF, and run testpmd, set Promiscuous mode and + All multicast mode to be enabled, then send packet with unknown destination MAC address + to VF, but VF can't receive the packet. + +**Implication**: + So far, the promiscuous mode is not supported by DPDK i40e VF driver if use i40e Linux kernel + driver as host driver. + +**Resolution/Workaround**: + Don't use promiscuous mode in i40e VF if use i40e Linux kernel driver as host driver. + +**Affected Environment/Platform**: + All. + +**Driver/Module**: + Poll Mode Driver (PMD). -- 1.9.3
[dpdk-dev] [PATCH] doc: add a deprecation about the modification of the return type of promiscuous configure ops in i40e eth_dev_ops
Since an issue has broken out the problem that even the i40e linux kernel driver do not support the promiscuous mode in i40e VF when use i40e linux kernel driver as host driver, the testpmd app still show the mode configure status to be enabled. In order to reflect the real status of the i40e linux kernel driver configure result, some i40e eth_dev_ops about enable and disable promiscuous and all multicast mode need to be modified the return type from void to int. --- doc/guides/rel_notes/deprecation.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index f502f86..2f41f67 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -41,3 +41,10 @@ Deprecation Notices * The mempool functions for single/multi producer/consumer are deprecated and will be removed in 16.11. It is replaced by rte_mempool_generic_get/put functions. + +* The i40e eth_dev_ops about enable and disable promiscuous and all multicast + mode are planned to modify the return type from void to int, in order to reflect + the real status of the hardware driver configure result to APIs users. The deprecated ops include, + i40evf_dev_promiscuous_enable, i40evf_dev_promiscuous_disable, i40evf_dev_allmulticast_enable, + i40evf_dev_allmulticast_disable, i40e_dev_promiscuous_enable, i40e_dev_promiscuous_disable, + i40e_dev_allmulticast_enable, i40e_dev_allmulticast_disable. -- 1.9.3
[dpdk-dev] [PATCH v2] mempool: fix unsafe removal from list by callback
> > If a mempool is removed from the list by a callback function > > during rte_mempool_walk(), the TAILQ_FOREACH loop will fail unexpectedly. > > It is fixed by using the safe version of the loop macro. > > > > Reported-by: Sergio Gonzalez Monroy > > Signed-off-by: Thomas Monjalon > > Acked-by: Olivier Matz Applied, thanks
[dpdk-dev] [PATCH v2] mempool: fix unsafe removal from list by callback
Hello Thomas,
On 07/25/2016 09:54 PM, Thomas Monjalon wrote:
> If a mempool is removed from the list by a callback function
> during rte_mempool_walk(), the TAILQ_FOREACH loop will fail unexpectedly.
> It is fixed by using the safe version of the loop macro.
>
> Reported-by: Sergio Gonzalez Monroy
> Signed-off-by: Thomas Monjalon
> ---
> lib/librte_mempool/rte_mempool.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_mempool/rte_mempool.c
> b/lib/librte_mempool/rte_mempool.c
> index 8806633..2e28e2e 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -1283,12 +1283,13 @@ void rte_mempool_walk(void (*func)(struct rte_mempool
> *, void *),
> {
> struct rte_tailq_entry *te = NULL;
> struct rte_mempool_list *mempool_list;
> + void *tmp_te;
>
> mempool_list = RTE_TAILQ_CAST(rte_mempool_tailq.head, rte_mempool_list);
>
> rte_rwlock_read_lock(RTE_EAL_MEMPOOL_RWLOCK);
>
> - TAILQ_FOREACH(te, mempool_list, next) {
> + TAILQ_FOREACH_SAFE(te, mempool_list, next, tmp_te) {
> (*func)((struct rte_mempool *) te->data, arg);
> }
>
>
Acked-by: Olivier Matz
Thanks
[dpdk-dev] [PATCH v2] mempool: fix unsafe removal from list by callback
If a mempool is removed from the list by a callback function
during rte_mempool_walk(), the TAILQ_FOREACH loop will fail unexpectedly.
It is fixed by using the safe version of the loop macro.
Reported-by: Sergio Gonzalez Monroy
Signed-off-by: Thomas Monjalon
---
lib/librte_mempool/rte_mempool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 8806633..2e28e2e 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -1283,12 +1283,13 @@ void rte_mempool_walk(void (*func)(struct rte_mempool
*, void *),
{
struct rte_tailq_entry *te = NULL;
struct rte_mempool_list *mempool_list;
+ void *tmp_te;
mempool_list = RTE_TAILQ_CAST(rte_mempool_tailq.head, rte_mempool_list);
rte_rwlock_read_lock(RTE_EAL_MEMPOOL_RWLOCK);
- TAILQ_FOREACH(te, mempool_list, next) {
+ TAILQ_FOREACH_SAFE(te, mempool_list, next, tmp_te) {
(*func)((struct rte_mempool *) te->data, arg);
}
--
2.7.0
[dpdk-dev] [RFC] mk: add config items to disable tools and tests
It is not possible to prevent compiling some tests and tools. These enabled when a library or specific exec env enabled. This compilation can be overkill for someone who is compiling DPDK just as library. Adding two new config options, to completely enable/disable tools and test. Both enable default, compatible with existing behavior. This commit also shows app folder is used both for unit tests, test tools and other tools for DPDK, it is possible to discuss separating tests into a test folder. Signed-off-by: Ferruh Yigit --- Targeted for DPDK16.11 --- app/Makefile | 5 + config/common_base | 10 ++ 2 files changed, 15 insertions(+) diff --git a/app/Makefile b/app/Makefile index 30ec292..76b1c2e 100644 --- a/app/Makefile +++ b/app/Makefile @@ -31,12 +31,17 @@ include $(RTE_SDK)/mk/rte.vars.mk +ifeq ($(CONFIG_RTE_ENABLE_TESTS),y) DIRS-$(CONFIG_RTE_APP_TEST) += test DIRS-$(CONFIG_RTE_LIBRTE_ACL) += test-acl DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += test-pipeline DIRS-$(CONFIG_RTE_TEST_PMD) += test-pmd DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_test +endif + +ifeq ($(CONFIG_RTE_ENABLE_TOOLS),y) DIRS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += proc_info DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += pdump +endif include $(RTE_SDK)/mk/rte.subdir.mk diff --git a/config/common_base b/config/common_base index 7830535..50fdf98 100644 --- a/config/common_base +++ b/config/common_base @@ -573,6 +573,11 @@ CONFIG_RTE_LIBRTE_XEN_DOM0=n CONFIG_RTE_INSECURE_FUNCTION_WARNING=n # +# Enable/Disable all test applications +# +CONFIG_RTE_ENABLE_TESTS=y + +# # Compile the test application # CONFIG_RTE_APP_TEST=y @@ -583,4 +588,9 @@ CONFIG_RTE_APP_TEST_RESOURCE_TAR=n # CONFIG_RTE_TEST_PMD=y CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n + +# +# Enable/Disable all test applications +# +CONFIG_RTE_ENABLE_TOOLS=y CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n -- 2.7.4
[dpdk-dev] [PATCH 2/2] mempool: fix unsafe tailq element removal
Hi Sergio,
On 07/22/2016 06:01 PM, Sergio Gonzalez Monroy wrote:
> Potentially user provided function could remove/free tailq elements.
> Doing so within a TAILQ_FOREACH loop is not safe.
>
> Use _SAFE versions of _FOREACH macros.
>
> Signed-off-by: Sergio Gonzalez Monroy
> ---
> lib/librte_mempool/rte_mempool.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/lib/librte_mempool/rte_mempool.c
> b/lib/librte_mempool/rte_mempool.c
> index 8806633..394154a 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -157,10 +157,10 @@ rte_mempool_obj_iter(struct rte_mempool *mp,
> rte_mempool_obj_cb_t *obj_cb, void *obj_cb_arg)
> {
> struct rte_mempool_objhdr *hdr;
> - void *obj;
> + void *obj, *temp;
> unsigned n = 0;
>
> - STAILQ_FOREACH(hdr, >elt_list, next) {
> + STAILQ_FOREACH_SAFE(hdr, >elt_list, next, temp) {
> obj = (char *)hdr + sizeof(*hdr);
> obj_cb(mp, obj_cb_arg, obj, n);
> n++;
> @@ -176,8 +176,9 @@ rte_mempool_mem_iter(struct rte_mempool *mp,
> {
> struct rte_mempool_memhdr *hdr;
> unsigned n = 0;
> + void *temp;
>
> - STAILQ_FOREACH(hdr, >mem_list, next) {
> + STAILQ_FOREACH_SAFE(hdr, >mem_list, next, temp) {
> mem_cb(mp, mem_cb_arg, hdr, n);
> n++;
> }
Not sure it is required to use the _SAFE() variant here.
The object or mem_chunk should be considered as const, because these
objects are not allocated/freed by the user but by the mempool functions.
> @@ -1283,12 +1284,13 @@ void rte_mempool_walk(void (*func)(struct rte_mempool
> *, void *),
> {
> struct rte_tailq_entry *te = NULL;
> struct rte_mempool_list *mempool_list;
> + void *temp;
>
> mempool_list = RTE_TAILQ_CAST(rte_mempool_tailq.head, rte_mempool_list);
>
> rte_rwlock_read_lock(RTE_EAL_MEMPOOL_RWLOCK);
>
> - TAILQ_FOREACH(te, mempool_list, next) {
> + TAILQ_FOREACH_SAFE(te, mempool_list, next, temp) {
> (*func)((struct rte_mempool *) te->data, arg);
> }
>
>
I think this one is legitimate and we should have it for 16.07.
So only this hunk would be required, and the patch 1/2 may be dropped if
we remove the first 2 chunks.
Regards,
Olivier
[dpdk-dev] [PATCH] maintainers: add an entry for the stable branches
2016-07-25 23:05, Yuanhan Liu: > On Mon, Jul 25, 2016 at 04:38:03PM +0200, Thomas Monjalon wrote: > > This git tree will be used to backport some fixes from the > > master branch to maintain some "stable releases". > > The minor version number z will be incremented for these releases: > > YY.MM.z > > > > Signed-off-by: Thomas Monjalon > > Acked-by: Yuanhan Liu Applied
[dpdk-dev] [PATCH] mk: fix link with glibc < 2.17
2016-07-25 12:57, Thomas Monjalon:
> There is a dependency on librt with old glibc.
> The -lrt option was added everywhere it is needed but was also
> added in some applications makefiles as the first link option.
> The problem is this option is really useful only if added after
> the objects or libraries using it (except if using --whole-archive).
> And the -lrt options put after were removed to avoid duplicates.
>
> It was resulting in errors linking test application:
> eal_timer.c:(.text+0x128): undefined reference to `clock_gettime'
> eal_timer.c:(.text+0x166): undefined reference to `clock_gettime'
> eal_alarm.c:(.text+0xda): undefined reference to `clock_gettime'
> eal_alarm.c:(.text+0x211): undefined reference to `clock_gettime'
>
> It is fixed by removing superflous -lrt in app makefiles.
>
> Fixes: 281948b4753e ("mk: fix missing librt dependencies")
> Fixes: 2f6414f4baf1 ("mk: fix static link with glibc < 2.17")
>
> Signed-off-by: Thomas Monjalon
Reported-by: Piotr Azarewicz
Applied, thanks
[dpdk-dev] [PATCH] timer: fix break list when timer_cb reset running timer
> >When timer_cb resets another running timer on the same lcore, > >the list of expired timers is chained to the pending-list. > >This commit prevents a running timer from being reset > >by not its own timer_cb. > > > >Signed-off-by: Hiroyuki Mikita > > Acked-by: Robert Sanford > > I tested the three timer patches with app/test timer_autotest and > timer_racecond_autotest, and additional private tests. Applied, thanks
[dpdk-dev] [PATCH] timer: remove unnecessary timer add call
2016-07-26 00:15, Hiroyuki Mikita:
> Fixes: a4b7a5a45cf5 ("timer: fix race condition")
> >
> >>When timer_set_running_state() fails in rte_timer_manage(),
> >>the failed timer is put back on pending-list.
> >>In this case, another core tries to reset or stop the timer.
> >>It does not need to be on pending-list
> >>
> >>Signed-off-by: Hiroyuki Mikita
> >
> > Acked-by: Robert Sanford
Applied, thanks
[dpdk-dev] [PATCH] timer: fix incorrect pending-list manipulation
2016-07-26 00:16, Hiroyuki Mikita:
> Fixes: 9b15ba895b9f ("timer: use a skip list")
>
> >>This commit fixes incorrect pending-list manipulation
> >>when getting list of expired timers in rte_timer_manage().
> >>
> >>When timer_get_prev_entries() sets pending_head on prev,
> >>the pending-list is broken.
> >>The next of pending_head always becomes NULL.
> >>In this depth level, it is not need to manipulate the list.
> >>
> >>Signed-off-by: Hiroyuki Mikita
> >
> > Acked-by: Robert Sanford
Applied, thanks
[dpdk-dev] [PATCH 1/2] mk: get correct clang version
2016-07-25 16:21, Bruce Richardson:
> On Mon, Jul 25, 2016 at 01:55:48PM +0100, Ferruh Yigit wrote:
> > -dumpversion is for gcc compatibility and doesn't return actual clang
> > version. -dumpversion only returns 4.2.1 for a long time.
> >
> > Fixes: 2ef6eea891e5 ("mk: add clang toolchain")
> >
> > Signed-off-by: Ferruh Yigit
>
> Confirm this set fixes the issues with shared lib compile on FreeBSD.
>
> Tested-by: Bruce Richardson
Applied, thanks
[dpdk-dev] [PATCH] vhost: fix off-by-one error on nr_desc check
2016-07-25 23:24, Yuanhan Liu:
> On Mon, Jul 25, 2016 at 04:09:58PM +0200, Maxime Coquelin wrote:
> > nr_desc is not an index but the number of descriptors,
> > so can be equal to the virtqueue size.
> >
> > Fixes: a436f53ebfeb ("vhost: avoid dead loop chain")
> >
> > Cc: Yuanhan Liu
> > Signed-off-by: Maxime Coquelin
>
> Thanks for catching it!
>
> > ---
> > Hi Yuanhan,
> >
> > I faced the bug while testing my indirect descriptor patch, it happens
> > as soon as the number of chained descritors is above 2.
> >
> > But the bug may in theory also be faced with normal descriptors,
>
> In theory, yes, and only in one case, that there is a Tx has 256
> descriptors chained. If that happens, I doubt things work well.
> So I would say it just happens __in theory__.
>
> > so it might
> > be good to have it 16.07?
>
> Even though, it apparently fixes a bug, so I think we could have it
> for 16.07.
>
> Acked-by: Yuanhan Liu
Applied, thanks
[dpdk-dev] [PATCH] vhost: fix off-by-one error on nr_desc check
On 07/25/2016 05:24 PM, Yuanhan Liu wrote:
> On Mon, Jul 25, 2016 at 04:09:58PM +0200, Maxime Coquelin wrote:
>> nr_desc is not an index but the number of descriptors,
>> so can be equal to the virtqueue size.
>>
>> Fixes: a436f53ebfeb ("vhost: avoid dead loop chain")
>>
>> Cc: Yuanhan Liu
>> Signed-off-by: Maxime Coquelin
>
> Thanks for catching it!
>
>> ---
>> Hi Yuanhan,
>>
>> I faced the bug while testing my indirect descriptor patch, it happens
>> as soon as the number of chained descritors is above 2.
>>
>> But the bug may in theory also be faced with normal descriptors,
>
> In theory, yes, and only in one case, that there is a Tx has 256
> descriptors chained. If that happens, I doubt things work well.
> So I would say it just happens __in theory__.
Right.
>
>> so it might
>> be good to have it 16.07?
>
> Even though, it apparently fixes a bug, so I think we could have it
> for 16.07.
Good, but don't delay 16.07 for that! :)
>
> Acked-by: Yuanhan Liu
>
> --yliu
>
Thanks,
Maxime
[dpdk-dev] [PATCH] maintainers: add staging tree for network drivers
2016-07-25 16:19, Bruce Richardson: > +Staging Trees > +- > + > +Networking Drivers > +T: git://dpdk.org/dpdk-next-net > +M: Bruce Richardson I thought we could write the next- tree information below the existing title: Networking Drivers --
[dpdk-dev] [PATCH] timer: fix break list when timer_cb reset running timer
2016-07-26 00:14, Hiroyuki Mikita:
> Fixes: a4b7a5a45cf5 ("timer: fix race condition")
>
> 2016-07-25 23:43 GMT+09:00 Thomas Monjalon :
> > Hiroyuki, Robert,
> > I would like to apply these patches quickly.
> > Please could you provide some "Fixes:" line to know the origin
> > of the bugs?
> > Thanks
Thanks a lot, Hiroyuki
[dpdk-dev] [PATCH] maintainers: add staging tree for network drivers
On Mon, Jul 25, 2016 at 05:28:40PM +0200, Thomas Monjalon wrote: > 2016-07-25 16:19, Bruce Richardson: > > +Staging Trees > > +- > > + > > +Networking Drivers > > +T: git://dpdk.org/dpdk-next-net > > +M: Bruce Richardson > > I thought we could write the next- tree information below the > existing title: > > Networking Drivers > -- > Maybe, but I think it would work better to have all the staging trees listed together at the top of the file. Makes it easier to see on opening the file that they exist. /Bruce
[dpdk-dev] [PATCH v2] net/i40e: fix vsi removing from tailq when release
> > VSI structure need to be removed from TAILQ list when releasing.
> > But for the child VSI it will be removed again after the structure is
> > freed. It will
> > cause core dump when the DPDK i40e using as PF host driver.
> >
> > This patch fixes it to only remove child VSI from TAILQ before send adminq
> > command to remove it from hardware.
> >
> > Fixes: 4861cde46116 ("i40e: new poll mode driver")
> > Fixes: 440499cf5376 ("net/i40e: support floating VEB")
> > Signed-off-by: Jingjing Wu
> Acked-by: Helin Zhang
Applied, thanks
[dpdk-dev] [PATCH] timer: fix break list when timer_cb reset running timer
Hiroyuki, Robert, I would like to apply these patches quickly. Please could you provide some "Fixes:" line to know the origin of the bugs? Thanks
[dpdk-dev] [PATCH] maintainers: add an entry for the stable branches
This git tree will be used to backport some fixes from the master branch to maintain some "stable releases". The minor version number z will be incremented for these releases: YY.MM.z Signed-off-by: Thomas Monjalon --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 92ea5d7..d099131 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -30,6 +30,9 @@ F: scripts/checkpatches.sh F: scripts/load-devel-config.sh F: scripts/test-build.sh +Stable Branches +--- +T: git://dpdk.org/dpdk-stable Security Issues --- -- 2.7.0
[dpdk-dev] [PATCH 1/2] mk: get correct clang version
On Mon, Jul 25, 2016 at 01:55:48PM +0100, Ferruh Yigit wrote:
> -dumpversion is for gcc compatibility and doesn't return actual clang
> version. -dumpversion only returns 4.2.1 for a long time.
>
> Fixes: 2ef6eea891e5 ("mk: add clang toolchain")
>
> Signed-off-by: Ferruh Yigit
Confirm this set fixes the issues with shared lib compile on FreeBSD.
Tested-by: Bruce Richardson
[dpdk-dev] [PATCH] maintainers: add staging tree for network drivers
Signed-off-by: Bruce Richardson --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d099131..844227b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -34,6 +34,13 @@ Stable Branches --- T: git://dpdk.org/dpdk-stable +Staging Trees +- + +Networking Drivers +T: git://dpdk.org/dpdk-next-net +M: Bruce Richardson + Security Issues --- M: maintainers at dpdk.org -- 2.7.4
[dpdk-dev] [PATCH] vhost: fix off-by-one error on nr_desc check
nr_desc is not an index but the number of descriptors,
so can be equal to the virtqueue size.
Fixes: a436f53ebfeb ("vhost: avoid dead loop chain")
Cc: Yuanhan Liu
Signed-off-by: Maxime Coquelin
---
Hi Yuanhan,
I faced the bug while testing my indirect descriptor patch, it happens
as soon as the number of chained descritors is above 2.
But the bug may in theory also be faced with normal descriptors, so it might
be good to have it 16.07?
Regards,
Maxime
---
lib/librte_vhost/vhost_rxtx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index bc00518..08a73fd 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -748,7 +748,7 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct
vhost_virtqueue *vq,
break;
if (unlikely(desc->next >= vq->size ||
-++nr_desc >= vq->size))
+++nr_desc > vq->size))
return -1;
desc = >desc[desc->next];
--
2.7.4
[dpdk-dev] net/pcap: set rte_errno on TX error
2016-07-25 14:33, Ferruh Yigit: > On 7/25/2016 2:10 PM, Zoltan Kiss wrote: > > This returns the error code provided by pcap_sendpacket() > > Although this is good idea, this adds undocumented side effect to > rte_eth_tx_burst(). > > I am not able to find any information in rte_eth_tx_burst() that it can > alter rte_errno. > > Since rte_errno is shared resource, it shouldn't be updated without > documented. That's something I was looking into. Maybe we should generalize the use of rte_errno in 16.11?
[dpdk-dev] [PATCH] maintainers: add an entry for the stable branches
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Monday, July 25, 2016 3:38 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] maintainers: add an entry for the stable > branches > > This git tree will be used to backport some fixes from the master branch > to maintain some "stable releases". > The minor version number z will be incremented for these releases: > YY.MM.z > > Signed-off-by: Thomas Monjalon Acked-by: John McNamara
[dpdk-dev] [PATCH] mk: fix static link with glibc < 2.17
2016-07-25 11:13, Azarewicz, PiotrX T:
> > The problem is that -lrt appears before -lrte_eal.
> > The question is: where does it come from?
> > It is even before _LDLIBS-y += -L$(RTE_SDK_BIN)/lib... mystery
>
> root cause:
> commitc7cda4d8b4ea9cb0f209dda36882d225354b1db9
The error is seen after this commit, yes.
But I would not say it is the root cause.
The root cause is adding -lrt before other libs:
281948b4753e ("mk: fix missing librt dependencies")
> and my workaround is:
> /app/test/Makefile
>
> ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y)
> -LDLIBS += -lrt
> SRCS-y += test_red.c
> SRCS-y += test_sched.c
> endif
Yes it is what I've done in this patch:
http://dpdk.org/patch/15008
[dpdk-dev] net/pcap: set rte_errno on TX error
On 7/25/2016 2:10 PM, Zoltan Kiss wrote:
> This returns the error code provided by pcap_sendpacket()
Although this is good idea, this adds undocumented side effect to
rte_eth_tx_burst().
I am not able to find any information in rte_eth_tx_burst() that it can
alter rte_errno.
Since rte_errno is shared resource, it shouldn't be updated without
documented.
>
> Signed-off-by: Zoltan Kiss
>
> diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
> index 7e213eb..0899bac 100644
> --- a/drivers/net/pcap/rte_eth_pcap.c
> +++ b/drivers/net/pcap/rte_eth_pcap.c
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -360,8 +361,10 @@ eth_pcap_tx(void *queue,
> }
> }
>
> - if (unlikely(ret != 0))
> + if (unlikely(ret != 0)) {
> + rte_errno = ret;
> break;
> + }
> num_tx++;
> tx_bytes += mbuf->pkt_len;
> rte_pktmbuf_free(mbuf);
>
[dpdk-dev] net/pcap: set rte_errno on TX error
This returns the error code provided by pcap_sendpacket()
Signed-off-by: Zoltan Kiss
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 7e213eb..0899bac 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
@@ -360,8 +361,10 @@ eth_pcap_tx(void *queue,
}
}
- if (unlikely(ret != 0))
+ if (unlikely(ret != 0)) {
+ rte_errno = ret;
break;
+ }
num_tx++;
tx_bytes += mbuf->pkt_len;
rte_pktmbuf_free(mbuf);
[dpdk-dev] [PATCH 2/2] mk: fix FreeBSD clang compile error
clang version < 3.5 doesn't support -z linker option,
and some FreeBSD box still has clang versions < 3.5 as default version.
compile error:
clang: error: unknown argument: '-z'
Fixes: fd591c4c4e35 ("mk: check shared library dependencies")
Signed-off-by: Ferruh Yigit
---
mk/rte.lib.mk | 6 +-
mk/toolchain/clang/rte.toolchain-compat.mk | 4
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 0187ae8..830f81a 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -93,8 +93,12 @@ O_TO_A_DO = @set -e; \
$(O_TO_A) && \
echo $(O_TO_A_CMD) > $(call exe2cmd,$(@))
+ifneq ($(CC_SUPPORTS_Z),false)
+NO_UNDEFINED := -z defs
+endif
+
O_TO_S = $(LD) -L$(RTE_SDK_BIN)/lib $(_CPU_LDFLAGS) $(EXTRA_LDFLAGS) \
- -shared $(OBJS-y) -z defs $(LDLIBS) -Wl,-soname,$(LIB) -o $(LIB)
+ -shared $(OBJS-y) $(NO_UNDEFINED) $(LDLIBS) -Wl,-soname,$(LIB) -o
$(LIB)
O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)"," LD $(@)")
O_TO_S_DO = @set -e; \
diff --git a/mk/toolchain/clang/rte.toolchain-compat.mk
b/mk/toolchain/clang/rte.toolchain-compat.mk
index 03e5a97..b734413 100644
--- a/mk/toolchain/clang/rte.toolchain-compat.mk
+++ b/mk/toolchain/clang/rte.toolchain-compat.mk
@@ -43,3 +43,7 @@ CLANG_VERSION := $(shell $(CC) -v 2>&1 | grep version | sed
"s/.*version \([0-9]
CLANG_MAJOR_VERSION := $(shell echo $(CLANG_VERSION) | cut -f1 -d.)
CLANG_MINOR_VERSION := $(shell echo $(CLANG_VERSION) | cut -f2 -d.)
+
+ifeq ($(shell test $(CLANG_MAJOR_VERSION)$(CLANG_MINOR_VERSION) -lt 35 && echo
1), 1)
+ CC_SUPPORTS_Z := false
+endif
--
2.7.4
[dpdk-dev] [PATCH 1/2] mk: get correct clang version
-dumpversion is for gcc compatibility and doesn't return actual clang
version. -dumpversion only returns 4.2.1 for a long time.
Fixes: 2ef6eea891e5 ("mk: add clang toolchain")
Signed-off-by: Ferruh Yigit
---
mk/toolchain/clang/rte.toolchain-compat.mk | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mk/toolchain/clang/rte.toolchain-compat.mk
b/mk/toolchain/clang/rte.toolchain-compat.mk
index f995b0b..03e5a97 100644
--- a/mk/toolchain/clang/rte.toolchain-compat.mk
+++ b/mk/toolchain/clang/rte.toolchain-compat.mk
@@ -38,6 +38,8 @@
# find out CLANG version
-CLANG_MAJOR_VERSION = $(shell $(CC) -dumpversion | cut -f1 -d.)
+CLANG_VERSION := $(shell $(CC) -v 2>&1 | grep version | sed "s/.*version
\([0-9]*\.[0-9]*\).*/\1/")
-CLANG_MINOR_VERSION = $(shell $(CC) -dumpversion | cut -f2 -d.)
+CLANG_MAJOR_VERSION := $(shell echo $(CLANG_VERSION) | cut -f1 -d.)
+
+CLANG_MINOR_VERSION := $(shell echo $(CLANG_VERSION) | cut -f2 -d.)
--
2.7.4
[dpdk-dev] [PATCH v2] net/i40e: fix vsi removing from tailq when release
VSI structure need to be removed from TAILQ list when releasing.
But for the child VSI it will be removed again after the structure
is freed. It will cause core dump when the DPDK i40e using as PF
host driver.
This patch fixes it to only remove child VSI from TAILQ before
send adminq command to remove it from hardware.
Fixes: 4861cde46116 ("i40e: new poll mode driver")
Fixes: 440499cf5376 ("net/i40e: support floating VEB")
Signed-off-by: Jingjing Wu
---
v2 change:
- add fix for floating veb case
drivers/net/i40e/i40e_ethdev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 11a5804..d0aeb70 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -4110,7 +4110,6 @@ i40e_vsi_release(struct i40e_vsi *vsi)
TAILQ_FOREACH_SAFE(vsi_list, >veb->head, list, temp) {
if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
return -1;
- TAILQ_REMOVE(>veb->head, vsi_list, list);
}
i40e_veb_release(vsi->veb);
}
@@ -4119,7 +4118,6 @@ i40e_vsi_release(struct i40e_vsi *vsi)
TAILQ_FOREACH_SAFE(vsi_list, >floating_veb->head, list,
temp) {
if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
return -1;
- TAILQ_REMOVE(>floating_veb->head, vsi_list, list);
}
}
--
2.4.0
[dpdk-dev] [PATCH] mk: fix link with glibc < 2.17
There is a dependency on librt with old glibc.
The -lrt option was added everywhere it is needed but was also
added in some applications makefiles as the first link option.
The problem is this option is really useful only if added after
the objects or libraries using it (except if using --whole-archive).
And the -lrt options put after were removed to avoid duplicates.
It was resulting in errors linking test application:
eal_timer.c:(.text+0x128): undefined reference to `clock_gettime'
eal_timer.c:(.text+0x166): undefined reference to `clock_gettime'
eal_alarm.c:(.text+0xda): undefined reference to `clock_gettime'
eal_alarm.c:(.text+0x211): undefined reference to `clock_gettime'
It is fixed by removing superflous -lrt in app makefiles.
Fixes: 281948b4753e ("mk: fix missing librt dependencies")
Fixes: 2f6414f4baf1 ("mk: fix static link with glibc < 2.17")
Signed-off-by: Thomas Monjalon
---
app/test/Makefile | 1 -
examples/ptpclient/Makefile | 1 -
2 files changed, 2 deletions(-)
diff --git a/app/test/Makefile b/app/test/Makefile
index 6015b19..49ea195 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -158,7 +158,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_string.c
SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_lib.c
ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y)
-LDLIBS += -lrt
SRCS-y += test_red.c
SRCS-y += test_sched.c
endif
diff --git a/examples/ptpclient/Makefile b/examples/ptpclient/Makefile
index d241730..b77cf71 100644
--- a/examples/ptpclient/Makefile
+++ b/examples/ptpclient/Makefile
@@ -46,7 +46,6 @@ SRCS-y := ptpclient.c
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
-LDLIBS += -lrt
# workaround for a gcc bug with noreturn attribute
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
--
2.7.0
[dpdk-dev] [PATCH v2] net/i40e: fix vsi removing from tailq when release
> -Original Message-
> From: Wu, Jingjing
> Sent: Monday, July 25, 2016 1:36 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org; Wu, Jingjing ; Xing, Beilei
> ; Peng, Yuan
> Subject: [PATCH v2] net/i40e: fix vsi removing from tailq when release
>
> VSI structure need to be removed from TAILQ list when releasing.
> But for the child VSI it will be removed again after the structure is freed.
> It will
> cause core dump when the DPDK i40e using as PF host driver.
>
> This patch fixes it to only remove child VSI from TAILQ before send adminq
> command to remove it from hardware.
>
> Fixes: 4861cde46116 ("i40e: new poll mode driver")
> Fixes: 440499cf5376 ("net/i40e: support floating VEB")
> Signed-off-by: Jingjing Wu
Acked-by: Helin Zhang
[dpdk-dev] [PATCH] timer: fix break list when timer_cb reset running timer
On 7/23/16 4:49 AM, "Thomas Monjalon" wrote: >2016-07-23 0:14 GMT+02:00 Sanford, Robert : >> Acked-by: Robert Sanford >> >> I tested the three timer patches with app/test timer_autotest and >> timer_racecond_autotest, and additional private tests. > >Thanks Robert. >Are you confident enough to integrate them in the last days of 16.07? >How critical are they? >Should we make a RC5 for them? Yes, I'm confident that the patches are safe and correct. However, I'm not sure that we should make a RC just for them. Patch 1 fixes a problem where we incorrectly lower the depth of the skip list, resulting in performance that does not live up to O(log n) that we expect. Summary: performance degradation with large number of timers. Patch 2 fixes a minor inefficiency when timer_manage() races with timer_stop() or timer_reset(). Patch 3 fixes the most serious problem: We may corrupt timer list links if multiple timers expire at roughly the same time, and one of those timers' callback tries to stop/reset other(s) that are scheduled to run in the same call to timer_manage(). Question for Hiroyuki: How did you discover timer linked-list corruption? By code inspection, or do you have a real application that needs that functionality (timers stop/reset each other at roughly the same time)? Regards, Robert
[dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs for some RX mbuf sizes
Hi Beilei, On Mon, Jul 25, 2016 at 5:24 AM, Xing, Beilei wrote: > Hi, > >> -Original Message- >> From: Take Ceara [mailto:dumitru.ceara at gmail.com] >> Sent: Friday, July 22, 2016 8:32 PM >> To: Xing, Beilei >> Cc: Zhang, Helin ; Wu, Jingjing > intel.com>; >> dev at dpdk.org >> Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs >> for some RX mbuf sizes >> >> I was using the test-pmd "txonly" implementation which sends fixed UDP >> packets from 192.168.0.1:1024 -> 192.168.0.2:1024. >> >> I changed the test-pmd tx_only code so that it sends traffic with incremental >> destination IP: 192.168.0.1:1024 -> [192.168.0.2, >> 192.168.0.12]:1024 >> I also dumped the source and destination IPs in the "rxonly" >> pkt_burst_receive function. >> Then I see that packets are indeed sent to different queues but the >> mbuf->hash.rss value is still 0. >> >> ./testpmd -c 1 -n 4 -w :01:00.3 -w :81:00.3 -- -i >> --coremask=0x0 --rxq=16 --txq=16 --mbuf-size 1152 --txpkts 1024 >> --enable-rx-cksum --rss-udp >> >> [...] >> >> - Receive queue=0xf >> PKT_RX_RSS_HASH >> src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 - >> length=1024 - nb_segs=1 - RSS queue=0xa - (outer) L2 type: ETHER - >> (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80006 - (outer) >> L4 type: UDP - Tunnel type: Unknown - RSS hash=0x0 - Inner L2 type: >> Unknown - RSS queue=0xf - RSS queue=0x7 - (outer) L2 type: ETHER - >> (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80007 - (outer) >> L4 type: UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner >> L3 type: Unknown - Inner L4 type: Unknown >> - Receive queue=0x7 >> PKT_RX_RSS_HASH >> src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - (outer) L2 type: >> ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80009 - >> type=0x0800 - length=1024 - nb_segs=1 - Inner L3 type: Unknown - Inner >> L4 type: Unknown - RSS hash=0x0 - (outer) L4 type: UDP - Tunnel type: >> Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - RSS >> queue=0x7 - Inner L4 type: Unknown >> >> [...] >> >> testpmd> stop >> --- Forward Stats for RX Port= 0/Queue= 0 -> TX Port= 1/Queue= 0 >> --- >> RX-packets: 0 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue= 1 -> TX Port= 1/Queue= 1 >> --- >> RX-packets: 59 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue= 2 -> TX Port= 1/Queue= 2 >> --- >> RX-packets: 48 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue= 3 -> TX Port= 1/Queue= 3 >> --- >> RX-packets: 0 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue= 4 -> TX Port= 1/Queue= 4 >> --- >> RX-packets: 59 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue= 5 -> TX Port= 1/Queue= 5 >> --- >> RX-packets: 0 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue= 6 -> TX Port= 1/Queue= 6 >> --- >> RX-packets: 0 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue= 7 -> TX Port= 1/Queue= 7 >> --- >> RX-packets: 48 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue= 8 -> TX Port= 1/Queue= 8 >> --- >> RX-packets: 0 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue= 9 -> TX Port= 1/Queue= 9 >> --- >> RX-packets: 59 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue=10 -> TX Port= 1/Queue=10 >> --- >> RX-packets: 48 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue=11 -> TX Port= 1/Queue=11 >> --- >> RX-packets: 0 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue=12 -> TX Port= 1/Queue=12 >> --- >> RX-packets: 59 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue=13 -> TX Port= 1/Queue=13 >> --- >> RX-packets: 0 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue=14 -> TX Port= 1/Queue=14 >> --- >> RX-packets: 0 TX-packets: 32 TX-dropped: 0 >> --- Forward Stats for RX Port= 0/Queue=15 -> TX Port= 1/Queue=15 >> --- >> RX-packets: 48 TX-packets: 32 TX-dropped: 0 >> -- Forward statistics for port 0 >> -- >> RX-packets: 428RX-dropped: 84RX-total: 512 >> TX-packets: 0 TX-dropped: 0 TX-total: 0 >> >> >> >>
[dpdk-dev] [PATCH] net/i40e: fix vsi removing from tailq when release
VSI structure need to be removed from TAILQ list when releasing.
But for the child VSI it will be removed again after the structure
is freed. It will cause core dump when the DPDK i40e using as PF
host driver.
This patch fixes it to only remove child VSI from TAILQ before
send adminq command to remove it from hardware.
Fixes: 4861cde46116 ("i40e: new poll mode driver")
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/i40e_ethdev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 11a5804..97f9d49 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -4110,7 +4110,6 @@ i40e_vsi_release(struct i40e_vsi *vsi)
TAILQ_FOREACH_SAFE(vsi_list, >veb->head, list, temp) {
if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
return -1;
- TAILQ_REMOVE(>veb->head, vsi_list, list);
}
i40e_veb_release(vsi->veb);
}
--
2.4.0
[dpdk-dev] [PATCH] mk: fix static link with glibc < 2.17
> The problem is that -lrt appears before -lrte_eal. > The question is: where does it come from? > It is even before _LDLIBS-y += -L$(RTE_SDK_BIN)/lib... mystery root cause: commit c7cda4d8b4ea9cb0f209dda36882d225354b1db9 and my workaround is: /app/test/Makefile ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y) -LDLIBS += -lrt SRCS-y += test_red.c SRCS-y += test_sched.c endif
[dpdk-dev] Updating http://dpdk.org/doc/nics
2016-07-24 14:29, Ajit Khaparde: > I don't see the Broadcom NICs listed in the list of supported NICs. > Can you add an entry for the Broadcom NICs supported by the bnxt PMD driver? Yes I'm used to update this page before each release. But I may also suggest to send a patch yourself to web at dpdk.org. Check out the git repository of the web pages: http://dpdk.org/browse/tools/dpdk-web/
[dpdk-dev] [RFC] Generic flow director/filtering/classification API
On 16-07-25 04:32 AM, Rahul Lakkireddy wrote: > Hi Adrien, > > On Thursday, July 07/21/16, 2016 at 19:07:38 +0200, Adrien Mazarguil wrote: >> Hi Rahul, >> >> Please see below. >> >> On Thu, Jul 21, 2016 at 01:43:37PM +0530, Rahul Lakkireddy wrote: >>> Hi Adrien, >>> >>> The proposal looks very good. It satisfies most of the features >>> supported by Chelsio NICs. We are looking for suggestions on exposing >>> more additional features supported by Chelsio NICs via this API. >>> >>> Chelsio NICs have two regions in which filters can be placed - >>> Maskfull and Maskless regions. As their names imply, maskfull region >>> can accept masks to match a range of values; whereas, maskless region >>> don't accept any masks and hence perform a more strict exact-matches. >>> Filters without masks can also be placed in maskfull region. By >>> default, maskless region have higher priority over the maskfull region. >>> However, the priority between the two regions is configurable. >> >> I understand this configuration affects the entire device. Just to be clear, >> assuming some filters are already configured, are they affected by a change >> of region priority later? >> > > Both the regions exist at the same time in the device. Each filter can > either belong to maskfull or the maskless region. > > The priority is configured at time of filter creation for every > individual filter and cannot be changed while the filter is still > active. If priority needs to be changed for a particular filter then, > it needs to be deleted first and re-created. Could you model this as two tables and add a table_id to the API? This way user space could populate the table it chooses. We would have to add some capabilities attributes to "learn" if tables support masks or not though. I don't see how the PMD can sort this out in any meaningful way and it has to be exposed to the application that has the intelligence to 'know' priorities between masks and non-masks filters. I'm sure you could come up with something but it would be less than ideal in many cases I would guess and we can't have the driver getting priorities wrong or we may not get the correct behavior. > >>> Please suggest on how we can let the apps configure in which region >>> filters must be placed and set the corresponding priority accordingly >>> via this API. >> >> Okay. Applications, like customers, are always right. >> >> With this in mind, PMDs are not allowed to break existing flow rules, and >> face two options when applications provide a flow specification that would >> break an existing rule: >> >> - Refuse to create it (easiest). >> >> - Find a workaround to apply it anyway (possibly quite complicated). >> >> The reason you have these two regions is performance right? Otherwise I'd >> just say put everything in the maskfull region. >> > > Unfortunately, our maskfull region is extremely small too compared to > maskless region. > To me this means a userspace application would want to pack it carefully to get the full benefit. So you need some mechanism to specify the "region" hence the above table proposal. >> PMDs are allowed to rearrange existing rules or change device parameters as >> long as existing constraints are satisfied. In my opinion it does not matter >> which region has the highest default priority. Applications always want the >> best performance so the first created rule should be in the most appropriate >> region. >> >> If a subsequent rule requires it to be in the other region but the >> application specified the wrong priority for this to work, then the PMD can >> either choose to swap region priorities on the device (assuming it does not >> affect other rules), or destroy and recreate the original rule in a way that >> satisfies all constraints (i.e. moving conflicting rules from the maskless >> region to the maskfull one). >> >> Going further, when subsequent rules get destroyed the PMD should ideally >> move back maskfull rules back into the maskless region for better >> performance. >> >> This is only a suggestion. PMDs have the right to say "no" at some point. >> > > Filter search and deletion are expensive operations and they need to be > atomic in order to not affect existing traffic already hitting the > filters. Also, Chelsio hardware can support upto ~500,000 maskless > region entries. So, the cost of search becomes too high for the PMD > when there are large number of filter entries present. > > In my opinion, rather than PMD deciding on priority by itself, it would > be more simpler if the apps have the flexibility to configure the > priority between the regions by themselves? > Agreed I think this will be a common problem especially as the hardware tables get bigger and support masks where priority becomes important to distinguish between multiple matching rules. +1 for having a priority field. >> More important in my opinion is to make sure applications can create a given >> set of flow rules in any order. If
[dpdk-dev] [PATCH 2/2] doc: improve wording of new features section
On Fri, Jul 22, 2016 at 06:19:11PM +0200, Thomas Monjalon wrote: > 2016-07-22 17:06, Bruce Richardson: > > Improve the wording of some text in the "new features" section of > > the release notes. > > I think these patches conflict with this one: > http://dpdk.org/dev/patchwork/patch/14898/ > Ooops, forgot to check if there was an outstanding patch for the RN doc. I'll review again and submit a new patch if one is needed. /Bruce
[dpdk-dev] [PATCH] ring: fix sc dequeue performance issue
2016-07-24 22:57, Ananyev, Konstantin:
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> > Use of rte_smb_wmb() instead of rte_smb_rmb() in sc dequeue function
> > creates the additional overhead of waiting for all the STOREs to be
> > completed to local buffer from ring buffer memory. The sc dequeue function
> > demands only LOAD-STORE barrier where LOADs from ring
> > buffer memory needs to be completed before tail pointer update. Changing to
> > rte_smb_rmb() to enable the required LOAD-STORE barrier.
> >
> > Fixes: ecc7d10e448e ("ring: guarantee dequeue ordering before tail update")
> >
> > Signed-off-by: Jerin Jacob
>
> Acked-by: Konstantin Ananyev
Applied, thanks for the quick reaction
[dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs for some RX mbuf sizes
Hi, > -Original Message- > From: Take Ceara [mailto:dumitru.ceara at gmail.com] > Sent: Friday, July 22, 2016 8:32 PM > To: Xing, Beilei > Cc: Zhang, Helin ; Wu, Jingjing intel.com>; > dev at dpdk.org > Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs > for some RX mbuf sizes > > I was using the test-pmd "txonly" implementation which sends fixed UDP > packets from 192.168.0.1:1024 -> 192.168.0.2:1024. > > I changed the test-pmd tx_only code so that it sends traffic with incremental > destination IP: 192.168.0.1:1024 -> [192.168.0.2, > 192.168.0.12]:1024 > I also dumped the source and destination IPs in the "rxonly" > pkt_burst_receive function. > Then I see that packets are indeed sent to different queues but the > mbuf->hash.rss value is still 0. > > ./testpmd -c 1 -n 4 -w :01:00.3 -w :81:00.3 -- -i > --coremask=0x0 --rxq=16 --txq=16 --mbuf-size 1152 --txpkts 1024 > --enable-rx-cksum --rss-udp > > [...] > > - Receive queue=0xf > PKT_RX_RSS_HASH > src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 - > length=1024 - nb_segs=1 - RSS queue=0xa - (outer) L2 type: ETHER - > (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80006 - (outer) > L4 type: UDP - Tunnel type: Unknown - RSS hash=0x0 - Inner L2 type: > Unknown - RSS queue=0xf - RSS queue=0x7 - (outer) L2 type: ETHER - > (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80007 - (outer) > L4 type: UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner > L3 type: Unknown - Inner L4 type: Unknown > - Receive queue=0x7 > PKT_RX_RSS_HASH > src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - (outer) L2 type: > ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80009 - > type=0x0800 - length=1024 - nb_segs=1 - Inner L3 type: Unknown - Inner > L4 type: Unknown - RSS hash=0x0 - (outer) L4 type: UDP - Tunnel type: > Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - RSS > queue=0x7 - Inner L4 type: Unknown > > [...] > > testpmd> stop > --- Forward Stats for RX Port= 0/Queue= 0 -> TX Port= 1/Queue= 0 --- > RX-packets: 0 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue= 1 -> TX Port= 1/Queue= 1 --- > RX-packets: 59 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue= 2 -> TX Port= 1/Queue= 2 --- > RX-packets: 48 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue= 3 -> TX Port= 1/Queue= 3 --- > RX-packets: 0 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue= 4 -> TX Port= 1/Queue= 4 --- > RX-packets: 59 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue= 5 -> TX Port= 1/Queue= 5 --- > RX-packets: 0 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue= 6 -> TX Port= 1/Queue= 6 --- > RX-packets: 0 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue= 7 -> TX Port= 1/Queue= 7 --- > RX-packets: 48 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue= 8 -> TX Port= 1/Queue= 8 --- > RX-packets: 0 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue= 9 -> TX Port= 1/Queue= 9 --- > RX-packets: 59 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue=10 -> TX Port= 1/Queue=10 --- > RX-packets: 48 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue=11 -> TX Port= 1/Queue=11 --- > RX-packets: 0 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue=12 -> TX Port= 1/Queue=12 --- > RX-packets: 59 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue=13 -> TX Port= 1/Queue=13 --- > RX-packets: 0 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue=14 -> TX Port= 1/Queue=14 --- > RX-packets: 0 TX-packets: 32 TX-dropped: 0 > --- Forward Stats for RX Port= 0/Queue=15 -> TX Port= 1/Queue=15 --- > RX-packets: 48 TX-packets: 32 TX-dropped: 0 > -- Forward statistics for port 0 -- > RX-packets: 428RX-dropped: 84RX-total: 512 > TX-packets: 0 TX-dropped: 0 TX-total: 0 > > > -- Forward statistics for port 1 -- > RX-packets: 0 RX-dropped: 0 RX-total: 0 > TX-packets: 512TX-dropped: 0 TX-total: 512 >
[dpdk-dev] [PATCH] doc: add known issue about promiscuous mode for I40e VF
When use i40e linux kernel driver as host driver and DPDK handler the i40e VF, the promiscuous mode doesn't work in i40e VF. It is not supported by DPDK i40e VF driver right now. --- doc/guides/rel_notes/known_issues.rst | 22 ++ 1 file changed, 22 insertions(+) diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst index 5ec1987..e907c22 100644 --- a/doc/guides/rel_notes/known_issues.rst +++ b/doc/guides/rel_notes/known_issues.rst @@ -620,3 +620,25 @@ The last EAL argument is replaced by the program name in argv[] **Driver/Module**: Environment Abstraction Layer (EAL). + + +I40e VF can't receive the promiscuous unicast/multicast/broadcast packet. +- + +**Description**: + Use i40e linux kernel driver PF generate VF, and run testpmd, set Promiscuous mode and + All multicast mode to be enabled, then send packet with unknown destination MAC address + to VF, but VF can't receive the packet. + +**Implication**: + So far, the promiscuous mode is not supported by DPDK i40e VF driver if use i40e Linux kernel + driver as host driver. + +**Resolution/Workaround**: + Don't use promiscuous mode in i40e VF if use i40e Linux kernel driver as host driver. + +**Affected Environment/Platform**: + All. + +**Driver/Module**: + Poll Mode Driver (PMD). -- 1.9.3
