[dpdk-dev] packet loss in usvhost dpdk interface
thanks a lot .. great help . On Wed, Apr 8, 2015 at 8:10 PM, Xie, Huawei wrote: > On 4/6/2015 6:42 PM, Srinivasreddy R wrote: > > Hi, > > I have observed packet loss with usvhost dpdk interfaces even at a very > > small rate . > > This is because virtqueue [dev->virtqueue] is found to be full, > > and my application should drop the packets . > Maybe your virtio guest is slow in processing the packets. > Could you refer to the retry mechanism in the vhost example? search > enable_retry in switch_worker in examples/vhost/main.c. > > > > some one pls help me , > > how can I avoid this loss . > > > > > > thanks > > srinivas. > > > > > >
[dpdk-dev] Polling too often at lower packet rates?
Stephen Hemminger wrote: > Your excess polling consumes PCI bandwidth which is a fixed resource. I doubt that this is the problem for three reasons: * The poll rate would regulate itself if the PCIe bus was the bottleneck * This problem only occurs with 82599 chips, not with X540 chips (which are virtually identical except for 10GBase-T vs. fiber) * This effect already appears with relatively low poll rates (batch size 1). The overhead would have to be > 128 bytes per poll to saturate the PCIe bus at this rate. (Even if this was the case, my first point still applies) I unfortunately don't have a test system with a CPU that supports PCIe performance counters with a 82599 card. Otherwise I'd measure this since I think this effect is really interesting (I'm a co-authors of the paper linked above). Paul
[dpdk-dev] Polling too often at lower packet rates?
Paul Emmerich wrote: > Stephen Hemminger wrote: > >> Your excess polling consumes PCI bandwidth which is a fixed resource. > > I doubt that this is the problem for three reasons: > 4th: polling should not cause a PCIe access as all the required information is written to memory by the NIC [1]. I only noticed that after I tried to measure the PCIe bandwidth caused by polling an X540 NIC... the result was 0 MBit/s ;) Paul [1] 82599 and X540 data sheets, Table 1-9
[dpdk-dev] tools brainstorming
On 4/9/15, 7:26 PM, "Neil Horman" wrote: >On Thu, Apr 09, 2015 at 09:10:19PM +, Wiles, Keith wrote: >> >> >> On 4/9/15, 2:38 PM, "Jay Rolette" wrote: >> >> >On Thu, Apr 9, 2015 at 2:16 PM, Neil Horman >>wrote: >> > >> >> On Thu, Apr 09, 2015 at 11:31:39AM -0500, Jay Rolette wrote: >> >> > On Wed, Apr 8, 2015 at 5:38 PM, Stephen Hemminger < >> >> > stephen at networkplumber.org> wrote: >> >> > >> >> > > On Wed, 8 Apr 2015 16:29:54 -0600 >> >> > > Jay Rolette wrote: >> >> > > >> >> > > > "C comments" includes //, right? It's been part of the C >>standard >> >> for a >> >> > > long time now... >> >> > > >> >> > > Yes but. >> >> > > I like to use checkpatch and checkpatch enforces kernel style >>which >> >> does >> >> > > not allow // for >> >> > > comments. >> >> > > >> >> > >> >> > Fork checkpatch and disable that bit? DPDK isn't the kernel, so no >> >> > requirement to follow all of its rules >> >> > >> >> >> >> Doesn't that beg the question, why? I understand the DPDK isn't the >> >> kernel, but >> >> we're not talking about clarity of code, not anything functional to >>that >> >> code. >> >> It seems we would be better served by just taking something that >>works >> >>here >> >> rather than re-inventing the wheel and digging into the minuate of >>what >> >> type of >> >> comments should be allowed (unless there is a compelling reason to >> >>change >> >> it >> >> that supercedes the avilable tools). If not checkpath, then some >>other >> >> tool, >> >> but It seems to me that coding style is one of those things where we >>can >> >> bend to >> >> the tool rather than taking the time to make the tool do exactly >>whats >> >> desired, >> >> at least until someone gets the time to modify it. >> >> >> > >> >Fair question. >> > >> >It depends a bit on how much you want to encourage patch >>contributions. Is >> >it worth adding more pain for folks trying to contribute patches for >> >things >> >like this? >> > >> >Should we force someone to spend time redoing a patch because of which >>way >> >they do their parenthesis? What about number of spaces to indent code? >>// >> >vs /* */ comments? None of these matter functionally and they don't >>affect >> >maintenance generally. >> > >> >If someone is modifying existing code, then yeah, they should follow >>the >> >prevailing style (indention level, brace alignment, etc.) of the file >>they >> >are in. It helps readability, which makes maintenance easier. However, >> >IMO, >> >mixing // and /* */ for comments doesn't affect the readability of the >> >source. >> > >> >I know if I submit a patch and the only feedback is that I should have >> >used >> >/* */ for comments, I'm extremely unlikely spend extra time to resubmit >> >the >> >patch for pedantry. >> >> I looked at checkpatch.pl for few minutes and the code does check for >>C99 >> comments and adding a command line option to allow C99 comments could >> pretty simple. I found the code around line 3048 or search for C99, it >>is >> possible it could accepted back into Linux as long as the default option >> was to not allow C99 comments. >> >> Allowing C99 comments would be nice and the only problem I could see if >> some compiler has a problem with them. I believe all of the compilers we >> support allow C99 comments. >> >> The only other reason to allow them is if we add some open source code >>in >> the future to DPDK which has C99 comments and if would be a pain to have >> to convert that code every time the open source group released a new >> version. It does open that path IMO. >> > >So, this again seems to be bad philosophy in my mind. If we are, to use >your >exmple, accept code into the DPDK in the future with comments that >violate our >selected style, it is then, by definition, in violation of the style >guidelines. Who stated it violated the style guidelines, we do not have a style guideline yet. This why Shiobhan sent out the guidelines in the first place. >If we accept it anyway, or if we allow both styles (by documenting >it/codifying >it a tool to check for/etc) then we dilute the style guide. Maybe in some >cases, such as this, thats ok, but its something to be cogniscent of. >Especially if making the choice to allow both put us in a position of >having to >maintain a tool to do the checking, then I think we need to fall on the >side of >going with what the tool (checkpatch or something else) does, unless we >have a >maintainer stepping up. Sure maintaining a tool for the C99 comment seems pretty easy, if no one want to maintain the tool that is another problem. Whether to support C99 comments is the point not that we have to maintain the tool. At this point checkpatch is a OK tool if you only want Linux kernel coding style and at this point we are not Linux code style. It just so happens the checkpatch provides some checks we seem to agree with. If we really want some type of tool to check every detail of ?our? coding style then we most likely need to stop using checkpatch
[dpdk-dev] Running DPDK Binaries on a different Target
Hi Konstantin, Thanks a lot for looking in to this. In my case, I am using the ACL Pipeline Infra [My application logic is built on the ACL pipeline]. After your mail, I did verify the same with "l3fwd-acl" example, it just worked fine. Seems like, the issue is observed only with the Pipeline implementation. Currently, I am debugging this, will update you once I have more info on this. Any known issues with the Pipeline implementation? Regards Venkat On 9 April 2015 at 17:07, Ananyev, Konstantin wrote: > > Hi Venkat, > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Venkat Thummala > > Sent: Thursday, April 09, 2015 10:07 AM > > To: Neil Horman > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] Running DPDK Binaries on a different Target > > > > I have the following ACL rule configured in the ACL Table. > > > > Priority - 20 > > SIP - 0 > > SIP MASK - 0 > > DIP - 0 > > DIP MASK - 0 > > PROTO - 17 [UDP] > > PROTO MASK - 0xFF > > SPORT - 0 > > SPORT RANGE - 0x > > DPORT - 0 > > DPORT RANGE - 0x > > > > And pumping UDP traffic. > > > > On Machine 1, it always HITS the rule as expected. > > > > But On Machine 2, the same traffic never HITS the rule. > > > > I have tried this with both SCALAR and SSE classification algorithms, but > > the result is same. > > So did I get it right: > You build a binary with RTE_MACHINE="default" on a box with AVX2 support. > Then run that binary on > a) native box (machine with AVX2 support) > b) machine without AVX2 support > > For the same input and same rules, same binary you got different results > for a) and b). > If that is the case, then there is something wrong here, either within our > code or with the compiler you are using. > Could you provide steps to reproduce it? > I did a quick test with l3fwd-acl for that case, 'default' binary that I > built on HSW board, > works as expected on IVB box for me. > > Build box: HSW (E3-1285), gcc 4.8.3 > SUT: IVB 2.80GHz, gcc 4.8.2 > > # cat acl_ipv4.rule1 > R0.0.0.0/0 0.0.0.0/0 0 : 0x 0 : 0x 17/0xff 0 > # cat acl_ipv6.rule1 > R0:0:0:0:0:0:0:0/0 0:0:0:0:0:0:0:0/0 0 : 0x 0 : 0x 17/0xff 0 > > ./dpdk.org-acl/examples/l3fwd-acl/x86_64-default-linuxapp-gcc/l3fwd-acl > --lcores=3 -n 4 --socket-mem=1024,0 -w :04:00.1 -- -p 1 --config "(0, > 0, 3)" --rule_ipv4=./acl_ipv4.rule1 --rule_ipv6=acl_ipv6.rule1 -P > > Forwards UDP packets, drops all others. > > Anything else in your setup, that I am missing here? > > Konstantin > > > > > Could some one, please help me on this? > > > > DPDK Version: > > === > > 2.0 > > > > Machine 1 CPU INFO: > > > > vendor_id: GenuineIntel > > cpu family: 6 > > model: 69 > > model name: Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz > > stepping: 1 > > microcode: 0x16 > > cpu MHz: 759.000 > > cache size: 3072 KB > > physical id: 0 > > siblings: 4 > > core id: 1 > > cpu cores: 2 > > apicid: 3 > > initial apicid: 3 > > fpu: yes > > fpu_exception: yes > > cpuid level: 13 > > wp: yes > > flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl > > xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor > > ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe > popcnt > > tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb > > xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase > > tsc_adjust bmi1 avx2 smep bmi2 erms invpcid > > bogomips: 4589.70 > > clflush size: 64 > > cache_alignment: 64 > > address sizes: 39 bits physical, 48 bits virtual > > power management: > > > > MACHINE 1 OS: > > = > > Linux vthummala-HP-Pavilion-15-Notebook-PC 3.13.0-48-generic #80-Ubuntu > SMP > > Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > > > MACHINE 2 CPU INFO: > > == > > vendor_id: GenuineIntel > > cpu family: 6 > > model: 62 > > model name: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz > > stepping: 4 > > microcode: 0x416 > > cpu MHz: 2599.890 > > cache size: 20480 KB > > physical id: 1 > > siblings: 16 > > core id: 7 > > cpu cores: 8 > > apicid: 47 > > initial apicid: 47 > > fpu: yes > > fpu_exception: yes > > cpuid level: 13 > > wp: yes > > flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl > > xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor > > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic > > popcnt tsc_deadline_timer aes xsave avx f16c rdrand
[dpdk-dev] How to check memory leak with dpdk application
Hi, all I'am trying to use valgrind to check memory leak with my dpdk application but dpdk always failed to mmap hugepages. Without valgrind it works well.How to run dpdk applications with valgrind?Is there any other way to check memory leak with dpdk applications?
[dpdk-dev] [PATCH 1/5] bond: use existing enslaved device queues
On 2015-04-06 19:01, Eric Kinzie wrote:
> If a device to be enslaved already has transmit and/or receive queues
> allocated, use those and then create any additional queues that are
> necessary.
>
> Signed-off-by: Eric Kinzie
> ---
> lib/librte_pmd_bond/rte_eth_bond_pmd.c |8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_pmd_bond/rte_eth_bond_pmd.c
> b/lib/librte_pmd_bond/rte_eth_bond_pmd.c
> index c937e6b..4fd7d97 100644
> --- a/lib/librte_pmd_bond/rte_eth_bond_pmd.c
> +++ b/lib/librte_pmd_bond/rte_eth_bond_pmd.c
> @@ -1318,7 +1318,9 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
> }
>
> /* Setup Rx Queues */
> - for (q_id = 0; q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) {
> + /* Use existing queues, if any */
> + for (q_id = slave_eth_dev->data->nb_rx_queues;
> + q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) {
> bd_rx_q = (struct bond_rx_queue
> *)bonded_eth_dev->data->rx_queues[q_id];
>
> errval = rte_eth_rx_queue_setup(slave_eth_dev->data->port_id,
> q_id,
> @@ -1334,7 +1336,9 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
> }
>
> /* Setup Tx Queues */
> - for (q_id = 0; q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
> + /* Use existing queues, if any */
> + for (q_id = slave_eth_dev->data->nb_tx_queues;
> + q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
> bd_tx_q = (struct bond_tx_queue
> *)bonded_eth_dev->data->tx_queues[q_id];
>
> errval = rte_eth_tx_queue_setup(slave_eth_dev->data->port_id,
> q_id,
>
Why you want to do that?
As far as I am aware (but Declan Doherty should speak here to) purpose
of this part of code is to have configuration of queues in slaves
consistent with bd_rx_q/bd_tx_q. If you skip reconfiguration of queues
that are already configured in port you can have them configured
in different way after enslaving.
So again: what is the purpose of doing so?
--
Pawel
[dpdk-dev] [PATCH 2/5] bond mode 4: copy entire config structure
On 2015-04-06 19:01, Eric Kinzie wrote: >Copy all needed fields from the mode8023ad_private structure in >bond_mode_8023ad_conf_get(). > > Signed-off-by: Eric Kinzie > --- > lib/librte_pmd_bond/rte_eth_bond_8023ad.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/librte_pmd_bond/rte_eth_bond_8023ad.c > b/lib/librte_pmd_bond/rte_eth_bond_8023ad.c > index 97a828e..1009d5b 100644 > --- a/lib/librte_pmd_bond/rte_eth_bond_8023ad.c > +++ b/lib/librte_pmd_bond/rte_eth_bond_8023ad.c > @@ -1013,6 +1013,7 @@ bond_mode_8023ad_conf_get(struct rte_eth_dev *dev, > conf->aggregate_wait_timeout_ms = mode4->aggregate_wait_timeout / > ms_ticks; > conf->tx_period_ms = mode4->tx_period_timeout / ms_ticks; > conf->update_timeout_ms = mode4->update_timeout_us / 1000; > + conf->rx_marker_period_ms = mode4->rx_marker_timeout / ms_ticks; > } > > void > This is bugfix. Acked-by: Pawel Wodkowski -- Pawel
[dpdk-dev] [PATCH] mk: remove uio suffix from virtio pmd
The virtio pmd is not restricted to uio anymore.
Fixes: da978dfdc43b ("virtio: use port IO to get PCI resource")
Signed-off-by: Thomas Monjalon
---
lib/librte_pmd_virtio/Makefile | 2 +-
mk/rte.app.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_pmd_virtio/Makefile b/lib/librte_pmd_virtio/Makefile
index 793067f..21ff7e5 100644
--- a/lib/librte_pmd_virtio/Makefile
+++ b/lib/librte_pmd_virtio/Makefile
@@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
#
# library name
#
-LIB = librte_pmd_virtio_uio.a
+LIB = librte_pmd_virtio.a
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 56886dc..aa8af79 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -212,7 +212,7 @@ LDLIBS += -lrte_pmd_vmxnet3_uio
endif
ifeq ($(CONFIG_RTE_LIBRTE_VIRTIO_PMD),y)
-LDLIBS += -lrte_pmd_virtio_uio
+LDLIBS += -lrte_pmd_virtio
endif
ifeq ($(CONFIG_RTE_LIBRTE_ENIC_PMD),y)
--
2.2.2
[dpdk-dev] [PATCH] mk: fix static linking with null pmd
Null PMD was not found when using a statically linked application:
EAL: no driver found for eth_null1
EAL: failed to initialize eth_null1 device
Fixes: c743e50c475f ("null: new poll mode driver")
Signed-off-by: Thomas Monjalon
---
mk/rte.app.mk | 4
1 file changed, 4 insertions(+)
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index aa8af79..62a76ae 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -251,6 +251,10 @@ ifeq ($(CONFIG_RTE_LIBRTE_PMD_AF_PACKET),y)
LDLIBS += -lrte_pmd_af_packet
endif
+ifeq ($(CONFIG_RTE_LIBRTE_PMD_NULL),y)
+LDLIBS += -lrte_pmd_null
+endif
+
endif # plugins
endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
--
2.2.2
[dpdk-dev] [PATCH] scripts: test null forwarding
This script ease testing of basic initializations and Rx/Tx bursts.
It may help to check obvious regressions.
In order to run it on a standard development machine, it doesn't use
neither hugepages nor real interfaces.
The optional parameters are:
- build directory (default: build)
- coremask (default: 3 i.e. cores 0 and 1)
Signed-off-by: Thomas Monjalon
---
scripts/test-null.sh | 14 ++
1 file changed, 14 insertions(+)
create mode 100755 scripts/test-null.sh
diff --git a/scripts/test-null.sh b/scripts/test-null.sh
new file mode 100755
index 000..6f6918e
--- /dev/null
+++ b/scripts/test-null.sh
@@ -0,0 +1,14 @@
+#! /bin/sh -e
+
+build=${1:-build}
+coremask=${2:-3} # default using cores 0 and 1
+
+if grep -q SHARED_LIB=y $build/.config; then
+ export LD_LIBRARY_PATH=$build/lib:$LD_LIBRARY_PATH
+ pmd='-d librte_pmd_null.so'
+fi
+
+(sleep 1 && echo stop) |
+$build/app/testpmd -c $coremask -n 1 --no-huge \
+ $pmd --vdev eth_null1 --vdev eth_null2 -- \
+ --total-num-mbufs=2048 -ia
--
2.2.2
[dpdk-dev] [PATCH 3/5] bond mode 4: do not ignore multicast
On 2015-04-06 19:01, Eric Kinzie wrote:
> if (unlikely(hdr->ether_type == ether_type_slow_be ||
> !collecting || (!promisc &&
> - !is_same_ether_addr(&bond_mac,
> &hdr->d_addr {
> + (!is_multicast_ether_addr(&hdr->d_addr)
> &&
> + !is_same_ether_addr(&bond_mac,
> &hdr->d_addr) {
>
You can drop extra parenthesis here, but beside that I think it is OK.
Should be marked as bugfix.
Acked-by: Pawel Wodkowski
[dpdk-dev] [PATCH 2/5] bond mode 4: copy entire config structure
2015-04-10 09:47, Pawel Wodkowski: > On 2015-04-06 19:01, Eric Kinzie wrote: > >Copy all needed fields from the mode8023ad_private structure in > >bond_mode_8023ad_conf_get(). > > > > Signed-off-by: Eric Kinzie > > --- > > lib/librte_pmd_bond/rte_eth_bond_8023ad.c |1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/lib/librte_pmd_bond/rte_eth_bond_8023ad.c > > b/lib/librte_pmd_bond/rte_eth_bond_8023ad.c > > index 97a828e..1009d5b 100644 > > --- a/lib/librte_pmd_bond/rte_eth_bond_8023ad.c > > +++ b/lib/librte_pmd_bond/rte_eth_bond_8023ad.c > > @@ -1013,6 +1013,7 @@ bond_mode_8023ad_conf_get(struct rte_eth_dev *dev, > > conf->aggregate_wait_timeout_ms = mode4->aggregate_wait_timeout / > > ms_ticks; > > conf->tx_period_ms = mode4->tx_period_timeout / ms_ticks; > > conf->update_timeout_ms = mode4->update_timeout_us / 1000; > > + conf->rx_marker_period_ms = mode4->rx_marker_timeout / ms_ticks; > > } > > > > void > > > > This is bugfix. When fixing a bug, it's better to explain what was wrong (i.e. behaviour impact) and to add a tag "Fixes: ". Thanks > Acked-by: Pawel Wodkowski
[dpdk-dev] [PATCH 4/5] bond mode 4: allow external state machine
Hi Eric
Please see my comments.
On 2015-04-06 19:01, Eric Kinzie wrote:
>Provide functions to allow an external 802.3ad state machine to transmit
>and recieve LACPDUs and to set the collection/distribution flags on
>slave interfaces.
>
> Signed-off-by: Eric Kinzie
> ---
> lib/librte_pmd_bond/rte_eth_bond_8023ad.c | 175
> +
> lib/librte_pmd_bond/rte_eth_bond_8023ad.h | 44 ++
> lib/librte_pmd_bond/rte_eth_bond_8023ad_private.h |2 +
> 3 files changed, 221 insertions(+)
>
> diff --git a/lib/librte_pmd_bond/rte_eth_bond_8023ad.c
> b/lib/librte_pmd_bond/rte_eth_bond_8023ad.c
> index 1009d5b..29cd962 100644
> --- a/lib/librte_pmd_bond/rte_eth_bond_8023ad.c
> +++ b/lib/librte_pmd_bond/rte_eth_bond_8023ad.c
> @@ -42,6 +42,8 @@
>
> #include "rte_eth_bond_private.h"
>
> +static void bond_mode_8023ad_ext_periodic_cb(void *arg);
> +
> #ifdef RTE_LIBRTE_BOND_DEBUG_8023AD
> #define MODE4_DEBUG(fmt, ...) RTE_LOG(DEBUG, PMD, "%6u [Port %u: %s] " fmt,
> \
> bond_dbg_get_time_diff_ms(), slave_id, \
> @@ -1014,6 +1016,8 @@ bond_mode_8023ad_conf_get(struct rte_eth_dev *dev,
> conf->tx_period_ms = mode4->tx_period_timeout / ms_ticks;
> conf->update_timeout_ms = mode4->update_timeout_us / 1000;
> conf->rx_marker_period_ms = mode4->rx_marker_timeout / ms_ticks;
> + conf->slowrx_cb = mode4->slowrx_cb;
> + conf->external_sm = mode4->external_sm;
> }
>
> void
> @@ -1035,6 +1039,8 @@ bond_mode_8023ad_setup(struct rte_eth_dev *dev,
> conf->tx_period_ms = BOND_8023AD_TX_MACHINE_PERIOD_MS;
> conf->rx_marker_period_ms = BOND_8023AD_RX_MARKER_PERIOD_MS;
> conf->update_timeout_ms = BOND_MODE_8023AX_UPDATE_TIMEOUT_MS;
> + conf->slowrx_cb = NULL;
> + conf->external_sm = 0;
> }
>
> mode4->fast_periodic_timeout = conf->fast_periodic_ms * ms_ticks;
> @@ -1045,6 +1051,8 @@ bond_mode_8023ad_setup(struct rte_eth_dev *dev,
> mode4->tx_period_timeout = conf->tx_period_ms * ms_ticks;
> mode4->rx_marker_timeout = conf->rx_marker_period_ms * ms_ticks;
> mode4->update_timeout_us = conf->update_timeout_ms * 1000;
> + mode4->slowrx_cb = conf->slowrx_cb;
> + mode4->external_sm = conf->external_sm;
> }
>
> int
> @@ -1062,6 +1070,13 @@ bond_mode_8023ad_enable(struct rte_eth_dev *bond_dev)
> int
> bond_mode_8023ad_start(struct rte_eth_dev *bond_dev)
> {
> + struct bond_dev_private *internals = bond_dev->data->dev_private;
> + struct mode8023ad_private *mode4 = &internals->mode4;
> +
> + if (mode4->external_sm)
> + return rte_eal_alarm_set(BOND_MODE_8023AX_UPDATE_TIMEOUT_MS *
> 1000,
> + &bond_mode_8023ad_ext_periodic_cb, bond_dev);
> +
> return rte_eal_alarm_set(BOND_MODE_8023AX_UPDATE_TIMEOUT_MS * 1000,
> &bond_mode_8023ad_periodic_cb, bond_dev);
> }
> @@ -1069,6 +1084,13 @@ bond_mode_8023ad_start(struct rte_eth_dev *bond_dev)
> void
> bond_mode_8023ad_stop(struct rte_eth_dev *bond_dev)
> {
> + struct bond_dev_private *internals = bond_dev->data->dev_private;
> + struct mode8023ad_private *mode4 = &internals->mode4;
> +
> + if (mode4->external_sm) {
> + rte_eal_alarm_cancel(&bond_mode_8023ad_ext_periodic_cb,
> bond_dev);
> + return;
> + }
> rte_eal_alarm_cancel(&bond_mode_8023ad_periodic_cb, bond_dev);
> }
>
> @@ -1215,3 +1237,156 @@ rte_eth_bond_8023ad_slave_info(uint8_t port_id,
> uint8_t slave_id,
> info->agg_port_id = port->aggregator_port_id;
> return 0;
> }
> +
> +int
> +rte_eth_bond_8023ad_ext_collect(uint8_t port_id, uint8_t slave_id, int
> enabled)
> +{
> + struct rte_eth_dev *bond_dev;
> + struct bond_dev_private *internals;
> + struct mode8023ad_private *mode4;
> + struct port *port;
> +
> + if (valid_bonded_port_id(port_id) != 0 ||
> + rte_eth_bond_mode_get(port_id) != BONDING_MODE_8023AD)
The rte_eth_bond_mode_get() function already check if given port_id is
valid bonded device so you can remove valid_bonded_port_id() here.
You should check here is port is started.
> + return -EINVAL;
> +
> + bond_dev = &rte_eth_devices[port_id];
> +
> + internals = bond_dev->data->dev_private;
> + if (find_slave_by_id(internals->active_slaves,
> + internals->active_slave_count, slave_id) ==
> + internals->active_slave_count)
> + return -EINVAL;
> +
> + mode4 = &internals->mode4;
> + if (mode4->slowrx_cb == NULL || !mode4->external_sm)
> + return -EINVAL;
> +
> + port = &mode_8023ad_ports[slave_id];
> +
> + if (enabled)
> + ACTOR_STATE_SET(port, COLLECTING);
> + else
> + ACTOR_STATE_CLR(port, COLLECTING);
> +
> + return 0;
> +}
> +
> +int
> +rte_eth_bond_8023ad_ext_distrib(uint8_t port_id, uint8
[dpdk-dev] [PATCH 5/5] bond mode 4: tests for external state machine
On 2015-04-06 19:01, Eric Kinzie wrote:
>
> +static void
> +lacp_recv_cb(uint8_t slave_id, struct rte_mbuf *lacp_pkt)
> +{
> + lacpdu_rx_count[slave_id]++;
> + RTE_VERIFY(lacp_pkt != NULL);
> + rte_pktmbuf_free(lacp_pkt);
> +}
> +
Would be nice to check here if it is valid LACP packet.
--
Pawel
[dpdk-dev] Running DPDK Binaries on a different Target
The issue is with my application logic, which calculates the SIP/DIP MASK values. I am using "__builtin_ctz(x)" to calculate the SIP/DIP MASK. mask = 32 - __builtin_ctz(value). If the value is ZERO, the outcome is undefined. In my case, we are hitting the UNDEFINED case here. On MACHINE 1, __builtin_ctz(0) is returning 32, So, it works. On MACHINE 2, __builtin_ctz(0) is returning 0, So, it fails. Regards Venkat On 10 April 2015 at 10:38, Venkat Thummala wrote: > Hi Konstantin, > > Thanks a lot for looking in to this. > > In my case, I am using the ACL Pipeline Infra [My application logic is > built on the ACL pipeline]. > After your mail, I did verify the same with "l3fwd-acl" example, it just > worked fine. > Seems like, the issue is observed only with the Pipeline implementation. > Currently, I am debugging this, will update you once I have more info on > this. > Any known issues with the Pipeline implementation? > > Regards > Venkat > > > > On 9 April 2015 at 17:07, Ananyev, Konstantin < > konstantin.ananyev at intel.com> wrote: > >> >> Hi Venkat, >> >> > -Original Message- >> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Venkat Thummala >> > Sent: Thursday, April 09, 2015 10:07 AM >> > To: Neil Horman >> > Cc: dev at dpdk.org >> > Subject: Re: [dpdk-dev] Running DPDK Binaries on a different Target >> > >> > I have the following ACL rule configured in the ACL Table. >> > >> > Priority - 20 >> > SIP - 0 >> > SIP MASK - 0 >> > DIP - 0 >> > DIP MASK - 0 >> > PROTO - 17 [UDP] >> > PROTO MASK - 0xFF >> > SPORT - 0 >> > SPORT RANGE - 0x >> > DPORT - 0 >> > DPORT RANGE - 0x >> > >> > And pumping UDP traffic. >> > >> > On Machine 1, it always HITS the rule as expected. >> > >> > But On Machine 2, the same traffic never HITS the rule. >> > >> > I have tried this with both SCALAR and SSE classification algorithms, >> but >> > the result is same. >> >> So did I get it right: >> You build a binary with RTE_MACHINE="default" on a box with AVX2 support. >> Then run that binary on >> a) native box (machine with AVX2 support) >> b) machine without AVX2 support >> >> For the same input and same rules, same binary you got different results >> for a) and b). >> If that is the case, then there is something wrong here, either within >> our code or with the compiler you are using. >> Could you provide steps to reproduce it? >> I did a quick test with l3fwd-acl for that case, 'default' binary that I >> built on HSW board, >> works as expected on IVB box for me. >> >> Build box: HSW (E3-1285), gcc 4.8.3 >> SUT: IVB 2.80GHz, gcc 4.8.2 >> >> # cat acl_ipv4.rule1 >> R0.0.0.0/0 0.0.0.0/0 0 : 0x 0 : 0x 17/0xff 0 >> # cat acl_ipv6.rule1 >> R0:0:0:0:0:0:0:0/0 0:0:0:0:0:0:0:0/0 0 : 0x 0 : 0x 17/0xff 0 >> >> ./dpdk.org-acl/examples/l3fwd-acl/x86_64-default-linuxapp-gcc/l3fwd-acl >> --lcores=3 -n 4 --socket-mem=1024,0 -w :04:00.1 -- -p 1 --config "(0, >> 0, 3)" --rule_ipv4=./acl_ipv4.rule1 --rule_ipv6=acl_ipv6.rule1 -P >> >> Forwards UDP packets, drops all others. >> >> Anything else in your setup, that I am missing here? >> >> Konstantin >> >> > >> > Could some one, please help me on this? >> > >> > DPDK Version: >> > === >> > 2.0 >> > >> > Machine 1 CPU INFO: >> > >> > vendor_id: GenuineIntel >> > cpu family: 6 >> > model: 69 >> > model name: Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz >> > stepping: 1 >> > microcode: 0x16 >> > cpu MHz: 759.000 >> > cache size: 3072 KB >> > physical id: 0 >> > siblings: 4 >> > core id: 1 >> > cpu cores: 2 >> > apicid: 3 >> > initial apicid: 3 >> > fpu: yes >> > fpu_exception: yes >> > cpuid level: 13 >> > wp: yes >> > flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca >> > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall >> nx >> > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl >> > xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor >> > ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe >> popcnt >> > tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb >> > xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase >> > tsc_adjust bmi1 avx2 smep bmi2 erms invpcid >> > bogomips: 4589.70 >> > clflush size: 64 >> > cache_alignment: 64 >> > address sizes: 39 bits physical, 48 bits virtual >> > power management: >> > >> > MACHINE 1 OS: >> > = >> > Linux vthummala-HP-Pavilion-15-Notebook-PC 3.13.0-48-generic #80-Ubuntu >> SMP >> > Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> > >> > MACHINE 2 CPU INFO: >> > == >> > vendor_id: GenuineIntel >> > cpu family: 6 >> > model: 62 >> > model name: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz >> > stepping: 4 >> > microcode: 0x416 >> > cpu MHz: 2599.890 >> > cache size
[dpdk-dev] tools brainstorming
On Fri, Apr 10, 2015 at 01:49:33AM +, Wiles, Keith wrote: > > > On 4/9/15, 7:26 PM, "Neil Horman" wrote: > > >On Thu, Apr 09, 2015 at 09:10:19PM +, Wiles, Keith wrote: > >> > >> > >> On 4/9/15, 2:38 PM, "Jay Rolette" wrote: > >> > >> >On Thu, Apr 9, 2015 at 2:16 PM, Neil Horman > >>wrote: > >> > > >> >> On Thu, Apr 09, 2015 at 11:31:39AM -0500, Jay Rolette wrote: > >> >> > On Wed, Apr 8, 2015 at 5:38 PM, Stephen Hemminger < > >> >> > stephen at networkplumber.org> wrote: > >> >> > > >> >> > > On Wed, 8 Apr 2015 16:29:54 -0600 > >> >> > > Jay Rolette wrote: > >> >> > > > >> >> > > > "C comments" includes //, right? It's been part of the C > >>standard > >> >> for a > >> >> > > long time now... > >> >> > > > >> >> > > Yes but. > >> >> > > I like to use checkpatch and checkpatch enforces kernel style > >>which > >> >> does > >> >> > > not allow // for > >> >> > > comments. > >> >> > > > >> >> > > >> >> > Fork checkpatch and disable that bit? DPDK isn't the kernel, so no > >> >> > requirement to follow all of its rules > >> >> > > >> >> > >> >> Doesn't that beg the question, why? I understand the DPDK isn't the > >> >> kernel, but > >> >> we're not talking about clarity of code, not anything functional to > >>that > >> >> code. > >> >> It seems we would be better served by just taking something that > >>works > >> >>here > >> >> rather than re-inventing the wheel and digging into the minuate of > >>what > >> >> type of > >> >> comments should be allowed (unless there is a compelling reason to > >> >>change > >> >> it > >> >> that supercedes the avilable tools). If not checkpath, then some > >>other > >> >> tool, > >> >> but It seems to me that coding style is one of those things where we > >>can > >> >> bend to > >> >> the tool rather than taking the time to make the tool do exactly > >>whats > >> >> desired, > >> >> at least until someone gets the time to modify it. > >> >> > >> > > >> >Fair question. > >> > > >> >It depends a bit on how much you want to encourage patch > >>contributions. Is > >> >it worth adding more pain for folks trying to contribute patches for > >> >things > >> >like this? > >> > > >> >Should we force someone to spend time redoing a patch because of which > >>way > >> >they do their parenthesis? What about number of spaces to indent code? > >>// > >> >vs /* */ comments? None of these matter functionally and they don't > >>affect > >> >maintenance generally. > >> > > >> >If someone is modifying existing code, then yeah, they should follow > >>the > >> >prevailing style (indention level, brace alignment, etc.) of the file > >>they > >> >are in. It helps readability, which makes maintenance easier. However, > >> >IMO, > >> >mixing // and /* */ for comments doesn't affect the readability of the > >> >source. > >> > > >> >I know if I submit a patch and the only feedback is that I should have > >> >used > >> >/* */ for comments, I'm extremely unlikely spend extra time to resubmit > >> >the > >> >patch for pedantry. > >> > >> I looked at checkpatch.pl for few minutes and the code does check for > >>C99 > >> comments and adding a command line option to allow C99 comments could > >> pretty simple. I found the code around line 3048 or search for C99, it > >>is > >> possible it could accepted back into Linux as long as the default option > >> was to not allow C99 comments. > >> > >> Allowing C99 comments would be nice and the only problem I could see if > >> some compiler has a problem with them. I believe all of the compilers we > >> support allow C99 comments. > >> > >> The only other reason to allow them is if we add some open source code > >>in > >> the future to DPDK which has C99 comments and if would be a pain to have > >> to convert that code every time the open source group released a new > >> version. It does open that path IMO. > >> > > > >So, this again seems to be bad philosophy in my mind. If we are, to use > >your > >exmple, accept code into the DPDK in the future with comments that > >violate our > >selected style, it is then, by definition, in violation of the style > >guidelines. > > Who stated it violated the style guidelines, we do not have a style > guideline yet. This why Shiobhan sent out the guidelines in the first > place. > No one said anyone is violating our style guidelines, I think thats pretty obvious. You had said that allowing C99 comments would be a nice thing to be able to do in the future if we were to want to integrate a submission that had them. While thats true, I was pointing out that what you were suggesting was asserting the notion that doing so was relaxing style guidelines to allow for easier acceptance, while style guidelines (as a general notion, not as any specific set of rules we currently do or may in the future assert) are there to enforce a consistent look in the code. Put another way, we can certainly allow for both styles of comment (or multiple styles of any aspect of the code), if we want to, but doing so is somewha
[dpdk-dev] [PATCH] doc: add field widths to prog guide glossary
Added explicit field widths to Programmer's Guide
Glossary table to control the PDF output. Previously
the table overflowed the right margin.
This doesn't affect the Html output.
Also, added bold format to colunm headers for clarity.
Signed-off-by: John McNamara
---
doc/guides/prog_guide/glossary.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/glossary.rst
b/doc/guides/prog_guide/glossary.rst
index 913946d..657248c 100644
--- a/doc/guides/prog_guide/glossary.rst
+++ b/doc/guides/prog_guide/glossary.rst
@@ -31,8 +31,10 @@
Glossary
+.. tabularcolumns:: |p{4cm}|p{11cm}|
+
===
=
-Term Definition
+**Term** **Definition**
===
=
ACL Access Control List
--
1.8.1.4
[dpdk-dev] [PATCH] doc: add field widths to prog guide glossary
2015-04-10 15:20, John McNamara: > Added explicit field widths to Programmer's Guide > Glossary table to control the PDF output. Previously > the table overflowed the right margin. Long tables should be avoided in RST as they are not easy to read or update. Why not using definition lists? http://docutils.sourceforge.net/docs/user/rst/quickref.html#definition-lists
[dpdk-dev] tools brainstorming
On 4/10/15, 6:41 AM, "Neil Horman" wrote: >On Fri, Apr 10, 2015 at 01:49:33AM +, Wiles, Keith wrote: >> >> >> On 4/9/15, 7:26 PM, "Neil Horman" wrote: >> >> >On Thu, Apr 09, 2015 at 09:10:19PM +, Wiles, Keith wrote: >> >> >> >> >> >> On 4/9/15, 2:38 PM, "Jay Rolette" wrote: >> >> >> >> >On Thu, Apr 9, 2015 at 2:16 PM, Neil Horman >> >>wrote: >> >> > >> >> >> On Thu, Apr 09, 2015 at 11:31:39AM -0500, Jay Rolette wrote: >> >> >> > On Wed, Apr 8, 2015 at 5:38 PM, Stephen Hemminger < >> >> >> > stephen at networkplumber.org> wrote: >> >> >> > >> >> >> > > On Wed, 8 Apr 2015 16:29:54 -0600 >> >> >> > > Jay Rolette wrote: >> >> >> > > >> >> >> > > > "C comments" includes //, right? It's been part of the C >> >>standard >> >> >> for a >> >> >> > > long time now... >> >> >> > > >> >> >> > > Yes but. >> >> >> > > I like to use checkpatch and checkpatch enforces kernel style >> >>which >> >> >> does >> >> >> > > not allow // for >> >> >> > > comments. >> >> >> > > >> >> >> > >> >> >> > Fork checkpatch and disable that bit? DPDK isn't the kernel, so >>no >> >> >> > requirement to follow all of its rules >> >> >> > >> >> >> >> >> >> Doesn't that beg the question, why? I understand the DPDK isn't >>the >> >> >> kernel, but >> >> >> we're not talking about clarity of code, not anything functional >>to >> >>that >> >> >> code. >> >> >> It seems we would be better served by just taking something that >> >>works >> >> >>here >> >> >> rather than re-inventing the wheel and digging into the minuate of >> >>what >> >> >> type of >> >> >> comments should be allowed (unless there is a compelling reason to >> >> >>change >> >> >> it >> >> >> that supercedes the avilable tools). If not checkpath, then some >> >>other >> >> >> tool, >> >> >> but It seems to me that coding style is one of those things where >>we >> >>can >> >> >> bend to >> >> >> the tool rather than taking the time to make the tool do exactly >> >>whats >> >> >> desired, >> >> >> at least until someone gets the time to modify it. >> >> >> >> >> > >> >> >Fair question. >> >> > >> >> >It depends a bit on how much you want to encourage patch >> >>contributions. Is >> >> >it worth adding more pain for folks trying to contribute patches for >> >> >things >> >> >like this? >> >> > >> >> >Should we force someone to spend time redoing a patch because of >>which >> >>way >> >> >they do their parenthesis? What about number of spaces to indent >>code? >> >>// >> >> >vs /* */ comments? None of these matter functionally and they don't >> >>affect >> >> >maintenance generally. >> >> > >> >> >If someone is modifying existing code, then yeah, they should follow >> >>the >> >> >prevailing style (indention level, brace alignment, etc.) of the >>file >> >>they >> >> >are in. It helps readability, which makes maintenance easier. >>However, >> >> >IMO, >> >> >mixing // and /* */ for comments doesn't affect the readability of >>the >> >> >source. >> >> > >> >> >I know if I submit a patch and the only feedback is that I should >>have >> >> >used >> >> >/* */ for comments, I'm extremely unlikely spend extra time to >>resubmit >> >> >the >> >> >patch for pedantry. >> >> >> >> I looked at checkpatch.pl for few minutes and the code does check for >> >>C99 >> >> comments and adding a command line option to allow C99 comments could >> >> pretty simple. I found the code around line 3048 or search for C99, >>it >> >>is >> >> possible it could accepted back into Linux as long as the default >>option >> >> was to not allow C99 comments. >> >> >> >> Allowing C99 comments would be nice and the only problem I could see >>if >> >> some compiler has a problem with them. I believe all of the >>compilers we >> >> support allow C99 comments. >> >> >> >> The only other reason to allow them is if we add some open source >>code >> >>in >> >> the future to DPDK which has C99 comments and if would be a pain to >>have >> >> to convert that code every time the open source group released a new >> >> version. It does open that path IMO. >> >> >> > >> >So, this again seems to be bad philosophy in my mind. If we are, to >>use >> >your >> >exmple, accept code into the DPDK in the future with comments that >> >violate our >> >selected style, it is then, by definition, in violation of the style >> >guidelines. >> >> Who stated it violated the style guidelines, we do not have a style >> guideline yet. This why Shiobhan sent out the guidelines in the first >> place. >> >No one said anyone is violating our style guidelines, I think thats pretty >obvious. You had said that allowing C99 comments would be a nice thing >to be >able to do in the future if we were to want to integrate a submission >that had >them. While thats true, I was pointing out that what you were suggesting >was >asserting the notion that doing so was relaxing style guidelines to allow >for >easier acceptance, while style guidelines (as a general notion, not as any >specific set of rules we currently do or may in the futu
[dpdk-dev] [PATCH] doc: fixed verbatim sections in vmxnet3 docs
Fixed two verbatim text sections in vmxnet3 docs. Signed-off-by: John McNamara --- doc/guides/nics/vmxnet3.rst | 27 --- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/doc/guides/nics/vmxnet3.rst b/doc/guides/nics/vmxnet3.rst index 3aa5b40..830530d 100644 --- a/doc/guides/nics/vmxnet3.rst +++ b/doc/guides/nics/vmxnet3.rst @@ -149,10 +149,15 @@ This section describes an example setup for Phy-vSwitch-VM-Phy communication. Other instructions on preparing to use DPDK such as, hugepage enabling, uio port binding are not listed here. Please refer to *DPDK Getting Started Guide and DPDK Sample Application's User Guide* for detailed instructions. -The packet reception and transmission flow path is: +The packet reception and transmission flow path is:: -Packet generator -> 82576 -> VMware ESXi vSwitch -> VMXNET3 device -> Guest VM VMXNET3 port 0 rx burst -> Guest -VM 82599 VF port 0 tx burst -> 82599 VF -> Packet generator +Packet generator -> 82576 + -> VMware ESXi vSwitch + -> VMXNET3 device + -> Guest VM VMXNET3 port 0 rx burst + -> Guest VM 82599 VF port 0 tx burst + -> 82599 VF + -> Packet generator VMXNET3 Chaining VMs Connected to a vSwitch --- @@ -166,7 +171,15 @@ The following figure shows an example VM-to-VM communication over a Phy-VM-vSwit When using the L2 Forwarding or L3 Forwarding applications, a destination MAC address needs to be written in packets to hit the other VM's VMXNET3 interface. -In this example, the packet flow path is: - -Packet generator -> 82599 VF -> Guest VM 82599 port 0 rx burst -> Guest VM VMXNET3 port 1 tx burst -> VMXNET3 -device -> VMware ESXi vSwitch -> VMXNET3 device -> Guest VM VMXNET3 port 0 rx burst -> Guest VM 82599 VF port 1 tx burst -> 82599 VF -> Packet generator +In this example, the packet flow path is:: + +Packet generator -> 82599 VF + -> Guest VM 82599 port 0 rx burst + -> Guest VM VMXNET3 port 1 tx burst + -> VMXNET3 device + -> VMware ESXi vSwitch + -> VMXNET3 device + -> Guest VM VMXNET3 port 0 rx burst + -> Guest VM 82599 VF port 1 tx burst + -> 82599 VF + -> Packet generator -- 1.8.1.4
[dpdk-dev] [PATCH] doc: add field widths to prog guide glossary
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, April 10, 2015 3:34 PM > To: Mcnamara, John > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] doc: add field widths to prog guide > glossary > > Long tables should be avoided in RST as they are not easy to read or > update. > Why not using definition lists? > http://docutils.sourceforge.net/docs/user/rst/quickref.html#definiti > on-lists Hi Thomas, That is a better suggestion. I'll reformat the table as a definition list and resubmit. John
[dpdk-dev] [PATCH 0/2] fix logging in Intel PMD's
The Intel Poll Mode Drivers generate a lot of log messages and they are mostly at the INFO logging level. This should be changed to the common syslog conventions, ie. put unimportant stuff for production users at DEBUG level and things of interest but not errors at NOTICE level. Also should use RTE_LOG not rte_log so that messages can be compiled out. Stephen Hemminger (2): ixgbe: silence noisy log messages e1000: silence noisy log messages lib/librte_pmd_e1000/e1000_logs.h | 3 +-- lib/librte_pmd_e1000/em_ethdev.c| 10 - lib/librte_pmd_e1000/igb_ethdev.c | 16 ++- lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 41 - lib/librte_pmd_ixgbe/ixgbe_fdir.c | 2 +- lib/librte_pmd_ixgbe/ixgbe_logs.h | 3 +-- lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 14 ++--- 7 files changed, 38 insertions(+), 51 deletions(-) -- 2.1.4
[dpdk-dev] [PATCH 1/2] ixgbe: silence noisy log messages
The ixgbe driver likes to be far to chatty in the system log
which is good for the original developer but not good for a production
product.
Reduce the log spam by doing:
* All the normal messages should be changed from INFO to DEBUG.
* The log messages should be done with RTE_LOG so that they can be
compiled out if RTE_LOG_LEVEL is set.
* The link state print routine prints more than is necessary
PCI information is already known (earlier in log) and has
no purpose here.
Signed-off-by: Stephen Hemminger
---
lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 41 -
lib/librte_pmd_ixgbe/ixgbe_fdir.c | 2 +-
lib/librte_pmd_ixgbe/ixgbe_logs.h | 3 +--
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 14 ++---
4 files changed, 27 insertions(+), 33 deletions(-)
diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index 5caee22..adc0fb9 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -569,8 +569,8 @@ ixgbe_dev_queue_stats_mapping_set(struct rte_eth_dev
*eth_dev,
(hw->mac.type != ixgbe_mac_X550EM_x))
return -ENOSYS;
- PMD_INIT_LOG(INFO, "Setting port %d, %s queue_id %d to stat index %d",
-(int)(eth_dev->data->port_id), is_rx ? "RX" : "TX",
+ PMD_INIT_LOG(DEBUG, "Setting port %u, %s queue_id %d to stat index %d",
+eth_dev->data->port_id, is_rx ? "RX" : "TX",
queue_id, stat_idx);
n = (uint8_t)(queue_id / NB_QMAP_FIELDS_PER_QSM_REG);
@@ -595,20 +595,20 @@ ixgbe_dev_queue_stats_mapping_set(struct rte_eth_dev
*eth_dev,
else
stat_mappings->rqsmr[n] |= qsmr_mask;
- PMD_INIT_LOG(INFO, "Set port %d, %s queue_id %d to stat index %d",
-(int)(eth_dev->data->port_id), is_rx ? "RX" : "TX",
+ PMD_INIT_LOG(DEBUG, "Set port %u, %s queue_id %d to stat index %d",
+eth_dev->data->port_id, is_rx ? "RX" : "TX",
queue_id, stat_idx);
- PMD_INIT_LOG(INFO, "%s[%d] = 0x%08x", is_rx ? "RQSMR" : "TQSM", n,
+ PMD_INIT_LOG(DEBUG, "%s[%d] = 0x%08x", is_rx ? "RQSMR" : "TQSM", n,
is_rx ? stat_mappings->rqsmr[n] : stat_mappings->tqsm[n]);
/* Now write the mapping in the appropriate register */
if (is_rx) {
- PMD_INIT_LOG(INFO, "Write 0x%x to RX IXGBE stat mapping reg:%d",
+ PMD_INIT_LOG(DEBUG, "Write 0x%x to RX IXGBE stat mapping
reg:%d",
stat_mappings->rqsmr[n], n);
IXGBE_WRITE_REG(hw, IXGBE_RQSMR(n), stat_mappings->rqsmr[n]);
}
else {
- PMD_INIT_LOG(INFO, "Write 0x%x to TX IXGBE stat mapping reg:%d",
+ PMD_INIT_LOG(DEBUG, "Write 0x%x to TX IXGBE stat mapping
reg:%d",
stat_mappings->tqsm[n], n);
IXGBE_WRITE_REG(hw, IXGBE_TQSM(n), stat_mappings->tqsm[n]);
}
@@ -752,7 +752,7 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
ixgbe_set_tx_function(eth_dev, txq);
} else {
/* Use default TX function if we get here */
- PMD_INIT_LOG(INFO, "No TX queues configured yet. "
+ PMD_INIT_LOG(DEBUG, "No TX queues configured yet. "
"Using default TX function.");
}
@@ -1249,7 +1249,7 @@ ixgbe_vlan_hw_strip_disable(struct rte_eth_dev *dev,
uint16_t queue)
if (hw->mac.type == ixgbe_mac_82598EB) {
/* No queue level support */
- PMD_INIT_LOG(INFO, "82598EB not support queue level hw strip");
+ PMD_INIT_LOG(NOTICE, "82598EB not support queue level hw
strip");
return;
}
else {
@@ -1273,7 +1273,7 @@ ixgbe_vlan_hw_strip_enable(struct rte_eth_dev *dev,
uint16_t queue)
if (hw->mac.type == ixgbe_mac_82598EB) {
/* No queue level supported */
- PMD_INIT_LOG(INFO, "82598EB not support queue level hw strip");
+ PMD_INIT_LOG(NOTICE, "82598EB not support queue level hw
strip");
return;
}
else {
@@ -2265,7 +2265,7 @@ ixgbe_dev_interrupt_get_status(struct rte_eth_dev *dev)
/* read-on-clear nic registers here */
eicr = IXGBE_READ_REG(hw, IXGBE_EICR);
- PMD_DRV_LOG(INFO, "eicr %x", eicr);
+ PMD_DRV_LOG(DEBUG, "eicr %x", eicr);
intr->flags = 0;
if (eicr & IXGBE_EICR_LSC) {
@@ -2297,20 +2297,15 @@ ixgbe_dev_link_status_print(struct rte_eth_dev *dev)
memset(&link, 0, sizeof(link));
rte_ixgbe_dev_atomic_read_link_status(dev, &link);
if (link.link_status) {
- PMD_INIT_LOG(INFO, "Port %d: Link Up - speed %u Mbps - %s",
- (int)(dev->data->port_id),
+ PMD_INIT_LOG(DEBUG, "P
[dpdk-dev] [PATCH 2/2] e1000: silence noisy log messages
Same as ixgbe. Should not be as chatty in log and should be
possible to compile away all the debug messages.
Signed-off-by: Stephen Hemminger
---
lib/librte_pmd_e1000/e1000_logs.h | 3 +--
lib/librte_pmd_e1000/em_ethdev.c | 10 --
lib/librte_pmd_e1000/igb_ethdev.c | 16 ++--
3 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/lib/librte_pmd_e1000/e1000_logs.h
b/lib/librte_pmd_e1000/e1000_logs.h
index 4a92804..81e7bf5 100644
--- a/lib/librte_pmd_e1000/e1000_logs.h
+++ b/lib/librte_pmd_e1000/e1000_logs.h
@@ -35,8 +35,7 @@
#define _E1000_LOGS_H_
#define PMD_INIT_LOG(level, fmt, args...) \
- rte_log(RTE_LOG_ ## level, RTE_LOGTYPE_PMD, \
- "PMD: %s(): " fmt "\n", __func__, ##args)
+ RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ##args)
#ifdef RTE_LIBRTE_E1000_DEBUG_INIT
#define PMD_INIT_FUNC_TRACE() PMD_INIT_LOG(DEBUG, " >>")
diff --git a/lib/librte_pmd_e1000/em_ethdev.c b/lib/librte_pmd_e1000/em_ethdev.c
index 76f45c9..9189134 100644
--- a/lib/librte_pmd_e1000/em_ethdev.c
+++ b/lib/librte_pmd_e1000/em_ethdev.c
@@ -270,7 +270,7 @@ eth_em_dev_init(struct rte_eth_dev *eth_dev)
/* initialize the vfta */
memset(shadow_vfta, 0, sizeof(*shadow_vfta));
- PMD_INIT_LOG(INFO, "port_id %d vendorID=0x%x deviceID=0x%x",
+ PMD_INIT_LOG(DEBUG, "port_id %d vendorID=0x%x deviceID=0x%x",
eth_dev->data->port_id, pci_dev->id.vendor_id,
pci_dev->id.device_id);
@@ -1293,16 +1293,14 @@ eth_em_interrupt_action(struct rte_eth_dev *dev)
memset(&link, 0, sizeof(link));
rte_em_dev_atomic_read_link_status(dev, &link);
if (link.link_status) {
- PMD_INIT_LOG(INFO, " Port %d: Link Up - speed %u Mbps - %s",
+ PMD_INIT_LOG(DEBUG, " Port %d: Link Up - speed %u Mbps - %s",
dev->data->port_id, (unsigned)link.link_speed,
link.link_duplex == ETH_LINK_FULL_DUPLEX ?
"full-duplex" : "half-duplex");
} else {
- PMD_INIT_LOG(INFO, " Port %d: Link Down", dev->data->port_id);
+ PMD_INIT_LOG(DEBUG, " Port %d: Link Down", dev->data->port_id);
}
- PMD_INIT_LOG(INFO, "PCI Address: %04d:%02d:%02d:%d",
-dev->pci_dev->addr.domain, dev->pci_dev->addr.bus,
-dev->pci_dev->addr.devid, dev->pci_dev->addr.function);
+
tctl = E1000_READ_REG(hw, E1000_TCTL);
rctl = E1000_READ_REG(hw, E1000_RCTL);
if (link.link_status) {
diff --git a/lib/librte_pmd_e1000/igb_ethdev.c
b/lib/librte_pmd_e1000/igb_ethdev.c
index b3892a5..7d00aed 100644
--- a/lib/librte_pmd_e1000/igb_ethdev.c
+++ b/lib/librte_pmd_e1000/igb_ethdev.c
@@ -580,7 +580,7 @@ eth_igb_dev_init(struct rte_eth_dev *eth_dev)
E1000_WRITE_REG(hw, E1000_CTRL_EXT, ctrl_ext);
E1000_WRITE_FLUSH(hw);
- PMD_INIT_LOG(INFO, "port_id %d vendorID=0x%x deviceID=0x%x",
+ PMD_INIT_LOG(DEBUG, "port_id %d vendorID=0x%x deviceID=0x%x",
eth_dev->data->port_id, pci_dev->id.vendor_id,
pci_dev->id.device_id);
@@ -1906,21 +1906,17 @@ eth_igb_interrupt_action(struct rte_eth_dev *dev)
memset(&link, 0, sizeof(link));
rte_igb_dev_atomic_read_link_status(dev, &link);
if (link.link_status) {
- PMD_INIT_LOG(INFO,
+ PMD_INIT_LOG(DEBUG,
" Port %d: Link Up - speed %u Mbps - %s",
dev->data->port_id,
(unsigned)link.link_speed,
link.link_duplex == ETH_LINK_FULL_DUPLEX ?
"full-duplex" : "half-duplex");
} else {
- PMD_INIT_LOG(INFO, " Port %d: Link Down",
+ PMD_INIT_LOG(DEBUG, " Port %d: Link Down",
dev->data->port_id);
}
- PMD_INIT_LOG(INFO, "PCI Address: %04d:%02d:%02d:%d",
-dev->pci_dev->addr.domain,
-dev->pci_dev->addr.bus,
-dev->pci_dev->addr.devid,
-dev->pci_dev->addr.function);
+
tctl = E1000_READ_REG(hw, E1000_TCTL);
rctl = E1000_READ_REG(hw, E1000_RCTL);
if (link.link_status) {
@@ -2204,12 +2200,12 @@ igbvf_dev_configure(struct rte_eth_dev *dev)
*/
#ifndef RTE_LIBRTE_E1000_PF_DISABLE_STRIP_CRC
if (!conf->rxmode.hw_strip_crc) {
- PMD_INIT_LOG(INFO, "VF can't disable HW CRC Strip");
+ PMD_INIT_LOG(NOTICE, "VF can't disable HW CRC Strip");
conf->rxmode.hw_strip_crc = 1;
}
#else
if (conf->rxmode.hw_strip_crc) {
- PMD_INIT_LOG(INFO, "VF can't enable
[dpdk-dev] [PATCH] doc: convert prog guide glossary to definition list
Converted the Glossary table in the Programmer's Guide to a definition list to improve rendering. Signed-off-by: John McNamara --- doc/guides/prog_guide/glossary.rst | 261 - 1 file changed, 168 insertions(+), 93 deletions(-) diff --git a/doc/guides/prog_guide/glossary.rst b/doc/guides/prog_guide/glossary.rst index 913946d..4cbed4c 100644 --- a/doc/guides/prog_guide/glossary.rst +++ b/doc/guides/prog_guide/glossary.rst @@ -31,169 +31,244 @@ Glossary -=== = -Term Definition -=== = -ACL Access Control List -API Application Programming Interface +ACL + Access Control List -ASLR Linux* kernel Address-Space Layout Randomization +API + Application Programming Interface -BSD Berkeley Software Distribution +ASLR + Linux* kernel Address-Space Layout Randomization -Clr Clear +BSD + Berkeley Software Distribution -CIDR Classless Inter-Domain Routing +Clr + Clear -Control Plane The control plane is concerned with the routing of packets and with providing a start or end point. +CIDR + Classless Inter-Domain Routing -Core A core may include several lcores or threads if the processor supports hyperthreading. +Control Plane + The control plane is concerned with the routing of packets and with + providing a start or end point. -Core Components A set of libraries provided by the DPDK, including eal, ring, mempool, mbuf, timers, and so on. +Core + A core may include several lcores or threads if the processor supports + hyperthreading. -CPU Central Processing Unit +Core Components + A set of libraries provided by the DPDK, including eal, ring, mempool, + mbuf, timers, and so on. -CRC Cyclic Redundancy Check +CPU + Central Processing Unit -ctrlmbuf An *mbuf* carrying control data. +CRC + Cyclic Redundancy Check -Data PlaneIn contrast to the control plane, - the data plane in a network architecture are the layers involved when forwarding packets. - These layers must be highly optimized to achieve good performance. +ctrlmbuf + An *mbuf* carrying control data. -DIMM Dual In-line Memory Module +Data Plane + In contrast to the control plane, the data plane in a network architecture + are the layers involved when forwarding packets. These layers must be + highly optimized to achieve good performance. -Doxygen A documentation generator used in the DPDK to generate the API reference. +DIMM + Dual In-line Memory Module -DPDK Data Plane Development Kit +Doxygen + A documentation generator used in the DPDK to generate the API reference. -DRAM Dynamic Random Access Memory +DPDK + Data Plane Development Kit -EAL The Environment Abstraction Layer (EAL) provides a generic interface that hides the environment specifics - from the applications and libraries. - The services expected from the EAL are: - development kit loading and launching, core affinity/ assignment procedures, - system memory allocation/description, PCI bus access, inter-partition communication. +DRAM + Dynamic Random Access Memory -FIFO First In First Out +EAL + The Environment Abstraction Layer (EAL) provides a generic interface that + hides the environment specifics from the applications and libraries. The + services expected from the EAL are: development kit loading and launching, + core affinity/ assignment procedures, system memory allocation/description, + PCI bus access, inter-partition communication. -FPGA Field Programmable Gate Array +FIFO + First In First Out -GbE Gigabit Ethernet +FPGA + Field Programmable Gate Array -HWHardware +GbE + Gigabit Ethernet -HPET High Precision Event Timer; - a hardware timer that provides a precise time reference on x86 platforms. +HW + Hardware -IDIdentifier +HPET + High Precision Event Timer; a har
[dpdk-dev] [RFC PATCH 0/4] Extending DPDK to have more devices supported
Any comments on this RFC Patch? Must be perfect right :-) On 4/8/15, 3:58 PM, "Keith Wiles" wrote: >Hi All, > >Here is a set of RFC patches to update DPDK to support a generic set of >devices. The patches that follow create two files eal_common_device.h >and rte_common_device.c and then a few items in rte_ethdev.[ch] were moved >to cleanup those files by moving the device generic values and functions >into a common set of device generic files. > >In the rte_common_device.h file are a couple of macros to abstract a few >common items from rte_ethdev.h which are not ethernet specific. These >generic device specific structure members are place into macros to be >placed at the top of each new device type crypto, hardware offload, dpi, >compression and possible others to be defined later. > Note: could have used nested structures, but required a larger change >set. > >I did not pull the Rx/Tx Routines into a common function, but it could be >done if everyone agrees. It does not mean every device will use a common >Rx/Tx routine. Without pulling Rx/Tx routines into a common file allows >the device writer to have similar or different set of routines. > >These patches do not contain any new devices as these are being work on >today. > >More cleanup of ethdev could be done to remove NIC specific features not >supported in all devices and someone needs to do that cleanup IMO. > >The code is untested and I wanted to get something our for others to poke >at >today and more could be pulled out of ethdev as well. I/We will be looking >at testing the code as we get more completed. > >I have not finished up the crypto APIs yet, but I am planning to work on >those additions today. The crypto code we are using is the Quick Assist >code >found on 01.org, but we need to update the code to be move DPDK friendly. > >The QAT code does have a modified like API similar to Linux Kernel crypto >API >and I want to review that code first. > >Regards, >++Keith > >Keith Wiles (4): > Rename of device types to be generic device names. > Add the new common device header and C file. > Update files to build new device generic common files and headers. > Update the rte_ethdev.[ch] files for the new device generic changes. > > app/test/test_link_bonding.c | 10 +- > app/test/virtual_pmd.c| 4 +- > examples/link_status_interrupt/main.c | 6 +- > lib/librte_eal/bsdapp/eal/Makefile| 1 + > lib/librte_eal/common/Makefile| 1 + > lib/librte_eal/common/eal_common_device.c | 185 +++ > lib/librte_eal/common/include/rte_common_device.h | 617 >++ > lib/librte_eal/common/include/rte_log.h | 1 + > lib/librte_eal/linuxapp/eal/Makefile | 1 + > lib/librte_ether/rte_ethdev.c | 290 ++ > lib/librte_ether/rte_ethdev.h | 225 +++- > lib/librte_pmd_af_packet/rte_eth_af_packet.c | 2 +- > lib/librte_pmd_bond/rte_eth_bond_api.c| 6 +- > lib/librte_pmd_bond/rte_eth_bond_pmd.c| 12 +- > lib/librte_pmd_bond/rte_eth_bond_private.h| 2 +- > lib/librte_pmd_e1000/em_ethdev.c | 8 +- > lib/librte_pmd_e1000/em_rxtx.c| 4 +- > lib/librte_pmd_e1000/igb_ethdev.c | 2 +- > lib/librte_pmd_i40e/i40e_ethdev.c | 4 +- > lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 2 +- > lib/librte_pmd_mlx4/mlx4.c| 2 +- > lib/librte_pmd_null/rte_eth_null.c| 2 +- > lib/librte_pmd_pcap/rte_eth_pcap.c| 2 +- > lib/librte_pmd_ring/rte_eth_ring.c| 2 +- > lib/librte_pmd_virtio/virtio_ethdev.c | 2 +- > lib/librte_pmd_xenvirt/rte_eth_xenvirt.c | 2 +- > 26 files changed, 969 insertions(+), 426 deletions(-) > create mode 100644 lib/librte_eal/common/eal_common_device.c > create mode 100644 lib/librte_eal/common/include/rte_common_device.h > >-- >2.3.0 >
[dpdk-dev] [RFC PATCH 2/4] Add the new common device header and C file.
On 4/9/15, 6:53 AM, "Neil Horman" wrote:
>On Wed, Apr 08, 2015 at 03:58:38PM -0500, Keith Wiles wrote:
>> Move a number of device specific define, structures and functions
>> into a generic device base set of files for all device not just
>>Ethernet.
>>
>> Signed-off-by: Keith Wiles
>> ---
>> lib/librte_eal/common/eal_common_device.c | 185 +++
>> lib/librte_eal/common/include/rte_common_device.h | 617
>>++
>> 2 files changed, 802 insertions(+)
>> create mode 100644 lib/librte_eal/common/eal_common_device.c
>> create mode 100644 lib/librte_eal/common/include/rte_common_device.h
>>
>> diff --git a/lib/librte_eal/common/eal_common_device.c
>>b/lib/librte_eal/common/eal_common_device.c
>> new file mode 100644
>> index 000..a9ef925
>> --- /dev/null
>> +++ b/lib/librte_eal/common/eal_common_device.c
>> @@ -0,0 +1,185 @@
>> +/*-
>> + * BSD LICENSE
>> + *
>> + * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>> + * Copyright(c) 2014 6WIND S.A.
>> + * All rights reserved.
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + *
>> + * * Redistributions of source code must retain the above copyright
>> + * notice, this list of conditions and the following disclaimer.
>> + * * Redistributions in binary form must reproduce the above
>>copyright
>> + * notice, this list of conditions and the following disclaimer
>>in
>> + * the documentation and/or other materials provided with the
>> + * distribution.
>> + * * Neither the name of Intel Corporation nor the names of its
>> + * contributors may be used to endorse or promote products
>>derived
>> + * from this software without specific prior written permission.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
>>CONTRIBUTORS
>> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
>>FOR
>> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
>>COPYRIGHT
>> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
>>INCIDENTAL,
>> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
>>USE,
>> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
>>ANY
>> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
>>TORT
>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
>>USE
>> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
>>DAMAGE.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "rte_common_device.h"
>> +
>> +void *
>> +rte_dev_add_callback(struct rte_dev_rxtx_callback ** cbp,
>> +void * fn, void *user_param)
>> +{
>> +struct rte_dev_rxtx_callback *cb;
>> +
>> +cb = rte_zmalloc(NULL, sizeof(*cb), 0);
>> +
>> +if (cb == NULL) {
>> +rte_errno = ENOMEM;
>> +return NULL;
>> +}
>> +
>> +cb->fn.vp = fn;
>> +cb->param = user_param;
>> +cb->next = *cbp;
>> +*cbp = cb;
>> +return cb;
>> +}
>> +
>> +int
>> +rte_dev_remove_callback(struct rte_dev_rxtx_callback ** cbp,
>> +struct rte_dev_rxtx_callback *user_cb)
>> +{
>> +struct rte_dev_rxtx_callback *cb = *cbp;
>> +struct rte_dev_rxtx_callback *prev_cb;
>> +
>> +/* Reset head pointer and remove user cb if first in the list. */
>> +if (cb == user_cb) {
>> +*cbp = user_cb->next;
>> +return 0;
>> +}
>> +
>> +/* Remove the user cb from the callback list. */
>> +do {
>> +prev_cb = cb;
>> +cb = cb->next;
>> +
>> +if (cb == user_cb) {
>> +prev_cb->next = user_cb->next;
>> +return 0;
>> +}
>> +} while (cb != NULL);
>> +
>> +/* Callback wasn't found. */
>> +return (-EINVAL);
>> +}
>> +
>> +int
>> +rte_dev_callback_register(struct rte_dev_cb_list * cb_list,
>> +rte_spinlock_t * lock,
>> +enum rte_dev_event_type event,
>> +rte_dev_cb_fn cb_fn, void *cb_arg)
>> +{
>> +struct rte_dev_callback *cb;
>> +
>> +rte_spinlock_lock(lock);
>> +
>> +TAILQ_FOREACH(cb, cb_list, next) {
>> +if (cb->cb_fn == cb_fn &&
>> +cb->cb_arg == cb_arg &&
>> +cb->event == event) {
>> +break;
>> +}
>> +}
>> +
>> +/* create a new callback. */
>> +if (cb == NULL && (cb = rte_zmalloc("INTR_USER_CALLBACK",
>> +sizeof(struct rte_dev_callback), 0)) != NULL) {
>> +cb->cb_fn = cb_fn;
>> +cb-
