[dpdk-dev] [PATCH v2] scripts: check commit formatting
On Mon, Apr 11, 2016 at 05:39:05PM +0200, Thomas Monjalon wrote: > The git messages have three parts: > 1/ the headline > 2/ the explanations > 3/ the footer tags > > The headline helps to quickly browse an history or catch instantly the > purpose of a commit. Making it short with some consistent wording > allows to easily parse it or match some patterns. > > The explanations must give some keys like the reason of the change. > Nothing can be automatically checked for this part, except line length. > > The footer contains some tags to find the origin of a bug or who > was working on it. > > This script is doing some basic checks mostly on parts 1 and 3. > > Signed-off-by: Thomas Monjalon Reviewed-by: Yuanhan Liu --yliu
[dpdk-dev] [PATCH] vhost: fix mem share between VM and host
On Mon, Apr 11, 2016 at 06:22:12AM +, Xie, Huawei wrote:
> On 4/11/2016 1:29 AM, Zhe Tao wrote:
> >
> > +/* Check the share memory in case the QEMU doesn't set the share option
> > + * as on for the memory-backend-file object in the QEMU command line.
> > + */
> > +
> > +int
> > +vhost_check_mem_shared(struct vhost_device_ctx ctx)
> > +{
> > + struct virtio_net *dev;
> > + struct vhost_virtqueue *vq;
> > + int ret = 0;
> > +
> > + dev = get_device(ctx);
> > + if ((dev == NULL) || (dev->mem == NULL))
> > + return -1;
> > +
> > + /* check first virtqueue 0 rxq. */
> > + vq = dev->virtqueue[VIRTIO_RXQ];
> > + ret = vq->desc[0].next == 0 ? -1 : 0;
> > +
> > + if (ret)
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "The mem is not shared between VM and host\n");
> > +
> > + return ret;
> > +}
> > +
>
> Zhe: This is known to vhost-user users that share=on is a must-to-have
> option. I think this isn't an issue.
Agreed.
> It is OK if we could do some early check in vhost, however we couldn't
I think if there is really a need to do the check, it might should be
done in QEMU: the option is from QEMU after all.
> assume the value of vq->desc[0].next.
> Check if there is other simple and reliable way.
I will not say no to an elegant check though.
--yliu
[dpdk-dev] [PATCH v3 0/4] external mempool manager
On Wed, Mar 09, 2016 at 09:50:33AM +, David Hunt wrote: ... > The external mempool manager needs to provide the following functions. > 1. alloc - allocates the mempool memory, and adds each object onto a ring > 2. put - puts an object back into the mempool once an application has > finished with it > 3. get - gets an object from the mempool for use by the application > 4. get_count - gets the number of available objects in the mempool > 5. free - frees the mempool memory It's a lengthy and great description, and it's a pity that you don't include it in the commit log: cover letter will not be in the history. > > For and example of a simple malloc based mempool manager, see > lib/librte_mempool/custom_mempool.c I didn't see this file. Forgot to include it? --yliu
[dpdk-dev] [PATCH v3 1/4] mempool: add external mempool manager support
Hi David,
On Wed, Mar 09, 2016 at 09:50:34AM +, David Hunt wrote:
> -static struct rte_tailq_elem rte_mempool_tailq = {
> +struct rte_tailq_elem rte_mempool_tailq = {
Why removing static? I didn't see it's referenced somewhere else.
> + if (flags && MEMPOOL_F_INT_HANDLER) {
I would assume it's "flags & MEMPOOL_F_INT_HANDLER". BTW, you might want
to do a thorough check, as I found few more typos like this.
--yliu
> + if (flags && MEMPOOL_F_INT_HANDLER) {
> +
> + if (rte_eal_has_hugepages()) {
> + startaddr = (void *)mz->addr;
> + } else {
> + /* align memory pool start address on a page boundary */
> + unsigned long addr = (unsigned long)mz->addr;
> +
> + if (addr & (page_size - 1)) {
> + addr += page_size;
> + addr &= ~(page_size - 1);
> + }
> + startaddr = (void *)addr;
> }
> - startaddr = (void*)addr;
> + } else {
> + startaddr = (void *)mz->addr;
> }
[dpdk-dev] [dpdk-announce] DPDK 16.04 released
The freshest April fish is there: http://dpdk.org/browse/dpdk/tag/?id=v16.04 The statistics are stable: 704 patches from 102 authors 657 files changed, 60233 insertions(+), 17157 deletions(-) There are 50 new contributors (including authors, reviewers and testers): Thanks to Alexander Matushevsky, Antonio Fischetti, Arek Kusztal, Beilei Xing, Charles Williams, Chintu Hetam, David Verbeiren, Dawid Jurczak, Deepak Kumar Jain, Dror Birkman, Eric Kinzie, Evgeny Schemeilin, Gerald Rogers, Hannes Frederic Sowa, Ilya Maximets, Jakub Palider, Jan Medala, Jerry Zhang, Jiangu Zhao, Kamil Rytarowski, Kyle Larose, Lazaros Koromilas, Liming Sun, Maciej Czekaj, Marcel Cornu, Markos Chandras, Michael Frasca, Michal Kobylinski, Mike Stolarchuk, Nachiketa Prachanda, Nelson Escobar, Netanel Belgazal, Pavel Fedin, Ralf Hoffmann, Rami Rosen, Raslan Darawsheh, Santosh Shukla, Sean Harte, Seth Arnold, Slawomir Mrozowicz, Steeven Lee, Thibaut Collet, Tomasz Kantecki, Vladyslav Buslov, Wojciech Andralojc, Wojciech Zmuda, Yi Lu, Yoann Desmouceaux, Yury Kylulin, Ziye Yang. These new contributors are associated with these domain names: 6wind.com, allegro-packets.com, amazon.com, arraynetworks.com.cn, asaltech.com, bigswitch.com, brocade.com, canonical.com, caviumnetworks.com, cesnet.cz, cisco.com, ezchip.com, gmail.com, harmonicinc.com, intel.com, lightcyber.com, live.com, mvista.com, nofutznetworks.com, oracle.com, samsung.com, sandvine.com, semihalf.com, stressinduktion.org, suse.de, vp.pl. Some highlights since 2.2.0: * virtio for ARM * new ena driver * new crypto drivers * stable crypto API More details in the release notes: http://dpdk.org/doc/guides/rel_notes/release_16_04.html It is now time to prepare the next promising stuff: http://dpdk.org/dev/roadmap The new features for the 16.07 cycle must be submitted before 8th of May. The features properly reviewed and approved before June 16 will be part of the summer release. Enjoy spring flowers!
[dpdk-dev] [PATCH] lib: fix DCB config issue on ixgbe
Hi Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, April 11, 2016 5:52 PM > To: Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] lib: fix DCB config issue on ixgbe > > 2016-04-11 16:24, Wenzhuo Lu: > > An issue is found that DCB cannot be configged on ixgbe NICs. It's > > said the TX queue number is not right. > > On ixgbe the max TX queue number is not fixed, it depends on the > > multi-queue mode. The API rte_eth_dev_configure should be used to > > config this mode. But the input of this API includes TX queue number. > > The problem is before the mode is configged, we cannot decide the TX > > queue number. > > > > This patch adds an API to config RX & TX multi-queue mode separately. > > After the mode is configged, the max RX & TX queue number is decided. > > Then we can set the appropriate RX & TX queue number. > > > > Fixes: 96c0450dff86 (ixgbe: fix dropping packets from unsupported Tx > > queues) > > Signed-off-by: Wenzhuo Lu > > --- > > app/test-pmd/testpmd.c | 40 > > +++--- > > lib/librte_ether/rte_ethdev.c | 17 +++ > > lib/librte_ether/rte_ethdev.h | 19 > > lib/librte_ether/rte_ether_version.map | 1 + > > 4 files changed, 59 insertions(+), 18 deletions(-) > > Obviously, it will be considered for 16.07. OK. I've got some feedback from the users that DCB is working, so I think it's not a critical issue and maybe only testpmd is impacted. I'll send a new version later. As rte_ether_version.map should be change for 16.07. Thanks.
[dpdk-dev] dev stop and buffer releases
Team, Hit a crash while vmxnet_xmit_pkts()-->vmxnet3_tq_tx_complete() API trying to release completed buffers. As we see in the code, there are two independent paths that clean up completed buffers: 1) vmxnet3_xmit_pkts 2) vmxnet3_dev_stop. In a multi-threaded environment potentially this can cause issues since queues/buffers not guarded with any locks. Specifically, in my case, one thread handles admin messages like port shut and hence triggers vmxnet3_dev_stop. Another thread for forwarding (vmxnet3_xmit_pkts). Isn't this a candidate for introducing locks within drivers? Any other suggestions to handle it? Thanks, -Vithal
[dpdk-dev] Reg: promiscuous mode on VF
Hi Greg, Thanks for your response. I am using the old kernel (2.6.32-573.22.1.el6.x86_64). First I have to update the kernel to version-3.18.4 and will try what you have specified. I will keep you posted with the outcomes. Thanks, Bharath On Sat, Apr 9, 2016 at 2:36 AM, Rose, Gregory V wrote: > Bharath, > > > > Please try the following: > > > > In this example we are directing the traffic to queue 1 of VF ID 5. First > you must turn on ntuple. > > > > $ ethtool ?K p5p2 ntuple on > > > > Then you can set the FD rule: > > > > $ ethtool ?N p5p2 flow-type udp4 dst-port 4790 action 1 user-def 5 > > > > When I do that this is the rule definition result: > > > > Filter: 2045 > > Rule Type: UDP over IPv4 > > Src IP addr: 0.0.0.0 mask: 255.255.255.255 > > Dest IP addr: 0.0.0.0 mask: 255.255.255.255 > > TOS: 0x0 mask: 0xff > > Src port: 0 mask: 0x > > Dest port: 4790 mask: 0x0 > > VLAN EtherType: 0x0 mask: 0x > > VLAN: 0x0 mask: 0x > > User-defined: 0x5 mask: 0xff00 > > Action: Direct to queue 1 > > > > Be sure to use a version of ethtool 3.0 or greater and a recent kernel ? I > tested on ethtool version 3.15 with a 3.18.4 Linux kernel from kernel.org > and using the most recent ixgbe driver release. > > > > Let me know if this works for you. > > > > Thanks, > > > > - Greg > > > > *From:* Rose, Gregory V > *Sent:* Thursday, April 7, 2016 4:43 PM > *To:* bharath paulraj ; Qiu, Michael < > michael.qiu at intel.com> > *Cc:* Zhang, Helin ; Lu, Wenzhuo < > wenzhuo.lu at intel.com>; Rowden, Aaron F ; > dev at dpdk.org; Jayakumar, Muthurajan > > *Subject:* RE: [dpdk-dev] Reg: promiscuous mode on VF > > > > Bharath, > > > > I?m sorry for the delay but I am working on a response to this. There is > a way to do what you need to do and I will get together some instructions > and respond by tomorrow. > > > > Thanks and regards, > > > > - Greg > > > > *From:* bharath paulraj [mailto:bharathpaul at gmail.com > ] > *Sent:* Thursday, April 7, 2016 3:40 AM > *To:* Qiu, Michael > *Cc:* Rose, Gregory V ; Zhang, Helin < > helin.zhang at intel.com>; Lu, Wenzhuo ; Rowden, > Aaron > F ; dev at dpdk.org; Jayakumar, Muthurajan < > muthurajan.jayakumar at intel.com> > *Subject:* Re: [dpdk-dev] Reg: promiscuous mode on VF > > > > Hi Team, > > > > May I have some update on my previous mail? I am here stuck in flow > creation. > > > > Thanks, > > Bharath > > > > On Thu, Mar 31, 2016 at 4:13 PM, bharath paulraj > wrote: > > Hi Michael and All, > > > I am unable to set the rule to receive the packet on the VF. > Below is my setup. > > 1. Creating one virtual function with one queue, in one of my port, p2p1. > *modprobe ixgbe MQ=1 max_vfs=1 RSS=1 allow_unsupported_sfp=1 * > 2. Below is the interface status after creating one virtual function. > [root at sriov]# ifconfig p2p1 > p2p1 Link encap:Ethernet HWaddr A0:36:9F:86:C2:74 > inet6 addr: fe80::a236:9fff:fe86:c274/64 Scope:Link > UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 > RX packets:2540 errors:0 dropped:0 overruns:0 frame:0 > TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:157456 (153.7 KiB) TX bytes:258 (258.0 b) > > [root at sriov]# ifconfig p2p1_0 > p2p1_0Link encap:Ethernet HWaddr DA:61:95:CD:AF:35 > inet6 addr: fe80::d861:95ff:fecd:af35/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:12 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:360 (360.0 b) TX bytes:740 (740.0 b) > 3. Next I am enable ntuple > *ethtool -K p2p1 ntuple on * > 4. Now I am adding below rule > > *ethtool -N p2p1 flow-type udp4 dst-port 4789 action 0x1 --> VF > 0, queue 0 ethtool -N p2p1 flow-type udp4 dst-port 4790 action > 0x0 --> PF queue 0 * > 5. [root at XXX sriov]# ethtool -n p2p1 > 1 RX rings available > Total 2 rules > > Filter: 2044 > Rule Type: UDP over IPv4 > Src IP addr: 0.0.0.0 mask: 255.255.255.255 > Dest IP addr: 0.0.0.0 mask: 255.255.255.255 > TOS: 0x0 mask: 0xff > Src port: 0 mask: 0x > Dest port: 4790 mask: 0x0 > VLAN EtherType: 0x0 mask: 0x > VLAN: 0x0 mask: 0x > User-defined: 0x0 mask: 0x > Action: Direct to queue 0 > > Filter: 2045 > Rule Type: UDP over IPv4 > Src IP addr: 0.0.0.0 mask: 255.255.255.255 > Dest IP addr: 0.0.0.0 mask: 255.255.255.255 > TOS: 0x0 mask: 0xff > Src port: 0 mask: 0x > Dest port: 4789 mask: 0x0 > VLAN EtherType: 0x0 mask: 0x > VLAN: 0x0 mask: 0x > User-defined: 0x0 mask: 0x > Action: Direct to queue
[dpdk-dev] Pktgen rate issue
Hello I have been using pktgen for a while and I released that there is no possibility to set a rate between two whole numbers. I looked up the source code and I found out that the rate is stored in a uint8_t. So, I made a quick-and-dirty change just to check if it is possible to get a speed between two hole numbers. It seemed to work properly. Is there a reason to use an uint8_t instead of a float, for example? Thank you, I?aki Murillo
[dpdk-dev] [PATCH] l2fwd-crypto: fix supported key size check
When initializing crypto devices within the app,
the provided key sizes are checked against the supported
sizes from the crypto device capabilities.
When the supported sizes are not a range, but a single value,
the check may become an infinite loop (when size is not supported).
Fixes: a061e50a0d97 ("examples/l2fwd-crypto: fix ambiguous input key size")
Signed-off-by: Pablo de Lara
---
examples/l2fwd-crypto/main.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index d4e2d8d..e273f2f 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1486,6 +1486,15 @@ check_supported_size(uint16_t length, uint16_t min,
uint16_t max,
{
uint16_t supp_size;
+ /* Single value */
+ if (increment == 0) {
+ if (length == min)
+ return 0;
+ else
+ return -1;
+ }
+
+ /* Range of values */
for (supp_size = min; supp_size <= max; supp_size += increment) {
if (length == supp_size)
return 0;
--
2.5.5
[dpdk-dev] AF_PACKET poll mode driver
Hi, We are facing a problem in DPDK - AF_PACKET poll mode driver. We are able to create RAW socket and receive RTP-Signaling packets successfully and our application is running fine. But if we try doing scp to the same interface we are facing a crash. The stack trace: (gdb) bt #0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:1644 #1 0x0059053e in eth_af_packet_rx (queue=0x7f6b2936c060, bufs=0x7f6b27df16e0, nb_pkts=32) at /software/src/cmn_thirdparty/Intel/DPDK/2.1/blddir/dpdk-2.1.0/drivers/net/af_packet/rte_eth_af_packet.c:186 #2 0x004330aa in rte_eth_rx_burst (queue_id=0, nb_pkts=32, rx_pkts=0x7f6b27df16e0, port_id=0 '\000') at /software/src/cmn_thirdparty/Intel/DPDK/2.1/blddir/dpdk-2.1.0//x86_64-native-linuxapp-gcc/include/rte_ethdev.h:2629 #3 drain_mgt_pkts (tim=, arg=) at bp.c:1157 #4 0x004a33d4 in rte_timer_manage () #5 0x00433953 in handle_timers () at bp.c:1101 #6 packet_capture_loop () at bp.c:1265 #7 0x00434149 in ssbc_pkt_capture_launch_one_lcore (dummy=) at bp.c:1502 #8 0x004d2755 in eal_thread_loop () #9 0x7f6ba9c06b50 in start_thread (arg=) at pthread_create.c:304 #10 0x7f6ba995095d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x in ?? () (gdb) bt full #0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:1644 No locals. #1 0x0059053e in eth_af_packet_rx (queue=0x7f6b2936c060, bufs=0x7f6b27df16e0, nb_pkts=32) at /software/src/cmn_thirdparty/Intel/DPDK/2.1/blddir/dpdk-2.1.0/drivers/net/af_packet/rte_eth_af_packet.c:186 ethVlan = 0x7f6ba3e550c0 i = 7 ppd = 0x7f6ba9410800 mbuf = 0x7f6ba3e55840 pbuf = 0x7f6ba9410842 pkt_q = 0x7f6b2936c060 num_rx = 7 framecount = 512 framenum = 291 #2 0x004330aa in rte_eth_rx_burst (queue_id=0, nb_pkts=32, rx_pkts=0x7f6b27df16e0, port_id=0 '\000') at /software/src/cmn_thirdparty/Intel/DPDK/2.1/blddir/dpdk-2.1.0//x86_64-native-linuxapp-gcc/include/rte_ethdev.h:2629 temp = internal_af = dev = 0x8448ee0 nb_rx = 0 cb = Please help us out regarding this issue. I will provide more information if you require any in reproducing the issue. Thanks, Ganapati Hegde
[dpdk-dev] [PATCH v1] doc: add template release notes for 16.11
Added template release notes for DPDK 16.11 with inline explanations of the various sections. Signed-off-by: John McNamara --- doc/guides/rel_notes/index.rst | 1 + doc/guides/rel_notes/release_16_11.rst | 160 + 2 files changed, 161 insertions(+) create mode 100644 doc/guides/rel_notes/release_16_11.rst diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst index 84317b8..b38a58c 100644 --- a/doc/guides/rel_notes/index.rst +++ b/doc/guides/rel_notes/index.rst @@ -36,6 +36,7 @@ Release Notes :numbered: rel_description +release_16_11 release_16_04 release_2_2 release_2_1 diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst new file mode 100644 index 000..1b2ca1b --- /dev/null +++ b/doc/guides/rel_notes/release_16_11.rst @@ -0,0 +1,160 @@ +DPDK Release 16.11 +== + +**Read this first.** + +The text below explains how to update the release notes. + +Use proper spelling, capitalization and punctuation in all sections. + +Variable and config names should be quoted as fixed width text: ``LIKE_THIS``. + +Build the docs and view the output file to ensure the changes are correct:: + + make doc-guides-html + + firefox build/doc/html/guides/rel_notes/release_16_04.html + + +New Features + + +This section should contain new features added in this release. Sample format: + +* **Add a title in the past tense with a full stop.** + + Add a short 1-2 sentence description in the past tense. The description + should be enough to allow someone scanning the release notes to understand + the new feature. + + If the feature adds a lot of sub-features you can use a bullet list like this. + + * Added feature foo to do something. + * Enhanced feature bar to do something else. + + Refer to the previous release notes for examples. + + +Resolved Issues +--- + +This section should contain bug fixes added to the relevant sections. Sample format: + +* **code/section Fixed issue in the past tense with a full stop.** + + Add a short 1-2 sentence description of the resolved issue in the past tense. + The title should contain the code/lib section like a commit message. + Add the entries in alphabetic order in the relevant sections below. + + +EAL +~~~ + + +Drivers +~~~ + + +Libraries +~ + + +Examples + + + +Other +~ + + +Known Issues + + +This section should contain new known issues in this release. Sample format: + +* **Add title in present tense with full stop.** + + Add a short 1-2 sentence description of the known issue in the present + tense. Add information on any known workarounds. + + +API Changes +--- + +This section should contain API changes. Sample format: + +* Add a short 1-2 sentence description of the API change. Use fixed width + quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past tense. + + +ABI Changes +--- + +* Add a short 1-2 sentence description of the ABI change that was announced in + the previous releases and made in this release. Use fixed width quotes for + ``rte_function_names`` or ``rte_struct_names``. Use the past tense. + + +Shared Library Versions +--- + +Update any library version updated in this release and prepend with a ``+`` sign. + +The libraries prepended with a plus sign were incremented in this version. + +.. code-block:: diff + + libethdev.so.3 + librte_acl.so.2 + librte_cfgfile.so.2 + librte_cmdline.so.2 + librte_distributor.so.1 + librte_eal.so.2 + librte_hash.so.2 + librte_ip_frag.so.1 + librte_ivshmem.so.1 + librte_jobstats.so.1 + librte_kni.so.2 + librte_kvargs.so.1 + librte_lpm.so.2 + librte_mbuf.so.2 + librte_mempool.so.1 + librte_meter.so.1 + librte_pipeline.so.3 + librte_pmd_bond.so.1 + librte_pmd_ring.so.2 + librte_port.so.2 + librte_power.so.1 + librte_reorder.so.1 + librte_ring.so.1 + librte_sched.so.1 + librte_table.so.2 + librte_timer.so.1 + librte_vhost.so.2 + + +Tested Platforms + + +This section should contain a list of platforms that were tested with this +release. + +The format is: + +#. Platform name. + + - Platform details. + - Platform details. + + +Tested NICs +--- + +This section should contain a list of NICs that were tested with this release. + +The format is: + +#. NIC name. + + - NIC details. + - NIC details. -- 2.5.0
[dpdk-dev] librte_table build race with SYMLINK-FILE?
On 2016-04-11 20:53, Thomas Monjalon wrote: > 2016-04-11 11:15, Stephen Hemminger: >> On Mon, 11 Apr 2016 12:46:16 +0200 >> Simon K?gstr?m wrote: >>> In file included from [...]lib/librte_table/rte_table_lpm.c:43:0: >>> [...]/dpdk.build/include/rte_lpm.h:484:25: fatal error: rte_lpm_sse.h: >>> No such file or directory >>> #include "rte_lpm_sse.h" >> >> The issue is a missing dependency in the mk file for LPM. > > There is already this line: > DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_lpm Sorry, this whole issue might have been caused by my old configuration being carried over to 16.04. I'll let you know if I run into it again! // Simon
[dpdk-dev] [PATCH v1] doc: add template release notes for 16.11
2016-04-12 13:01, John McNamara: > Added template release notes for DPDK 16.11 with inline > explanations of the various sections. Excellent, thanks. Would you mind to also initialize the release notes for 16.07? ;)
[dpdk-dev] [PATCH] doc: announce ABI change for rte_port_source_params structure
Hi Fan Zhang, 2016-04-07 23:24, Thomas Monjalon: > Please send a patch to remove NEXT_ABI early in the 16.07 cycle. Please could you prepare a patch to remove NEXT_ABI from rte_port? Thanks
[dpdk-dev] [PATCH v1] doc: add template release notes for 16.11
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, April 12, 2016 1:12 PM > To: Mcnamara, John > Cc: dev at dpdk.org > Subject: Re: [PATCH v1] doc: add template release notes for 16.11 > > 2016-04-12 13:01, John McNamara: > > Added template release notes for DPDK 16.11 with inline explanations > > of the various sections. > > Excellent, thanks. > Would you mind to also initialize the release notes for 16.07? ;) Whoops. ENOCOFFEE error. :-/
[dpdk-dev] [PATCH v1] doc: add template release notes for 16.07
Added template release notes for DPDK 16.07 with inline explanations of the various sections. Signed-off-by: John McNamara --- doc/guides/rel_notes/index.rst | 1 + doc/guides/rel_notes/release_16_07.rst | 160 + 2 files changed, 161 insertions(+) create mode 100644 doc/guides/rel_notes/release_16_07.rst diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst index 84317b8..52c63b4 100644 --- a/doc/guides/rel_notes/index.rst +++ b/doc/guides/rel_notes/index.rst @@ -36,6 +36,7 @@ Release Notes :numbered: rel_description +release_16_07 release_16_04 release_2_2 release_2_1 diff --git a/doc/guides/rel_notes/release_16_07.rst b/doc/guides/rel_notes/release_16_07.rst new file mode 100644 index 000..701e827 --- /dev/null +++ b/doc/guides/rel_notes/release_16_07.rst @@ -0,0 +1,160 @@ +DPDK Release 16.07 +== + +**Read this first.** + +The text below explains how to update the release notes. + +Use proper spelling, capitalization and punctuation in all sections. + +Variable and config names should be quoted as fixed width text: ``LIKE_THIS``. + +Build the docs and view the output file to ensure the changes are correct:: + + make doc-guides-html + + firefox build/doc/html/guides/rel_notes/release_16_07.html + + +New Features + + +This section should contain new features added in this release. Sample format: + +* **Add a title in the past tense with a full stop.** + + Add a short 1-2 sentence description in the past tense. The description + should be enough to allow someone scanning the release notes to understand + the new feature. + + If the feature adds a lot of sub-features you can use a bullet list like this. + + * Added feature foo to do something. + * Enhanced feature bar to do something else. + + Refer to the previous release notes for examples. + + +Resolved Issues +--- + +This section should contain bug fixes added to the relevant sections. Sample format: + +* **code/section Fixed issue in the past tense with a full stop.** + + Add a short 1-2 sentence description of the resolved issue in the past tense. + The title should contain the code/lib section like a commit message. + Add the entries in alphabetic order in the relevant sections below. + + +EAL +~~~ + + +Drivers +~~~ + + +Libraries +~ + + +Examples + + + +Other +~ + + +Known Issues + + +This section should contain new known issues in this release. Sample format: + +* **Add title in present tense with full stop.** + + Add a short 1-2 sentence description of the known issue in the present + tense. Add information on any known workarounds. + + +API Changes +--- + +This section should contain API changes. Sample format: + +* Add a short 1-2 sentence description of the API change. Use fixed width + quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past tense. + + +ABI Changes +--- + +* Add a short 1-2 sentence description of the ABI change that was announced in + the previous releases and made in this release. Use fixed width quotes for + ``rte_function_names`` or ``rte_struct_names``. Use the past tense. + + +Shared Library Versions +--- + +Update any library version updated in this release and prepend with a ``+`` sign. + +The libraries prepended with a plus sign were incremented in this version. + +.. code-block:: diff + + libethdev.so.3 + librte_acl.so.2 + librte_cfgfile.so.2 + librte_cmdline.so.2 + librte_distributor.so.1 + librte_eal.so.2 + librte_hash.so.2 + librte_ip_frag.so.1 + librte_ivshmem.so.1 + librte_jobstats.so.1 + librte_kni.so.2 + librte_kvargs.so.1 + librte_lpm.so.2 + librte_mbuf.so.2 + librte_mempool.so.1 + librte_meter.so.1 + librte_pipeline.so.3 + librte_pmd_bond.so.1 + librte_pmd_ring.so.2 + librte_port.so.2 + librte_power.so.1 + librte_reorder.so.1 + librte_ring.so.1 + librte_sched.so.1 + librte_table.so.2 + librte_timer.so.1 + librte_vhost.so.2 + + +Tested Platforms + + +This section should contain a list of platforms that were tested with this +release. + +The format is: + +#. Platform name. + + - Platform details. + - Platform details. + + +Tested NICs +--- + +This section should contain a list of NICs that were tested with this release. + +The format is: + +#. NIC name. + + - NIC details. + - NIC details. -- 2.5.0
[dpdk-dev] Pktgen rate issue
>Hello > >I have been using pktgen for a while and I released that there is no >possibility to set a rate between two whole numbers. > > I looked up the source code and I found out that the rate is stored in >a uint8_t. So, I made a quick-and-dirty change just to check if it is >possible to get a speed between two hole numbers. It seemed to work >properly. > > Is there a reason to use an uint8_t instead of a float, for example? The uint8_t was easier then using floats :-) If you have a patch for this change please send it along and I will look at adding the support. > >Thank you, > >I?aki Murillo > Regards, Keith
[dpdk-dev] [PATCH] lpm: fix freeing of rules_tbl in rte_lpm_free_v20
Back then when we fixed the missing free lpm I was to quickly to say yes
if it applies not only to the lpm6 but also to all of the lpm code.
It turned out to not apply to all of them. In rte_lpm_create_v20 there
is an unexpected fused allocation:
mem_size = sizeof(*lpm) + (sizeof(lpm->rules_tbl[0]) * max_rules);
[...]
lpm = (struct rte_lpm_v20 *)rte_zmalloc_socket(mem_name,mem_size,
RTE_CACHE_LINE_SIZE, socket_id);
That causes lpm->rules_tbl not to have an own struct malloc_elem that
can be derived via RTE_PTR_SUB(data, MALLOC_ELEM_HEADER_LEN) in
malloc_elem_from_data.
Due to that the rte_lpm_free_v20 accidentially misderives the elem and
assumes it is ELEM_FREE triggering in malloc_elem_free
if (!malloc_elem_cookies_ok(elem) || elem->state !=
return -1;
While it seems counter-intuitive the way to properly remove rules_tbl in
the old fused allocation style of rte_lpm_free_v20 is to not remove it.
The newer rte_lpm_free_v1604 is safe because in rte_lpm_create_v1604
rules_tbl is a separate allocation.
Fixes: d4c18f0a1d5d ("lpm: fix missing free")
Signed-off-by: Christian Ehrhardt
---
lib/librte_lpm/rte_lpm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index 8bdf606..6f65d1c 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -373,7 +373,6 @@ rte_lpm_free_v20(struct rte_lpm_v20 *lpm)
rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
- rte_free(lpm->rules_tbl);
rte_free(lpm);
rte_free(te);
}
--
2.7.4
[dpdk-dev] [PATCH] lpm: fix freeing of rules_tbl in rte_lpm_free_v20
Hi,
On 04/12/2016 03:49 PM, Christian Ehrhardt wrote:
> Back then when we fixed the missing free lpm I was to quickly to say yes
> if it applies not only to the lpm6 but also to all of the lpm code.
>
> It turned out to not apply to all of them. In rte_lpm_create_v20 there
> is an unexpected fused allocation:
> mem_size = sizeof(*lpm) + (sizeof(lpm->rules_tbl[0]) * max_rules);
> [...]
> lpm = (struct rte_lpm_v20 *)rte_zmalloc_socket(mem_name,mem_size,
> RTE_CACHE_LINE_SIZE, socket_id);
>
> That causes lpm->rules_tbl not to have an own struct malloc_elem that
> can be derived via RTE_PTR_SUB(data, MALLOC_ELEM_HEADER_LEN) in
> malloc_elem_from_data.
> Due to that the rte_lpm_free_v20 accidentially misderives the elem and
> assumes it is ELEM_FREE triggering in malloc_elem_free
> if (!malloc_elem_cookies_ok(elem) || elem->state !=
> return -1;
>
> While it seems counter-intuitive the way to properly remove rules_tbl in
> the old fused allocation style of rte_lpm_free_v20 is to not remove it.
>
> The newer rte_lpm_free_v1604 is safe because in rte_lpm_create_v1604
> rules_tbl is a separate allocation.
>
> Fixes: d4c18f0a1d5d ("lpm: fix missing free")
>
> Signed-off-by: Christian Ehrhardt
Acked-by: Olivier Matz
Thanks, I missed it too during the review.
[dpdk-dev] [PATCH] examples/vm_power_manager: buffer not null terminated
CID30691:
If the buffer is treated as a null terminated string in later operations,
a buffer overflow or over-read may occur.
In add_vm: The string buffer may not have a null terminator if the source
string's length is equal to the buffer size
Fixes: e8ae9b662506 ("examples/vm_power: channel manager and monitor in host")
Signed-off-by: Daniel Mrzyglod
---
examples/vm_power_manager/channel_manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/examples/vm_power_manager/channel_manager.c
b/examples/vm_power_manager/channel_manager.c
index 22c2ddd..b9265ce 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -666,7 +666,8 @@ add_vm(const char *vm_name)
rte_free(new_domain);
return -1;
}
- strncpy(new_domain->name, vm_name, sizeof(new_domain->name));
+ strncat(new_domain->name, vm_name, sizeof(new_domain->name) -
+ strlen(new_domain->name) - 1);
new_domain->channel_mask = 0;
new_domain->num_channels = 0;
--
2.5.5
[dpdk-dev] [PATCH 4/4] port: fix ethdev writer burst too big
> -Original Message- > From: Sanford, Robert [mailto:rsanford at akamai.com] > Sent: Monday, April 11, 2016 9:37 PM > To: Dumitrescu, Cristian ; dev at dpdk.org > Cc: Liang, Cunming ; Venkatesan, Venky > ; Richardson, Bruce > > Subject: Re: [dpdk-dev] [PATCH 4/4] port: fix ethdev writer burst too big > > Hi Cristian, > > Yes, I mostly agree with your suggestions: > 1. We should fix the two obvious bugs (1a and 1b) right away. Jasvinder's > patches look fine. > 2. We should take no immediate action on the issue I raised about PMDs > (vector IXGBE) not enqueuing more than 32 packets. We can discuss and > debate; no patch for 16.04, perhaps something in 16.07. > > > Let's start the discussion now, regarding vector IXGBE. You state > "Internally it handles packets in batches [of] 32 (as your code snippets > suggest), but there is no drop of excess packets taking place." I guess it > depends on your definition of "drop". If I pass 33 packets to > ixgbe_xmit_pkts_vec(), it will enqueue 32 packets, and return a value of > 32. Can we agree on that? > Yes, Steve Liang and I looked at the latest IXGBE vector code and it looks like you are right. The number of packets that get accepted is the minimum between number of packets provided by the user (33 in our case) and two thresholds, txq->tx_rs_thresh and txq->nb_tx_free, which are by default set to 32, which is the value that yields the best performance, hence only 32 packets get accepted. It also looks virtually impossible to change this behaviour of IXGBE vector driver. As an example, let's say 33 packets are presented by the user, IXGBE picks the first 32 and tries to send them, but only 17 make it, so the other 15 have to be returned back to the user; then there is the 33rd packet that is picked, and this packet makes it. Since return value is a number (not a mask), how do you tell the user that packets 0 .. 16 and 32 made it, while the packets 17 .. 31 in the middle of the burst did not make it? So the only real place to improve this is the port_ethdev_writer. I wonder whether there is nice way to combine existing behavior (burst treated as minimal requirement) with your proposal (burst treated as constant requirement) under the same code, and then pick between the two behaviors based on an input parameter provided when port is created? > -- > Regards, > Robert > > > On 4/11/16 3:21 PM, "Dumitrescu, Cristian" > wrote: > > >Hi Robert, > > > >I am doing a quick summary below on the changes proposed by these > patches: > > > >1. [PRIORITY 1] Bug fixing: > >a) Fix buffer overflow issue in rte_port_ring.c (writer, writer_nodrop): > >double the tx_buf buffer size (applicable for current code approach) > >b) Fix issue with handling burst sizes bigger than 32: replace all > >declarations of local variable bsz_size from uint32_t to uint64_t > > > >2. [PRIORITY 2] Treat burst size as a fixed/exact value for the TX burst > >(Approach 2) instead of minimal value (current code, Approach 1) for > >ethdev ports. Rationale is that some PMDs (like vector IXGBE) _might_ > >drop the excess packets in the burst. > > > >Additional input: > >1. Bruce and I looked together at the code, it looks that vector IXGBE is > >not doing this (anymore). Internally it handles packets in batches on 32 > >(as your code snippets suggest), but there is no drop of excess packets > >taking place. > > > >2. Venky also suggested to keep a larger burst as a single burst > >(Approach 1) rather than break the larger burst into a fixed/constant > >size burst while buffering the excess packets until complete burst is met > >in the future. > > > >Given this input and also the timing of the release, we think the best > >option is: > >- urgently send a quick patch to handle the bug fixes now > >- keep the existing code (burst size used as minimal burst size > >requirement, not constant) as is, at least for now, and if you feel it is > >not the best choice, we can continue to debate it for 16.7 release. > >What do you think? > > > >Jasvinder just send the bug fixing patches, hopefully they will make it > >into the 16.4 release: > >http://www.dpdk.org/ml/archives/dev/2016-April/037392.html > >http://www.dpdk.org/ml/archives/dev/2016-April/037393.html > > > >Many thanks for your work on this, Robert! > > > >Regards, > >Cristian
[dpdk-dev] [PATCH] vmxnet3: VLAN tag on end packet, not first
Signed-off-by: John Guzik
Fixes: 9fd5e98b
---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index 4ac0456..3d4a5eb 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -587,12 +587,6 @@ vmxnet3_post_rx_bufs(vmxnet3_rx_queue_t *rxq, uint8_t
ring_id)
static void
vmxnet3_rx_offload(const Vmxnet3_RxCompDesc *rcd, struct rte_mbuf *rxm)
{
- /* Check for hardware stripped VLAN tag */
- if (rcd->ts) {
- rxm->ol_flags |= PKT_RX_VLAN_PKT;
- rxm->vlan_tci = rte_le_to_cpu_16((uint16_t)rcd->tci);
- }
-
/* Check for RSS */
if (rcd->rssType != VMXNET3_RCD_RSS_TYPE_NONE) {
rxm->ol_flags |= PKT_RX_RSS_HASH;
@@ -737,7 +731,15 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf
**rx_pkts, uint16_t nb_pkts)
rxq->last_seg = rxm;
if (rcd->eop) {
- rx_pkts[nb_rx++] = rxq->start_seg;
+ struct rte_mbuf *start = rxq->start_seg;
+
+ /* Check for hardware stripped VLAN tag */
+ if (rcd->ts) {
+ start->ol_flags |= PKT_RX_VLAN_PKT;
+ start->vlan_tci =
rte_le_to_cpu_16((uint16_t)rcd->tci);
+ }
+
+ rx_pkts[nb_rx++] = start;
rxq->start_seg = NULL;
}
--
1.9.1
[dpdk-dev] Packet drops at lower tc transmit-rates.
Hi Cristian, Thanks for the response. > > Another potential workaround could be to change the pipe TC credit update > logic from straightforward re-initialization to a slightly more tuned > strategy that, in some cases, keeps some of the existing credits, so that the > existing credits are not completely lost but some of them (value capped to 1x > MTU) are carried forward: > > pipe->tc_credits[i] = (params->tc_credits_per_period[i] < MTU)? > ((pipe->tc_credits[i] % MTU) + > params->tc_credits_per_period[i]) : > params->tc_credits_per_period[i]; > > This would give the chance to the pipe TC credits to accumulate and become > greater than the MTU every few periods and a packet to be transmitted for > this pipe TC. Of course, this strategy needs to be further developed. This approach seemed to give the apparent rate closest to the configured rate, irrespective of the MTU, the packet size, or the min packet size. I?ll use the port->mtu to influence the tc_credits_per_period accumulation. Is there any particular reason why a token bucket was not used for traffic classes? Regards, Sridhar
[dpdk-dev] [4.4 kernel] kni lockup, kernel dump
Hi, I recently upgraded my debian/jessie to 4.4 kernel, and my application uses kni to create test interface, However, when doing 'rte_kni_alloc()', i observed the following log in syslog... If i go on trying setting interface via ifconfig, the execution locks up... [ 888.051427] BUG: unable to handle kernel paging request at 073b010bcb88 [ 888.051972] IP: [] kni_net_rx_normal+0x3a/0x290 [rte_kni] [ 888.052371] PGD 0 [ 888.052638] Oops: [#1] SMP [ 888.053041] Modules linked in: rte_kni(O) xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter ip_tables x_tables nf_nat nf_conntrack br_netfilter bridge stp llc dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c crc32c_generic loop dm_mod nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc crct10dif_pclmul crc32_pclmul jitterentropy_rng sha256_ssse3 sha256_generic hmac drbg ansi_cprng ppdev parport_pc i2c_piix4 aesni_intel aes_x86_64 parport acpi_cpufreq tpm_tis tpm lrw gf128mul glue_helper ablk_helper evdev cryptd 8250_fintek psmouse processor serio_raw video battery button ac pcspkr autofs4 ext4 crc16 mbcache jbd2 sg sd_mod ata_generic ahci crc32c_intel libahci ata_piix fjes libata [ 888.065118] e1000 scsi_mod [ 888.065476] CPU: 1 PID: 2226 Comm: kni_single Tainted: G O 4.4.0-0.bpo.1-amd64 #1 Debian 4.4.6-1~bpo8+1 [ 888.065861] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 888.066183] task: 88011ab9e0c0 ti: 8800b2fb8000 task.ti: 8800b2fb8000 [ 888.06] RIP: 0010:[] [] kni_net_rx_normal+0x3a/0x290 [rte_kni] [ 888.094268] RSP: 0018:8800b2fbbd40 EFLAGS: 00010246 [ 888.094879] RAX: 8800da073000 RBX: 8800d88bc2f8 RCX: [ 888.095392] RDX: 073b010bcb80 RSI: 0282 RDI: 8800da073840 [ 888.095929] RBP: 03e8 R08: 8800b2fb8000 R09: 00cec3fd1e2c [ 888.096425] R10: 0002 R11: R12: 8800d88bc2c0 [ 888.096913] R13: 8800d88bc2d0 R14: 8800da073840 R15: 8800da073840 [ 888.097382] FS: () GS:88011fc8() knlGS: [ 888.098052] CS: 0010 DS: ES: CR0: 8005003b [ 888.098490] CR2: 073b010bcb88 CR3: 00044000 CR4: 000406e0 [ 888.098958] Stack: [ 888.099294] 8800b2fb8000 88011fc95d80 88011ab9e0c0 [ 888.100428] 810bc311 0002 00cec3fd1e2c [ 888.101629] 8800b2fb8000 88011fc8df80 0282 0001 [ 888.103134] Call Trace: [ 888.103607] [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [ 888.104553] [] ? try_to_del_timer_sync+0x59/0x80 [ 888.105290] [] ? del_timer_sync+0x44/0x50 [ 888.105722] [] ? schedule_timeout+0x169/0x2d0 [ 888.106159] [] ? trace_event_raw_event_tick_stop+0x100/0x100 [ 888.106816] [] ? kni_thread_single+0x4c/0xa0 [rte_kni] [ 888.107279] [] ? kni_init_net+0x50/0x50 [rte_kni] [ 888.107754] [] ? kthread+0xdf/0x100 [ 888.108177] [] ? kthread_park+0x50/0x50 [ 888.108600] [] ? ret_from_fork+0x3f/0x70 [ 888.109026] [] ? kthread_park+0x50/0x50 [ 888.109448] Code: 54 55 53 48 81 ec 28 01 00 00 48 8b 97 78 01 00 00 65 48 8b 04 25 28 00 00 00 48 89 84 24 20 01 00 00 31 c0 48 8b 87 48 01 00 00 <44> 8b 72 08 48 89 04 24 8b 42 04 8b 0a 41 83 ee 01 83 e8 01 29 [ 888.145305] RIP [] kni_net_rx_normal+0x3a/0x290 [rte_kni] [ 888.145904] RSP [ 888.146337] CR2: 073b010bcb88 [ 888.146705] ---[ end trace ef3848430517129b ]--- -- Alex Wang,
[dpdk-dev] [4.4 kernel] kni lockup, kernel dump
I tried compiling both dpdk-2.2 and dpdk-16.04, all have the issue, Thanks, On 12 April 2016 at 17:19, ALeX Wang wrote: > Hi, > > I recently upgraded my debian/jessie to 4.4 kernel, and my application > uses kni to > create test interface, > > However, when doing 'rte_kni_alloc()', i observed the following log in > syslog... > If i go on trying setting interface via ifconfig, the execution locks up... > > [ 888.051427] BUG: unable to handle kernel paging request at > 073b010bcb88 > [ 888.051972] IP: [] kni_net_rx_normal+0x3a/0x290 > [rte_kni] > [ 888.052371] PGD 0 > [ 888.052638] Oops: [#1] SMP > [ 888.053041] Modules linked in: rte_kni(O) xt_conntrack ipt_MASQUERADE > nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 > nf_nat_ipv4 xt_addrtype iptable_filter ip_tables x_tables nf_nat > nf_conntrack br_netfilter bridge stp llc dm_thin_pool dm_persistent_data > dm_bio_prison dm_bufio libcrc32c crc32c_generic loop dm_mod nfsd > auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc > crct10dif_pclmul crc32_pclmul jitterentropy_rng sha256_ssse3 sha256_generic > hmac drbg ansi_cprng ppdev parport_pc i2c_piix4 aesni_intel aes_x86_64 > parport acpi_cpufreq tpm_tis tpm lrw gf128mul glue_helper ablk_helper evdev > cryptd 8250_fintek psmouse processor serio_raw video battery button ac > pcspkr autofs4 ext4 crc16 mbcache jbd2 sg sd_mod ata_generic ahci > crc32c_intel libahci ata_piix fjes libata > [ 888.065118] e1000 scsi_mod > [ 888.065476] CPU: 1 PID: 2226 Comm: kni_single Tainted: G O > 4.4.0-0.bpo.1-amd64 #1 Debian 4.4.6-1~bpo8+1 > [ 888.065861] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS > VirtualBox 12/01/2006 > [ 888.066183] task: 88011ab9e0c0 ti: 8800b2fb8000 task.ti: > 8800b2fb8000 > [ 888.06] RIP: 0010:[] [] > kni_net_rx_normal+0x3a/0x290 [rte_kni] > [ 888.094268] RSP: 0018:8800b2fbbd40 EFLAGS: 00010246 > [ 888.094879] RAX: 8800da073000 RBX: 8800d88bc2f8 RCX: > > [ 888.095392] RDX: 073b010bcb80 RSI: 0282 RDI: > 8800da073840 > [ 888.095929] RBP: 03e8 R08: 8800b2fb8000 R09: > 00cec3fd1e2c > [ 888.096425] R10: 0002 R11: R12: > 8800d88bc2c0 > [ 888.096913] R13: 8800d88bc2d0 R14: 8800da073840 R15: > 8800da073840 > [ 888.097382] FS: () GS:88011fc8() > knlGS: > [ 888.098052] CS: 0010 DS: ES: CR0: 8005003b > [ 888.098490] CR2: 073b010bcb88 CR3: 00044000 CR4: > 000406e0 > [ 888.098958] Stack: > [ 888.099294] 8800b2fb8000 88011fc95d80 88011ab9e0c0 > > [ 888.100428] 810bc311 0002 > 00cec3fd1e2c > [ 888.101629] 8800b2fb8000 88011fc8df80 0282 > 0001 > [ 888.103134] Call Trace: > [ 888.103607] [] ? > __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 > [ 888.104553] [] ? try_to_del_timer_sync+0x59/0x80 > [ 888.105290] [] ? del_timer_sync+0x44/0x50 > [ 888.105722] [] ? schedule_timeout+0x169/0x2d0 > [ 888.106159] [] ? > trace_event_raw_event_tick_stop+0x100/0x100 > [ 888.106816] [] ? kni_thread_single+0x4c/0xa0 > [rte_kni] > [ 888.107279] [] ? kni_init_net+0x50/0x50 [rte_kni] > [ 888.107754] [] ? kthread+0xdf/0x100 > [ 888.108177] [] ? kthread_park+0x50/0x50 > [ 888.108600] [] ? ret_from_fork+0x3f/0x70 > [ 888.109026] [] ? kthread_park+0x50/0x50 > [ 888.109448] Code: 54 55 53 48 81 ec 28 01 00 00 48 8b 97 78 01 00 00 65 > 48 8b 04 25 28 00 00 00 48 89 84 24 20 01 00 00 31 c0 48 8b 87 48 01 00 00 > <44> 8b 72 08 48 89 04 24 8b 42 04 8b 0a 41 83 ee 01 83 e8 01 29 > [ 888.145305] RIP [] kni_net_rx_normal+0x3a/0x290 > [rte_kni] > [ 888.145904] RSP > [ 888.146337] CR2: 073b010bcb88 > [ 888.146705] ---[ end trace ef3848430517129b ]--- > > -- > Alex Wang, > > -- Alex Wang, Open vSwitch developer
