[dpdk-dev] [PATCHv8 0/6] Implement pmd hardware support exports
2016-06-30 08:45, Remy Horton:
> On 17/06/2016 19:46, Neil Horman wrote:
> > Hey all-
> > So heres attempt number 2 at a method for exporting PMD hardware support
> > information. As we discussed previously, the consensus seems to be that pmd
> > information should be:
> [..]
> > Signed-off-by: Neil Horman
> > Acked-by: Panu Matilainen
> > CC: Bruce Richardson
> > CC: Thomas Monjalon
> > CC: Stephen Hemminger
> > CC: Panu Matilainen
>
> Acked-by: Remy Horton
v8 applied
The only changes I did are to update new drivers introduced recently:
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -654,4 +654,6 @@ static struct rte_driver cryptodev_kasumi_pmd_drv = {
.uninit = cryptodev_kasumi_uninit
};
-PMD_REGISTER_DRIVER(cryptodev_kasumi_pmd_drv);
+PMD_REGISTER_DRIVER(cryptodev_kasumi_pmd_drv, kasumi);
+DRIVER_REGISTER_PARAM_STRING(kasumi, "max_nb_queue_pairs= "
+"max_nb_sessions= socket_id=");
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1046,4 +1046,5 @@ static struct rte_driver bnxt_pmd_drv = {
.init = bnxt_rte_pmd_init,
};
-PMD_REGISTER_DRIVER(bnxt_pmd_drv);
+PMD_REGISTER_DRIVER(bnxt_pmd_drv, bnxt);
+DRIVER_REGISTER_PCI_TABLE(bnxt, bnxt_pci_id_map);
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -1788,4 +1788,5 @@ static struct rte_driver rte_nicvf_driver = {
.init = rte_nicvf_pmd_init,
};
-PMD_REGISTER_DRIVER(rte_nicvf_driver);
+PMD_REGISTER_DRIVER(rte_nicvf_driver, thunderx_nicvf);
+DRIVER_REGISTER_PCI_TABLE(thunderx_nicvf, pci_id_nicvf_map);
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -437,4 +437,4 @@ static struct rte_driver virtio_user_driver = {
.uninit = virtio_user_pmd_devuninit,
};
-PMD_REGISTER_DRIVER(virtio_user_driver);
+PMD_REGISTER_DRIVER(virtio_user_driver, virtio_user);
[dpdk-dev] Question on rte_ring_dequeue_bulk()
I apologies, I should have checked it more carefully. * if behavior = RTE_RING_QUEUE_VARIABLE * - n: Actual number of objects dequeued. This function returns the "n" I was looking for. Thanks -Avinash From: Yeddula, Avinash Sent: Wednesday, July 06, 2016 6:39 PM To: dev at dpdk.org Subject: Question on rte_ring_dequeue_bulk() Hi All, * @param r * A pointer to the ring structure. * @param obj_table * A pointer to a table of void * pointers (objects) that will be filled. * @param n * The number of objects to dequeue from the ring to the obj_table. By looking at the code I understood that, if the ring has less than "n" objects, rte_ring_dequeue_bulk() readjusts the value "n" returns what ever is available. I have a requirement where I need to know the new value of "n" , if the api has returned less than what was requested. One way is to memset the "objects" and check for the non-zero values. I kind of, did not like this idea. Any better idea to get "n" ? 1. rte_ring_dequeue_bulk(my-ring, (void**) pkts, n) -- n is set to 32. 2. If the ring has less than 32 pkts, say 20, my understanding is that it returns 20 "pkt" ptrs. 3. How do I get the number "20" ? Hope my question was clear. Thanks -Avinash
[dpdk-dev] Question on rte_ring_dequeue_bulk()
Hi All, * @param r * A pointer to the ring structure. * @param obj_table * A pointer to a table of void * pointers (objects) that will be filled. * @param n * The number of objects to dequeue from the ring to the obj_table. By looking at the code I understood that, if the ring has less than "n" objects, rte_ring_dequeue_bulk() readjusts the value "n" returns what ever is available. I have a requirement where I need to know the new value of "n" , if the api has returned less than what was requested. One way is to memset the "objects" and check for the non-zero values. I kind of, did not like this idea. Any better idea to get "n" ? 1. rte_ring_dequeue_bulk(my-ring, (void**) pkts, n) -- n is set to 32. 2. If the ring has less than 32 pkts, say 20, my understanding is that it returns 20 "pkt" ptrs. 3. How do I get the number "20" ? Hope my question was clear. Thanks -Avinash
[dpdk-dev] [PATCH v2] Memory leak when adding/removing vhost_user ports
On Wed, Jul 06, 2016 at 02:24:57PM +0200, Christian Ehrhardt wrote: > Hi, > while checking for dpdk 16.07 what backports are accepted in the meantime so I > can drop them I found this particular discussion has been silently forgotten > by > all of us. Not really. As later I found that my patch was actually wrong (besides the issue you already found). I will revisit this issue thoroughly when get time, hopefully, next week. --yliu
[dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address.
On Wed, Jul 06, 2016 at 02:19:12PM +0300, Ilya Maximets wrote:
> On 01.07.2016 10:35, Yuanhan Liu wrote:
> > Hi,
> >
> > Sorry for the long delay.
> >
> > On Fri, May 20, 2016 at 03:50:04PM +0300, Ilya Maximets wrote:
> >> In current implementation guest application can reinitialize vrings
> >> by executing start after stop. In the same time host application
> >> can still poll virtqueue while device stopped in guest and it will
> >> crash with segmentation fault while vring reinitialization because
> >> of dereferencing of bad descriptor addresses.
> >
> > Yes, you are right that vring will be reinitialized after restart.
> > But even though, I don't see the reason it will cause a vhost crash,
> > since the reinitialization will reset all the vring memeory by 0:
> >
> > memset(vq->vq_ring_virt_mem, 0, vq->vq_ring_size);
> >
> > That means those bad descriptors will be skipped, safely, at vhost
> > side by:
> >
> > if (unlikely(desc->len < dev->vhost_hlen))
> > return -1;
> >
> >>
> >> OVS crash for example:
> >> <>
> >> [test-pmd inside guest VM]
> >>
> >>testpmd> port stop all
> >>Stopping ports...
> >>Checking link statuses...
> >>Port 0 Link Up - speed 1 Mbps - full-duplex
> >>Done
> >>testpmd> port config all rxq 2
> >>testpmd> port config all txq 2
> >>testpmd> port start all
> >>Configuring Port 0 (socket 0)
> >>Port 0: 52:54:00:CB:44:C8
> >>Checking link statuses...
> >>Port 0 Link Up - speed 1 Mbps - full-duplex
> >>Done
> >>
> >> [OVS on host]
> >>Program received signal SIGSEGV, Segmentation fault.
> >>rte_memcpy (n=2056, src=0xc, dst=0x7ff4d5247000) at rte_memcpy.h
> >
> > Interesting, so it bypasses the above check since desc->len is non-zero
> > while desc->addr is zero. The size (2056) also looks weird.
> >
> > Do you mind to check this issue a bit deeper, say why desc->addr is
> > zero, however, desc->len is not?
>
> OK. I checked this few more times.
Thanks!
> Actually, I see, that desc->addr is
> not zero. All desc memory looks like some rubbish:
>
> <-->
> (gdb)
> #3 copy_desc_to_mbuf (mbuf_pool=0x7fe9da9f4480, desc_idx=65363,
> m=0x7fe9db269400, vq=0x7fe9fff7bac0, dev=0x7fe9fff7cbc0)
> desc = 0x2aabc00ff530
> desc_addr = 0
> mbuf_offset = 0
> prev = 0x7fe9db269400
> nr_desc = 1
> desc_offset = 12
> cur = 0x7fe9db269400
> hdr = 0x0
> desc_avail = 1012591375
> mbuf_avail = 1526
> cpy_len = 1526
>
> (gdb) p *desc
> $2 = {addr = 8507655620301055744, len = 1012591387, flags = 3845, next =
> 48516}
>
> <-->
>
> And 'desc_addr' equals zero because 'gpa_to_vva' just can't map this huge
> address to host's.
>
> Scenario was the same. SIGSEGV received right after 'port start all'.
>
> Another thought:
>
> Actually, there is a race window between 'memset' in guest and reading
> of 'desc->len' and 'desc->addr' on host. So, it's possible to read non
> zero 'len' and zero 'addr' right after that.
That's also what I was thinking, that it should the only reason caused
such issue.
> But you're right, this case should be very rare.
Yes, it should be very rare. What troubles me is that seems you can
reproduce this issue very easily, that I doubt it's caused by this
rare race. The reason could be something else?
--yliu
[dpdk-dev] [PATCH v2 00/11] Fix build errors related to exported headers
2016-07-05 12:44, Adrien Mazarguil: > This patchset affects exported headers only, compilation problems are > addressed as follows: I prefer postponing the headers changes to the very first days of the 16.11 cycle.
[dpdk-dev] [PATCH v2 1/2] doc: live migration of VM with Virtio and VF
2016-07-06 17:01, Bernard Iremonger: > @@ -45,3 +45,4 @@ DPDK documentation > faq/index > rel_notes/index > contributing/index > + how_to/index 2 personal opinions: - I feel a directory "howto" (without underscore) would be nice. - The position in the index could be just after the faq.
[dpdk-dev] [PATCH v2 0/2] doc: live migration procedure
Hi Bernard, 2016-07-06 17:01, Bernard Iremonger: > This pachset set describes the procedure to Live migrate > a VM with Virtio and VF PMD's using the bonding PMD. [...] > doc/guides/how_to/img/lm_overview.svg | 666 +++ > doc/guides/how_to/index.rst| 38 ++ > doc/guides/how_to/lm_bond_virtio_sriov.rst | 693 > + > doc/guides/index.rst | 3 +- I'm surprised to see an howto appearing in the repository. My first reaction is: how hard will it be to maintain up-to-date? Otherwise I don't see any other reason to not accept it. It's eventually a good idea :) Opinion from others?
[dpdk-dev] [PATCH v9 0/7] export PMD infos
2016-07-05 16:08, Neil Horman: > On Mon, Jul 04, 2016 at 10:10:37PM +0200, Thomas Monjalon wrote: > > 2016-07-04 12:41, Neil Horman: > > > On Mon, Jul 04, 2016 at 03:10:14PM +0200, Thomas Monjalon wrote: > > > > Hi Neil, > > > > > > > > I don't really understand why you don't accept I contribute to this > > > > patchset. More details below. > > > > > > > I don't object to your contribution to this patchset. What I object to > > > is you > > > making changes contrary to what I just spent I don't even know how many > > > weeks > > > arguing with you and others about. Given your role as maintainer, it is > > > tantamout to a 'my way or the highway' position. > > > > Thank you for explaining your feeling so clearly. > > I'm sorry for any inconvenience or misunderstanding. > > I now understand that you prefer I make some patches separately after > > integrating your version. > > So I can send a v10 based on your v8 which only fixes compilation. > > Or you can do it yourself if you prefer. > > Then I'll send another series for the other changes. > > Deal? > > > You go ahead and do it, I'm done. I'm sorry of this answer. So I'll push the v8 to keep your work intact and will reconsider sending some additional patches for review later.
[dpdk-dev] [PATCH] net/enic: remove useless assert macro
The macro ENIC_ASSERT does the same thing as RTE_ASSERT,
thus it can be removed.
Signed-off-by: Thomas Monjalon
---
drivers/net/enic/enic.h | 12
drivers/net/enic/enic_rxtx.c | 2 +-
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 53fed0b..191e1a3 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -221,18 +221,6 @@ enic_ring_incr(uint32_t n_descriptors, uint32_t idx)
return idx;
}
-#if RTE_LOG_LEVEL >= RTE_LOG_DEBUG
-#define ENIC_ASSERT(cond) \
- do {\
- if (unlikely(!(cond))) {\
- rte_panic("line %d\tassert \"" #cond "\"" \
- "failed\n", __LINE__); \
- } \
- } while (0)
-#else
-#define ENIC_ASSERT(cond) do {} while (0)
-#endif
-
extern void enic_fdir_stats_get(struct enic *enic,
struct rte_eth_fdir_stats *stats);
extern int enic_fdir_add_fltr(struct enic *enic,
diff --git a/drivers/net/enic/enic_rxtx.c b/drivers/net/enic/enic_rxtx.c
index 5ac1d69..2f4a08c 100644
--- a/drivers/net/enic/enic_rxtx.c
+++ b/drivers/net/enic/enic_rxtx.c
@@ -400,7 +400,7 @@ static inline void enic_free_wq_bufs(struct vnic_wq *wq,
u16 completed_index)
buf = &wq->bufs[tail_idx];
m = (struct rte_mbuf *)(buf->mb);
if (likely(m->pool == pool)) {
- ENIC_ASSERT(nb_free < ENIC_MAX_WQ_DESCS);
+ RTE_ASSERT(nb_free < ENIC_MAX_WQ_DESCS);
free[nb_free++] = m;
} else {
rte_mempool_put_bulk(pool, (void *)free, nb_free);
--
2.7.0
[dpdk-dev] [PATCH] app/test: remove useless clock estimation
The function get_machclk_freq() in RED test can be replaced by
rte_get_timer_hz() which already estimates the clock frequency at EAL init.
Signed-off-by: Thomas Monjalon
---
app/test/test_red.c | 42 +-
1 file changed, 1 insertion(+), 41 deletions(-)
diff --git a/app/test/test_red.c b/app/test/test_red.c
index 2384c55..7d1c32c 100644
--- a/app/test/test_red.c
+++ b/app/test/test_red.c
@@ -274,46 +274,6 @@ static int check_avg(double *diff, double avg, double
exp_avg, double tolerance)
}
/**
- * get the clk frequency in Hz
- */
-static uint64_t get_machclk_freq(void)
-{
- uint64_t start = 0;
- uint64_t end = 0;
- uint64_t diff = 0;
- static uint64_t clk_freq_hz;
- struct timespec tv_start = {0, 0}, tv_end = {0, 0};
- struct timespec req = {0, 0};
-
- if (clk_freq_hz != 0)
- return clk_freq_hz;
-
- req.tv_sec = 0;
- req.tv_nsec = NSEC_PER_SEC / 4;
-
- clock_gettime(CLOCK_REALTIME, &tv_start);
- start = rte_rdtsc();
-
- if (nanosleep(&req, NULL) != 0) {
- perror("get_machclk_freq()");
- exit(EXIT_FAILURE);
- }
-
- clock_gettime(CLOCK_REALTIME, &tv_end);
- end = rte_rdtsc();
-
- diff = (uint64_t)(tv_end.tv_sec - tv_start.tv_sec) * USEC_PER_SEC
- + ((tv_end.tv_nsec - tv_start.tv_nsec + TEST_NSEC_MARGIN) /
- USEC_PER_MSEC); /**< diff is in micro secs */
-
- if (diff == 0)
- return 0;
-
- clk_freq_hz = ((end - start) * USEC_PER_SEC / diff);
- return clk_freq_hz;
-}
-
-/**
* initialize the test rte_red config
*/
static enum test_result
@@ -321,7 +281,7 @@ test_rte_red_init(struct test_config *tcfg)
{
unsigned i = 0;
- tcfg->tvar->clk_freq = get_machclk_freq();
+ tcfg->tvar->clk_freq = rte_get_timer_hz();
init_port_ts( tcfg->tvar->clk_freq );
for (i = 0; i < tcfg->tconfig->num_cfg; i++) {
--
2.7.0
[dpdk-dev] [PATCH v3] mempool: replace c memcpy code semantics with optimized rte_memcpy
On 7/5/2016 3:09 PM, Ferruh Yigit wrote:
> On 7/5/2016 2:13 PM, Jerin Jacob wrote:
>> On Tue, Jul 05, 2016 at 07:32:46PM +0800, Yuanhan Liu wrote:
>>> On Tue, Jul 05, 2016 at 09:43:03AM +0100, Ferruh Yigit wrote:
On 6/30/2016 6:28 PM, Thomas Monjalon wrote:
> 2016-06-30 17:46, Jerin Jacob:
>> Signed-off-by: Jerin Jacob
>> Acked-by: Olivier Matz
>
> Applied, thanks
>
Hi Jerin,
This commit cause a compilation error on target i686-native-linuxapp-gcc
with gcc6.
>>>
>>> Besides that, I'm more curious to know have you actually seen any
>>> performance boost?
>>
>> let me first address your curiosity,
>> http://dpdk.org/dev/patchwork/patch/12993/( check the second comment)
>> http://dpdk.org/ml/archives/dev/2016-June/042701.html
>>
>> Ferruh,
>
> Hi Jerin,
>
>>
>> I have tested on a x86 machine with gcc 6.1. I could n't see any issues
>> with i686-native-linuxapp-gcc target
> Thanks for investigating the issue.
>
>>
>> Steps following to create gcc 6.1 toolchain
>> https://sahas.ra.naman.ms/2016/05/31/building-gcc6-1-on-fedora-23/
>> (removed --disable-multilib to have support for -m32)
>>
>> ? [dpdk-master] $ gcc -v
>> Using built-in specs.
>> COLLECT_GCC=gcc
>> COLLECT_LTO_WRAPPER=/opt/gcc-6.1.0/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
>> Target: x86_64-pc-linux-gnu
>> Configured with: ../gcc-6.1.0/configure --prefix=/opt/gcc-6.1.0
>> --enable-languages=c,c++ --enable-libmudflap --with-system-zlib
>> Thread model: posix
>> gcc version 6.1.0 (GCC)
> I am using Fedora24, which has gcc6 (6.1.1) as default.
>
>>
>> More over this issue seems like an issue from x86 rte_memcpy implementation.
> You are right. But i686 compilation starts failing with this commit.
> And reverting this commit in the current HEAD solves the compilation
> problem.
> I am not really clear about reason of the compilation error.
The compile error is because compiler is so smart now and at the same
time not enough smart.
Call stack is as following:
virtio_xmit_pkts_simple
virtio_xmit_cleanup
rte_mempool_put_bulk
rte_mempool_generic_put
__mempool_generic_put
rte_memcpy
The array used as source buffer in virtio_xmit_cleanup (free) is a
pointer array with 32 elements, in 32bit this makes 128 bytes.
in rte_memcpy() implementation, there a code piece as following:
if (size > 256) {
rte_move128(...);
rte_move128(...); <--- [1]
}
The compiler traces the array all through the call stack and knows the
size of array is 128 and generates a warning on above [1] which tries to
access beyond byte 128.
But unfortunately it ignores the "(size > 256)" check.
In 64bit, this warning is not generated because array size becomes 256
bytes.
So this warning is a false positive. Although I am working on it, if
anybody has a suggestion to prevent warning, quite welcome. At worst I
will disable this compiler warning for the file.
Thanks,
ferruh
[dpdk-dev] [PATCH v2 2/2] doc: add live migration overview image
This patch adds an image of the Live Migration test configuration. Signed-off-by: Bernard Iremonger --- doc/guides/how_to/img/lm_overview.svg | 666 + doc/guides/how_to/lm_bond_virtio_sriov.rst | 3 + 2 files changed, 669 insertions(+) create mode 100644 doc/guides/how_to/img/lm_overview.svg diff --git a/doc/guides/how_to/img/lm_overview.svg b/doc/guides/how_to/img/lm_overview.svg new file mode 100644 index 000..d913ae0 --- /dev/null +++ b/doc/guides/how_to/img/lm_overview.svg @@ -0,0 +1,666 @@ + + + +http://purl.org/dc/elements/1.1/"; + xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; + width="1052.8693" + height="762.99158" + id="svg2" + version="1.1" + inkscape:version="0.48.4 r9939" + sodipodi:docname="lm_overview.svg"> + + + + + + + + + + + + + + + + + + + + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + + + + + + + + +VM 1 +Switch with 10Gb ports +Server 1 +Server 2 + 10 Gb Traffic Generator +VM 2 +Linux, KVM, QEMU +Linux, KVM, QEMU +10 Gb NIC +10 Gb NIC + + +10 Gb NIC +10 Gb NIC + +DPDK Testpmd App. +bonded device withvirtio and VF slaves + +DPDK Testpmd App. +bonded device withvirtio and VF slaves +Kernel PF driver +Kernel PF driver +SW bridge with Tapand PF connected +NFS ServerVM disk image + + + + + + + + + + + + + + + +SW bridge with Tapand PF connected +10 Gb Migration Link + + diff --git a/doc/guides/how_to/lm_bond_virtio_sriov.rst b/doc/guides/how_to/lm_bond_virtio_sriov.rst index 66b5e62..f9d3667 100644 --- a/doc/guides/how_to/lm_bond_virtio_sriov.rst +++ b/doc/guides/how_to/lm_bond_virtio_sriov.rst @@ -57,6 +57,9 @@ The switch is configured to broadcast traffic on all the NIC ports. Live Migration with SR-IOV VF test setup: - +.. _figure_lm_overview: + +.. figure:: img/lm_overview.* Live Migration steps for VM with Virtio and VF PMD's: - -- 2.9.0
[dpdk-dev] [PATCH v2 1/2] doc: live migration of VM with Virtio and VF
This patch describes the procedure to be be followed to perform Live Migration of a VM with Virtio and VF PMD's using the bonding PMD. It includes sample host and VM scripts used in the procedure, and a sample switch configuration. Signed-off-by: Bernard Iremonger --- doc/guides/how_to/index.rst| 38 ++ doc/guides/how_to/lm_bond_virtio_sriov.rst | 690 + doc/guides/index.rst | 3 +- 3 files changed, 730 insertions(+), 1 deletion(-) create mode 100644 doc/guides/how_to/index.rst create mode 100644 doc/guides/how_to/lm_bond_virtio_sriov.rst diff --git a/doc/guides/how_to/index.rst b/doc/guides/how_to/index.rst new file mode 100644 index 000..4b97a32 --- /dev/null +++ b/doc/guides/how_to/index.rst @@ -0,0 +1,38 @@ +.. BSD LICENSE +Copyright(c) 2016 Intel Corporation. All rights reserved. +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. + +How To User Guide += + +.. toctree:: +:maxdepth: 3 +:numbered: + +lm_bond_virtio_sriov diff --git a/doc/guides/how_to/lm_bond_virtio_sriov.rst b/doc/guides/how_to/lm_bond_virtio_sriov.rst new file mode 100644 index 000..66b5e62 --- /dev/null +++ b/doc/guides/how_to/lm_bond_virtio_sriov.rst @@ -0,0 +1,690 @@ +.. BSD LICENSE +Copyright(c) 2016 Intel Corporation. All rights reserved. +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. + + +Live Migration of VM with SR-IOV VF: + + +Live Migration overview for VM with Virtio and VF PMD's: + + +It is not possible to migrate a Virtual Machine which has an SR-IOV Virtual Function. +To get around this problem the bonding PMD is used. + +A bonded device is created in the VM. +The virtio and VF PMD's are added as slaves to the bonded device. +The VF is set as the primary slave of the bonded device. + +A bridge must be set up on the Host connecting the tap
[dpdk-dev] [PATCH v2 0/2] doc: live migration procedure
This pachset set describes the procedure to Live migrate a VM with Virtio and VF PMD's using the bonding PMD. Changes in v2: change primary port before removing slave port remove unused variables from QEMU scripts identify NIC's in bridge setup scripts Bernard Iremonger (2): doc: live migration of VM with Virtio and VF doc: add live migration overview image doc/guides/how_to/img/lm_overview.svg | 666 +++ doc/guides/how_to/index.rst| 38 ++ doc/guides/how_to/lm_bond_virtio_sriov.rst | 693 + doc/guides/index.rst | 3 +- 4 files changed, 1399 insertions(+), 1 deletion(-) create mode 100644 doc/guides/how_to/img/lm_overview.svg create mode 100644 doc/guides/how_to/index.rst create mode 100644 doc/guides/how_to/lm_bond_virtio_sriov.rst -- 2.9.0
[dpdk-dev] [PATCH 2/2] doc: add pdump shared library version to release notes
Added missing librte_pdump shared library version to release notes. Signed-off-by: Reshma Pattan --- doc/guides/rel_notes/release_16_07.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/guides/rel_notes/release_16_07.rst b/doc/guides/rel_notes/release_16_07.rst index 569f562..d758cd5 100644 --- a/doc/guides/rel_notes/release_16_07.rst +++ b/doc/guides/rel_notes/release_16_07.rst @@ -318,6 +318,7 @@ The libraries prepended with a plus sign were incremented in this version. librte_mbuf.so.2 + librte_mempool.so.2 librte_meter.so.1 + librte_pdump.so.1 librte_pipeline.so.3 librte_pmd_bond.so.1 librte_pmd_ring.so.2 -- 2.5.0
[dpdk-dev] [PATCH 1/2] doc: add pcap dependency note to pdump tool guide
Added a missing note about dependencies on libpcap and CONFIG_RTE_LIBRTE_PMD_PCAP flag that pdump tool has. Signed-off-by: Reshma Pattan --- doc/guides/sample_app_ug/pdump.rst | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/doc/guides/sample_app_ug/pdump.rst b/doc/guides/sample_app_ug/pdump.rst index 96c8709..32d4fbc 100644 --- a/doc/guides/sample_app_ug/pdump.rst +++ b/doc/guides/sample_app_ug/pdump.rst @@ -33,14 +33,21 @@ dpdk_pdump Application == -The ``dpdk_pdump`` application is a Data Plane Development Kit (DPDK) application that runs as a DPDK secondary process and +The ``dpdk_pdump`` tool is a Data Plane Development Kit (DPDK) tool that runs as a DPDK secondary process and is capable of enabling packet capture on dpdk ports. + .. Note:: + + * The ``dpdk_pdump`` tool depends on libpcap based PMD which is disabled by default in the build configuration +files, owing to an external dependency on the libpcap development files which must be installed on the board. +Once the libpcap development files are installed, the libpcap based PMD can be enabled by setting +CONFIG_RTE_LIBRTE_PMD_PCAP=y and recompiling the DPDK. + Running the Application --- -The application has a ``--pdump`` command line option with various sub arguments: +The tool has a ``--pdump`` command line option with various sub arguments: .. code-block:: console -- 2.5.0
[dpdk-dev] [PATCH 0/2] update packet capture framework doc
This patch set contains 1) Release notes update for adding pdump library version to shared library section. 2) Added missing note about pdump tool dependency on libpcap and CONFIG_RTE_LIBRTE_PMD_PCAP. Reshma Pattan (2): doc: add pcap dependency note to pdump tool guide doc: add pdump shared library version to release notes doc/guides/rel_notes/release_16_07.rst | 1 + doc/guides/sample_app_ug/pdump.rst | 11 +-- 2 files changed, 10 insertions(+), 2 deletions(-) -- 2.5.0
[dpdk-dev] [PATCH 2/2] doc: add pdump shared library version to release notes
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Reshma Pattan > Sent: Wednesday, July 6, 2016 4:58 PM > To: dev at dpdk.org > Cc: Pattan, Reshma > Subject: [dpdk-dev] [PATCH 2/2] doc: add pdump shared library version to > release notes > > Added missing librte_pdump shared library version to release notes. > > Signed-off-by: Reshma Pattan Acked-by: John McNamara
[dpdk-dev] [PATCH 1/2] doc: add pcap dependency note to pdump tool guide
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Reshma Pattan > Sent: Wednesday, July 6, 2016 4:58 PM > To: dev at dpdk.org > Cc: Pattan, Reshma > Subject: [dpdk-dev] [PATCH 1/2] doc: add pcap dependency note to pdump > tool guide > > Added a missing note about dependencies on libpcap and > CONFIG_RTE_LIBRTE_PMD_PCAP flag that pdump tool has. > > Signed-off-by: Reshma Pattan Acked-by: John McNamara
[dpdk-dev] [PATCH 3/3] examples: fix dependencies on hash library
The multi_process example do not need rte_hash. But these examples cannot compile if rte_hash is not available: - ipsec-secgw (was already protected - no change) - ipv4_multicast - l3fwd-power - l3fwd-vf - tep_termination - ip_pipeline The ip_pipeline example is not disabled because its dependencies are handled with #ifdef. It may require a separate fix. Signed-off-by: Thomas Monjalon --- examples/Makefile| 8 ++-- examples/multi_process/client_server_mp/mp_server/init.c | 1 - examples/multi_process/client_server_mp/mp_server/main.c | 1 - 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/examples/Makefile b/examples/Makefile index f650d3e..18b41b9 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -54,7 +54,7 @@ endif ifeq ($(CONFIG_RTE_LIBRTE_ACL)$(CONFIG_RTE_LIBRTE_HASH)$(CONFIG_RTE_LIBRTE_LPM),yyy) DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += ipsec-secgw endif -DIRS-y += ipv4_multicast +DIRS-$(CONFIG_RTE_LIBRTE_HASH) += ipv4_multicast DIRS-$(CONFIG_RTE_LIBRTE_KNI) += kni DIRS-y += l2fwd ifneq ($(PQOS_INSTALL_PATH),) @@ -65,9 +65,11 @@ DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += l2fwd-ivshmem DIRS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += l2fwd-jobstats DIRS-y += l2fwd-keepalive DIRS-y += l2fwd-keepalive/ka-agent +ifeq ($(CONFIG_RTE_LIBRTE_HASH),y) DIRS-$(CONFIG_RTE_LIBRTE_LPM) += l3fwd +endif DIRS-$(CONFIG_RTE_LIBRTE_ACL) += l3fwd-acl -ifeq ($(CONFIG_RTE_LIBRTE_LPM),y) +ifeq ($(CONFIG_RTE_LIBRTE_LPM)$(CONFIG_RTE_LIBRTE_HASH),yy) DIRS-$(CONFIG_RTE_LIBRTE_POWER) += l3fwd-power DIRS-y += l3fwd-vf endif @@ -82,7 +84,9 @@ DIRS-$(CONFIG_RTE_LIBRTE_SCHED) += qos_sched DIRS-y += quota_watermark DIRS-$(CONFIG_RTE_ETHDEV_RXTX_CALLBACKS) += rxtx_callbacks DIRS-y += skeleton +ifeq ($(CONFIG_RTE_LIBRTE_HASH),y) DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += tep_termination +endif DIRS-$(CONFIG_RTE_LIBRTE_TIMER) += timer DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost DIRS-$(CONFIG_RTE_LIBRTE_XEN_DOM0) += vhost_xen diff --git a/examples/multi_process/client_server_mp/mp_server/init.c b/examples/multi_process/client_server_mp/mp_server/init.c index ecb61c6..ad941a7 100644 --- a/examples/multi_process/client_server_mp/mp_server/init.c +++ b/examples/multi_process/client_server_mp/mp_server/init.c @@ -60,7 +60,6 @@ #include #include #include -#include #include #include diff --git a/examples/multi_process/client_server_mp/mp_server/main.c b/examples/multi_process/client_server_mp/mp_server/main.c index de54c67..a6dc12d 100644 --- a/examples/multi_process/client_server_mp/mp_server/main.c +++ b/examples/multi_process/client_server_mp/mp_server/main.c @@ -65,7 +65,6 @@ #include #include #include -#include #include #include "common.h" -- 2.7.0
[dpdk-dev] [PATCH 2/3] table: remove unneeded dependency on hash library
Fixes: 8aa327214ceb ("table: hash")
Signed-off-by: Thomas Monjalon
---
lib/librte_table/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/librte_table/Makefile b/lib/librte_table/Makefile
index 7f02af3..7a8a3f3 100644
--- a/lib/librte_table/Makefile
+++ b/lib/librte_table/Makefile
@@ -80,6 +80,5 @@ DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_lpm
ifeq ($(CONFIG_RTE_LIBRTE_ACL),y)
DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_acl
endif
-DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_hash
include $(RTE_SDK)/mk/rte.lib.mk
--
2.7.0
[dpdk-dev] [PATCH 1/3] net/bnx2x: remove unneeded dependency on hash library
Fixes: 9fb557035d90 ("bnx2x: enable PMD build")
Signed-off-by: Thomas Monjalon
---
drivers/net/bnx2x/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bnx2x/Makefile b/drivers/net/bnx2x/Makefile
index c2ddd8d..ab69680 100644
--- a/drivers/net/bnx2x/Makefile
+++ b/drivers/net/bnx2x/Makefile
@@ -31,7 +31,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_vfpf.c
SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC) += debug.c
# this lib depends upon:
-DEPDIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += lib/librte_eal lib/librte_ether
lib/librte_hash
+DEPDIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += lib/librte_eal lib/librte_ether
DEPDIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += lib/librte_mempool lib/librte_mbuf
include $(RTE_SDK)/mk/rte.lib.mk
--
2.7.0
[dpdk-dev] [PATCH 0/3] fix dependencies on librte_hash
Thomas Monjalon (3): net/bnx2x: remove unneeded dependency on hash library table: remove unneeded dependency on hash library examples: fix dependencies on hash library drivers/net/bnx2x/Makefile | 2 +- examples/Makefile| 8 ++-- examples/multi_process/client_server_mp/mp_server/init.c | 1 - examples/multi_process/client_server_mp/mp_server/main.c | 1 - lib/librte_table/Makefile| 1 - 5 files changed, 7 insertions(+), 6 deletions(-) -- 2.7.0
[dpdk-dev] [PATCH v6 0/4] support reset of VF link
On Wed, 2016-07-06 at 00:45 +, Lu, Wenzhuo wrote: > Hi Luca, > > > -Original Message- > > From: Luca Boccassi [mailto:lboccass at Brocade.com] > > Sent: Tuesday, July 5, 2016 5:53 PM > > To: Lu, Wenzhuo > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link > > > > On Tue, 2016-07-05 at 00:52 +, Lu, Wenzhuo wrote: > > > Hi Luca, > > > > > > > > > > -Original Message- > > > > From: Luca Boccassi [mailto:lboccass at Brocade.com] > > > > Sent: Monday, July 4, 2016 11:48 PM > > > > To: Lu, Wenzhuo > > > > Cc: dev at dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link > > > > > > > > On Mon, 2016-06-20 at 14:24 +0800, Wenzhuo Lu wrote: > > > > > If the PF link is down and up, VF link will not work accordingly. > > > > > This patch set addes the support of VF link reset. So, when VF > > > > > receices the messges of physical link down/up. APP can reset the > > > > > VF link and let it recover. > > > > > > > > > > PS: This patch set is splitted from a previous patch set, > > > > > *automatic link recovery on ixgbe/igb VF*, and it's base on the > > > > > patch set *support mailbox interruption on ixgbe/igb VF*. > > > > > > > > > > Wenzhuo Lu (3): > > > > > lib/librte_ether: support device reset > > > > > ixgbe: implement device reset on VF > > > > > igb: implement device reset on VF > > > > > > > > > > Zhe Tao (1): > > > > > i40e: implement device reset on VF > > > > > > > > > > v1: > > > > > - Added the implementation for the VF reset functionality. > > > > > v2: > > > > > - Changed the i40e related operations during VF reset. > > > > > v3: > > > > > - Resent the patches because of the mail sent issue. > > > > > v4: > > > > > - Removed some VF reset emulation code. > > > > > v5: > > > > > - Removed all the code related with lock. > > > > > v6: > > > > > - Updated the NIC feature overview matrix. > > > > > - Added more explanation in the doxygen comment of reset API. > > > > > > > > > > doc/guides/nics/overview.rst | 1 + > > > > > doc/guides/rel_notes/release_16_07.rst | 13 ++ > > > > > drivers/net/e1000/igb_ethdev.c | 59 > > > > > drivers/net/i40e/i40e_ethdev.h | 4 ++ > > > > > drivers/net/i40e/i40e_ethdev_vf.c | 83 > > > > ++ > > > > > drivers/net/i40e/i40e_rxtx.c | 10 > > > > > drivers/net/i40e/i40e_rxtx.h | 4 ++ > > > > > drivers/net/ixgbe/ixgbe_ethdev.c | 64 > > > > > +- > > > > > drivers/net/ixgbe/ixgbe_ethdev.h | 2 +- > > > > > drivers/net/ixgbe/ixgbe_rxtx.c | 12 +++-- > > > > > lib/librte_ether/rte_ethdev.c | 17 +++ > > > > > lib/librte_ether/rte_ethdev.h | 24 ++ > > > > > lib/librte_ether/rte_ether_version.map | 7 +++ > > > > > 13 files changed, 295 insertions(+), 5 deletions(-) > > > > > > > > Hello Wenzhuo, > > > > > > > > I'm testing this patchset, but I am sporadically running into an > > > > issue where the VFs reset fails after the PF flaps. > > > > > > > > I have a VM running on a KVM box with a X540-AT2, passing 2 VFs in. > > > > > > > > I am using calling rte_eth_dev_reset in response to a > > > > RTE_ETH_EVENT_INTR_RESET callback, and the following errors appear > > > > in the > > > > log: > > > > > > > > PMD: ixgbevf_dev_reset(): Ixgbe VF reset: Failed to update link. > > > > PMD: ixgbe_alloc_rx_queue_mbufs(): RX mbuf alloc failed queue_id=0 > > > > PMD: ixgbevf_dev_start(): Unable to initialize RX hardware (-12) > > > > PMD: ixgbevf_dev_reset(): Ixgbe VF reset: Failed to start device. > > > > > > > > Jumping in with GDB, it seems that the rte_rxmbuf_alloc call in > > > > ixgbe_alloc_rx_queue_mbufs returns NULL at iteration 64 out of 2048. > > > > The application has ~500 2MB hugepages, and there's 2GB of free > > > > memory available on top of that. > > > > > > > > Have you seen this before? Any pointer or suggestion for debugging? > > > > > > > > Thanks! > > > > > > > > -- > > > > Kind regards, > > > > Luca Boccassi > > > I think the problem is the mbuf occupied by the packets is not released. > > > This > > memory has to be released by the APP, so my patches haven?t covered this. > > Actually an example is needed to show how to use the reset API. I plan to > > modify > > the testpmd. > > > You may notice this feature is postponed to 16.11. Would you like to wait > > > for > > the new version that will include an example? > > > > Hi, > > > > Unfortunately we need the VF reset working sooner than that, so one way or > > the other I'll need to sort it out. Given I've got a use case where this is > > happening, > > if it can be helpful for you I'm more than happy to help as a guinea pig. > > If you > > could please give some guidance/guidelines with regards to which API to use > > to > > sort the mbuf problem, I can try it out and give back some feedback. > > > > Thanks! > I made a
[dpdk-dev] [PATCH] net/enic: fix checking for sufficient resources
The enic PMD was using the same variables in the enic structure to
track two different things. Initially rq_count, wq_count, cq_count,
and intr_count were set to the values obtained from the VIC adapters
as the maximum resources allocated on the VIC, then in
enic_set_vnic_res(), they were set to the counts of resources actually
used, discarding the initial values. The checks in enic_set_vnic_res()
were technically incorrect if it is called more than once on a port,
which happens when using bonding, but were harmless in practice as the
checks couldn't fail on the second call.
The enic rx-scatter patch misunderstood the subtleties of
enic_set_vnic_res(), and naively added a multiply by two to the
rq_count check. This resulted in the rq_count check failing when
enic_set_vnic_res() was called a second time, ie when using bonding.
This patch adds new variables to the enic structure to track the
maximum resources the VIC is configured to provide so that the
information isn't later lost and calls to enic_set_vnic_res() do
the expected thing.
Fixes: 856d7ba7ed22 ("net/enic: support scattered Rx")
Signed-off-by: Nelson Escobar
---
drivers/net/enic/enic.h| 6 ++
drivers/net/enic/enic_ethdev.c | 5 +++--
drivers/net/enic/enic_main.c | 14 --
drivers/net/enic/enic_res.c| 12 ++--
4 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 53fed0b..33057d4 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -152,6 +152,12 @@ struct enic {
/* software counters */
struct enic_soft_stats soft_stats;
+ /* configured resources on vic */
+ unsigned int conf_rq_count;
+ unsigned int conf_wq_count;
+ unsigned int conf_cq_count;
+ unsigned int conf_intr_count;
+
/* linked list storing memory allocations */
LIST_HEAD(enic_memzone_list, enic_memzone_entry) memzone_list;
rte_spinlock_t memzone_list_lock;
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index a7ce064..66b81a2 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -436,8 +436,9 @@ static void enicpmd_dev_info_get(struct rte_eth_dev
*eth_dev,
struct enic *enic = pmd_priv(eth_dev);
ENICPMD_FUNC_TRACE();
- device_info->max_rx_queues = enic->rq_count;
- device_info->max_tx_queues = enic->wq_count;
+ /* Scattered Rx uses two receive queues per rx queue exposed to dpdk */
+ device_info->max_rx_queues = enic->conf_rq_count / 2;
+ device_info->max_tx_queues = enic->conf_wq_count;
device_info->min_rx_bufsize = ENIC_MIN_MTU;
device_info->max_rx_pktlen = enic->rte_dev->data->mtu
+ ETHER_HDR_LEN + 4;
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 0475cc1..d4e43b5 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -1016,21 +1016,23 @@ int enic_set_vnic_res(struct enic *enic)
/* With Rx scatter support, two RQs are now used per RQ used by
* the application.
*/
- if (enic->rq_count < (eth_dev->data->nb_rx_queues * 2)) {
+ if (enic->conf_rq_count < eth_dev->data->nb_rx_queues) {
dev_err(dev, "Not enough Receive queues. Requested:%u which
uses %d RQs on VIC, Configured:%u\n",
eth_dev->data->nb_rx_queues,
- eth_dev->data->nb_rx_queues * 2, enic->rq_count);
+ eth_dev->data->nb_rx_queues * 2, enic->conf_rq_count);
rc = -EINVAL;
}
- if (enic->wq_count < eth_dev->data->nb_tx_queues) {
+ if (enic->conf_wq_count < eth_dev->data->nb_tx_queues) {
dev_err(dev, "Not enough Transmit queues. Requested:%u,
Configured:%u\n",
- eth_dev->data->nb_tx_queues, enic->wq_count);
+ eth_dev->data->nb_tx_queues, enic->conf_wq_count);
rc = -EINVAL;
}
- if (enic->cq_count < (enic->rq_count + enic->wq_count)) {
+ if (enic->conf_cq_count < (eth_dev->data->nb_rx_queues +
+ eth_dev->data->nb_tx_queues)) {
dev_err(dev, "Not enough Completion queues. Required:%u,
Configured:%u\n",
- enic->rq_count + enic->wq_count, enic->cq_count);
+ (eth_dev->data->nb_rx_queues +
+eth_dev->data->nb_tx_queues), enic->conf_cq_count);
rc = -EINVAL;
}
diff --git a/drivers/net/enic/enic_res.c b/drivers/net/enic/enic_res.c
index b271d34..84c5d33 100644
--- a/drivers/net/enic/enic_res.c
+++ b/drivers/net/enic/enic_res.c
@@ -215,14 +215,14 @@ void enic_free_vnic_resources(struct enic *enic)
void enic_get_res_counts(struct enic *enic)
{
- enic->wq_count = vnic_dev_get_res_count(enic->vdev, RES_TYPE_WQ);
- enic->rq_count = vnic
[dpdk-dev] [PATCH v2] scripts: check headline of drivers commits
From: Nelio Laranjeiro A driver patch under net should start with "net/" or if a patch touch multiple drivers, it should only start with "net:". The same apply for crypto. A patch touching all drivers (net + crypto) should start with "drivers:". Longer prefixes like "net/mlx:" (for mlx4/mlx5) or "net/e1000/base:" are handled by not checking the colon. The directories doc/ and config/ are ignored because a driver patch can modify them. Signed-off-by: Nelio Laranjeiro Signed-off-by: Thomas Monjalon --- v2: - fix capture in bad variable - ignore doc/ and config/ --- scripts/check-git-log.sh | 18 ++ 1 file changed, 18 insertions(+) diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh index 833aa39..21f1055 100755 --- a/scripts/check-git-log.sh +++ b/scripts/check-git-log.sh @@ -70,6 +70,24 @@ bad=$(echo "$headlines" | grep --color=always \ | sed 's,^,\t,') [ -z "$bad" ] || printf "Wrong headline format:\n$bad\n" +# check headline prefix when touching only drivers, e.g. net/ +bad=$(for commit in $commits ; do + headline=$(git log --format='%s' -1 $commit) + files=$(git diff-tree --no-commit-id --name-only -r $commit) + [ -z "$(echo "$files" | grep -v '^\(drivers\|doc\|config\)/')" ] || + continue + drv=$(echo "$files" | grep '^drivers/' | cut -d "/" -f 2,3 | sort -u) + drvgrp=$(echo "$drv" | cut -d "/" -f 1 | uniq) + if [ $(echo "$drvgrp" | wc -l) -gt 1 ] ; then + echo "$headline" | grep -v '^drivers:' + elif [ $(echo "$drv" | wc -l) -gt 1 ] ; then + echo "$headline" | grep -v "^$drvgrp" + else + echo "$headline" | grep -v "^$drv" + fi +done | sed 's,^,\t,') +[ -z "$bad" ] || printf "Wrong headline prefix:\n$bad\n" + # check headline label for common typos bad=$(echo "$headlines" | grep --color=always \ -e '^example[:/]' \ -- 2.7.0
[dpdk-dev] about rx checksum flags
Hi Sugesh On 07/06/2016 02:52 PM, Chandran, Sugesh wrote: > Hi Olivier, > > Just to confirm , is this rx checksum patch already submitted in the DPDK ML? > We would like to use these flags to speed up the tunneling in OVS. No it is not submitted yet. I plan to send it in the coming days, it will apply on top of the sw packet_type patchset I've sent yesterday. Regards, Olivier
[dpdk-dev] [PATCH 3/3] scripts: check headline of drivers commits
2016-07-06 13:59, N?lio Laranjeiro: > > +# check headline prefix when touching only drivers/, e.g. net/ > > +bad=$(for commit in $commits ; do > > + headline=$(git log --format='%s' -1 $commit) > > + files=$(git diff-tree --no-commit-id --name-only -r $commit) > > + [ -z "$(echo "$files" | grep -v '^drivers/')" ] || continue > > + driversgrp=$(echo "$files" | cut -d "/" -f 2 | sort -u) > > + drivers=$(echo "$files" | cut -d "/" -f 2,3 | sort -u) > > + if [ $(echo "$driversgrp" | wc -l) -gt 1 ] ; then > > + bad=$(echo "$headline" | grep -v '^drivers:') > > I think you forgot the '$' for drivers in the line just above. No it is a plain "drivers:" for cases where we have net and crypto. (it is an addition from your original idea) But I forgot to remove bad=$( which I've moved to the first line. > > + elif [ $(echo "$drivers" | wc -l) -gt 1 ] ; then > > + bad=$(echo "$headline" | grep -v "^$driversgrp") > > + else > > + bad=$(echo "$headline" | grep -v "^$drivers") > > + fi > > +done | sed 's,^,\t,') > > +[ -z "$bad" ] || printf "Wrong headline prefix:\n$bad\n" > > Otherwise it seems good. V2 on going
[dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet type parser
Hi Olivier,
On 7/5/2016 11:41 PM, Olivier Matz wrote:
> Add a new RTE_PTYPE_L2_ETHER_MPLS packet type, and its support in
> rte_pktmbuf_get_ptype().
>
> Signed-off-by: Didier Pallard
> Signed-off-by: Olivier Matz
> ---
> lib/librte_mbuf/rte_mbuf_ptype.c | 25 +
> lib/librte_mbuf/rte_mbuf_ptype.h | 9 -
> lib/librte_net/Makefile | 4 +++-
> lib/librte_net/rte_ether.h | 2 ++
> 4 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c
> b/lib/librte_mbuf/rte_mbuf_ptype.c
> index 5d46608..0dea600 100644
> --- a/lib/librte_mbuf/rte_mbuf_ptype.c
> +++ b/lib/librte_mbuf/rte_mbuf_ptype.c
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
>
> /* get l3 packet type from ip6 next protocol */
> static uint32_t
> @@ -166,6 +167,9 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
> off = sizeof(*eh);
> hdr_lens->l2_len = off;
>
> + if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4))
> + goto l3; /* fast path if packet is IPv4 */
> +
> if (proto == rte_cpu_to_be_16(ETHER_TYPE_VLAN)) {
> const struct vlan_hdr *vh;
> struct vlan_hdr vh_copy;
> @@ -189,8 +193,29 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
> off += 2 * sizeof(*vh);
> hdr_lens->l2_len += 2 * sizeof(*vh);
> proto = vh->eth_proto;
> + } else if ((proto == rte_cpu_to_be_16(ETHER_TYPE_MPLS)) ||
> + (proto == rte_cpu_to_be_16(ETHER_TYPE_MPLSM))) {
> + unsigned int i;
> + const struct mpls_hdr *mh;
> + struct mpls_hdr mh_copy;
> +
> +#define MAX_MPLS_HDR 5
> + for (i = 0; i < MAX_MPLS_HDR; i++) {
> + mh = rte_pktmbuf_read(m, off + (i * sizeof(*mh)),
> + sizeof(*mh), &mh_copy);
> + if (unlikely(mh == NULL))
> + return pkt_type;
> + if (mh->bs)
> + break;
> + }
> + if (i == MAX_MPLS_HDR)
> + return pkt_type;
> + pkt_type = RTE_PTYPE_L2_ETHER_MPLS;
> + hdr_lens->l2_len += (sizeof(*mh) * (i + 1));
[LC] l2_len includes Eth, Vlan(opt.), MPLS(opt.). For VLAN and MPLS, it
may include #n times overlay.
These layer recognition knowledge are lost after the detection logic.
Once the APP takes the ptype, for the layer(L2, L3, L4) which has more
shim-layer, the xxx_len can't help to avoid the re-parse cost.
> + return pkt_type;
> }
>
> [...]
[dpdk-dev] [PATCH v3 1/3] kasumi: add new KASUMI PMD
2016-07-06 12:26, Ferruh Yigit:
> On 6/20/2016 3:40 PM, Pablo de Lara wrote:
> > enum rte_cryptodev_type {
> > RTE_CRYPTODEV_NULL_PMD = 1, /**< Null crypto PMD */
> > RTE_CRYPTODEV_AESNI_GCM_PMD,/**< AES-NI GCM PMD */
> > RTE_CRYPTODEV_AESNI_MB_PMD, /**< AES-NI multi buffer PMD */
> > + RTE_CRYPTODEV_KASUMI_PMD, /**< KASUMI PMD */
> Does adding new field into middle cause a ABI breakage?
> Since now value of below fields changed.
>
> Btw, librte_cryptodev is not listed in release notes, "shared library
> versions" section, not sure if this is intentional.
Good catch!
Now that crypto is not experimental anymore, we must add cryptodev in
release notes. librte_pdump is also missing in this list.
[dpdk-dev] [PATCH] cryptodev: move new cryptodev type to bottom of enum
New cryptodev type for the new KASUMI PMD was added
in the cryptodev type enum, but not at the end of it,
causing an ABI breakage.
Fixes: 2773c86d061a ("crypto/kasumi: add driver for KASUMI library")
Signed-off-by: Pablo de Lara
Reported-by: Ferruh Yigit
---
lib/librte_cryptodev/rte_cryptodev.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index 7768f0a..508c1f7 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -67,9 +67,9 @@ enum rte_cryptodev_type {
RTE_CRYPTODEV_NULL_PMD = 1, /**< Null crypto PMD */
RTE_CRYPTODEV_AESNI_GCM_PMD,/**< AES-NI GCM PMD */
RTE_CRYPTODEV_AESNI_MB_PMD, /**< AES-NI multi buffer PMD */
- RTE_CRYPTODEV_KASUMI_PMD, /**< KASUMI PMD */
RTE_CRYPTODEV_QAT_SYM_PMD, /**< QAT PMD Symmetric Crypto */
RTE_CRYPTODEV_SNOW3G_PMD, /**< SNOW 3G PMD */
+ RTE_CRYPTODEV_KASUMI_PMD, /**< KASUMI PMD */
};
extern const char **rte_cyptodev_names;
--
2.5.5
[dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type from data
Hi Olivier,
On 7/5/2016 11:41 PM, Olivier Matz wrote:
> Introduce the function rte_pktmbuf_get_ptype() that parses a
> mbuf and returns its packet type. For now, the following packet
> types are parsed:
> L2: Ether
> L3: IPv4, IPv6
> L4: TCP, UDP, SCTP
>
> The goal here is to provide a reference implementation for packet type
> parsing. This function will be used by testpmd in next commits, allowing
> to compare its result with the value given by the hardware.
>
> This function will also be useful when implementing Rx offload support
> in virtio pmd. Indeed, the virtio protocol gives the csum start and
> offset, but it does not give the L4 protocol nor it tells if the
> checksum is relevant for inner or outer. This information has to be
> known to properly set the ol_flags in mbuf.
>
> Signed-off-by: Didier Pallard
> Signed-off-by: Jean Dao
> Signed-off-by: Olivier Matz
> ---
> doc/guides/rel_notes/release_16_11.rst | 5 +
> lib/librte_mbuf/Makefile | 5 +-
> lib/librte_mbuf/rte_mbuf_ptype.c | 234
> +
> lib/librte_mbuf/rte_mbuf_ptype.h | 43 ++
> lib/librte_mbuf/rte_mbuf_version.map | 1 +
> 5 files changed, 286 insertions(+), 2 deletions(-)
> create mode 100644 lib/librte_mbuf/rte_mbuf_ptype.c
>
> [...]
> +
> +/* parse mbuf data to get packet type */
> +uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
> + struct rte_mbuf_hdr_lens *hdr_lens)
> +{
> + struct rte_mbuf_hdr_lens local_hdr_lens;
> + const struct ether_hdr *eh;
> + struct ether_hdr eh_copy;
> + uint32_t pkt_type = RTE_PTYPE_L2_ETHER;
> + uint32_t off = 0;
> + uint16_t proto;
> +
> + if (hdr_lens == NULL)
> + hdr_lens = &local_hdr_lens;
> +
> + eh = rte_pktmbuf_read(m, off, sizeof(*eh), &eh_copy);
> + if (unlikely(eh == NULL))
> + return 0;
> + proto = eh->ether_type;
> + off = sizeof(*eh);
> + hdr_lens->l2_len = off;
> +
> + if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
> + const struct ipv4_hdr *ip4h;
> + struct ipv4_hdr ip4h_copy;
> +
> + ip4h = rte_pktmbuf_read(m, off, sizeof(*ip4h), &ip4h_copy);
> + if (unlikely(ip4h == NULL))
> + return pkt_type;
> +
> + pkt_type |= ptype_l3_ip(ip4h->version_ihl);
> + hdr_lens->l3_len = ip4_hlen(ip4h);
> + off += hdr_lens->l3_len;
> + if (ip4h->fragment_offset &
> + rte_cpu_to_be_16(IPV4_HDR_OFFSET_MASK |
> + IPV4_HDR_MF_FLAG)) {
> + pkt_type |= RTE_PTYPE_L4_FRAG;
> + hdr_lens->l4_len = 0;
> + return pkt_type;
> + }
> + proto = ip4h->next_proto_id;
> + pkt_type |= ptype_l4(proto);
> + } else if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv6)) {
> + const struct ipv6_hdr *ip6h;
> + struct ipv6_hdr ip6h_copy;
> + int frag = 0;
> +
> + ip6h = rte_pktmbuf_read(m, off, sizeof(*ip6h), &ip6h_copy);
> + if (unlikely(ip6h == NULL))
> + return pkt_type;
> +
> + proto = ip6h->proto;
> + hdr_lens->l3_len = sizeof(*ip6h);
> + off += hdr_lens->l3_len;
> + pkt_type |= ptype_l3_ip6(proto);
> + if ((pkt_type & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV6_EXT) {
> + proto = skip_ip6_ext(proto, m, &off, &frag);
> + hdr_lens->l3_len = off - hdr_lens->l2_len;
> + }
> + if (proto == 0)
> + return pkt_type;
> + if (frag) {
> + pkt_type |= RTE_PTYPE_L4_FRAG;
> + hdr_lens->l4_len = 0;
> + return pkt_type;
> + }
> + pkt_type |= ptype_l4(proto);
> + }
> +
> + if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_UDP) {
> + hdr_lens->l4_len = sizeof(struct udp_hdr);
> + } else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_TCP) {
> + const struct tcp_hdr *th;
> + struct tcp_hdr th_copy;
> +
> + th = rte_pktmbuf_read(m, off, sizeof(*th), &th_copy);
> + if (unlikely(th == NULL))
> + return pkt_type & (RTE_PTYPE_L2_MASK |
> + RTE_PTYPE_L3_MASK);
> + hdr_lens->l4_len = (th->data_off & 0xf0) >> 2;
> + } else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_SCTP) {
> + hdr_lens->l4_len = sizeof(struct sctp_hdr);
> + } else {
> + hdr_lens->l4_len = 0;
> + }
> +
> + return pkt_type;
> +}
> diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h
> b/lib/librte_mbuf/rte_mbuf_ptype.h
> index 4a34678..f468520 100644
> --- a/lib/librte_mbuf/rte_mbuf_ptype.h
> +++ b/lib/librte_mbuf/rte_mbuf_ptype.h
> @@ -545,6 +545,49 @
[dpdk-dev] [PATCH v2] Memory leak when adding/removing vhost_user ports
Now let us really get to this old discussion. Once again - sorry for mixing this up :-/ Found too much at once today. ## Ok - refocus ## Back then in http://dpdk.org/dev/patchwork/patch/12103/ http://dpdk.org/dev/patchwork/patch/12118/ We came up with a nice solution for the leak. But it was never picked up upstream. There were a lot of changes to all of that code, especially vhost client/server. Lacking an openvswitch for DPDK 16.07 I can't test if the issue still shows up, but looking at the code suggests it still does. Unfortunately the internal structures and scopes are slightly different so that I couldn't come up with a working forward port of the old patch. Attached is a patch as close as I got (obviously not working). I'm convinced that Yuanhan Liu and Xie Huawei with their deep context knowledge of dpdk's vhost_user will quickly know: - if the root cause still applies - what the best new way of fixing this would be As this makes long term usage of dpdk aborting by a leak I hope we have a chance to get this into 16.07 still. Kind Regards, Christian Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Wed, Jul 6, 2016 at 2:30 PM, Christian Ehrhardt < christian.ehrhardt at canonical.com> wrote: > This is the series this really belongs to > http://dpdk.org/dev/patchwork/patch/11581/ > Message ID < > 1458292380-9258-1-git-send-email-patrik.r.andersson at ericsson.com> > > Should I wait for a v2 to point the patch at the right ID or do you prefer > a fixed resubmit right away? > > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > > On Wed, Jul 6, 2016 at 2:26 PM, Christian Ehrhardt < > christian.ehrhardt at canonical.com> wrote: > >> Sorry, >> please ignore the two links, the cover letter has - they belong to a >> different issue I have to bring up again. >> Everything else still applies. >> >> Christian Ehrhardt >> Software Engineer, Ubuntu Server >> Canonical Ltd >> >> On Wed, Jul 6, 2016 at 2:24 PM, Christian Ehrhardt < >> christian.ehrhardt at canonical.com> wrote: >> >>> Hi, >>> while checking for dpdk 16.07 what backports are accepted in the >>> meantime so I >>> can drop them I found this particular discussion has been silently >>> forgotten by >>> all of us. >>> >>> Back then we had the patch and discussion first in >>> http://dpdk.org/dev/patchwork/patch/12103/ >>> and then >>> http://dpdk.org/dev/patchwork/patch/12118/ >>> >>> Things worked fine as I reported and I integrated the patch in our >>> packaging as >>> it fixed a severe issue. Since it was reported by someone else I do not >>> seem to >>> be the only one :-) >>> >>> So today I rebased the patch including my updates I made based on our >>> discussion >>> and I think it would make as much sense as it made back then to fix this. >>> >>> Christian Ehrhardt (1): >>> vhost_user: avoid crash when exeeding file descriptors >>> >>> lib/librte_vhost/vhost_user/fd_man.c | 11 ++- >>> lib/librte_vhost/vhost_user/vhost-net-user.c | 19 +-- >>> 2 files changed, 23 insertions(+), 7 deletions(-) >>> >>> -- >>> 2.7.4 >>> >>> >> >
[dpdk-dev] [PATCH 3/3] scripts: check headline of drivers commits
2016-07-06 12:09, Bruce Richardson: > On Wed, Jul 06, 2016 at 12:38:50PM +0200, Thomas Monjalon wrote: > > From: Nelio Laranjeiro > > +# check headline prefix when touching only drivers/, e.g. net/ > > +bad=$(for commit in $commits ; do > > + headline=$(git log --format='%s' -1 $commit) > > + files=$(git diff-tree --no-commit-id --name-only -r $commit) > > + [ -z "$(echo "$files" | grep -v '^drivers/')" ] || continue > > Given the preference for including documentation in with the code changes, > we should perhaps exclude any doc changes when making this check. Yes we can exclude doc/ and config/. Thanks
[dpdk-dev] [PATCH v2] Memory leak when adding/removing vhost_user ports
This is the series this really belongs to http://dpdk.org/dev/patchwork/patch/11581/ Message ID <1458292380-9258-1-git-send-email-patrik.r.andersson at ericsson.com > Should I wait for a v2 to point the patch at the right ID or do you prefer a fixed resubmit right away? Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Wed, Jul 6, 2016 at 2:26 PM, Christian Ehrhardt < christian.ehrhardt at canonical.com> wrote: > Sorry, > please ignore the two links, the cover letter has - they belong to a > different issue I have to bring up again. > Everything else still applies. > > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > > On Wed, Jul 6, 2016 at 2:24 PM, Christian Ehrhardt < > christian.ehrhardt at canonical.com> wrote: > >> Hi, >> while checking for dpdk 16.07 what backports are accepted in the meantime >> so I >> can drop them I found this particular discussion has been silently >> forgotten by >> all of us. >> >> Back then we had the patch and discussion first in >> http://dpdk.org/dev/patchwork/patch/12103/ >> and then >> http://dpdk.org/dev/patchwork/patch/12118/ >> >> Things worked fine as I reported and I integrated the patch in our >> packaging as >> it fixed a severe issue. Since it was reported by someone else I do not >> seem to >> be the only one :-) >> >> So today I rebased the patch including my updates I made based on our >> discussion >> and I think it would make as much sense as it made back then to fix this. >> >> Christian Ehrhardt (1): >> vhost_user: avoid crash when exeeding file descriptors >> >> lib/librte_vhost/vhost_user/fd_man.c | 11 ++- >> lib/librte_vhost/vhost_user/vhost-net-user.c | 19 +-- >> 2 files changed, 23 insertions(+), 7 deletions(-) >> >> -- >> 2.7.4 >> >> >
[dpdk-dev] [PATCH v2] Memory leak when adding/removing vhost_user ports
Sorry, please ignore the two links, the cover letter has - they belong to a different issue I have to bring up again. Everything else still applies. Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Wed, Jul 6, 2016 at 2:24 PM, Christian Ehrhardt < christian.ehrhardt at canonical.com> wrote: > Hi, > while checking for dpdk 16.07 what backports are accepted in the meantime > so I > can drop them I found this particular discussion has been silently > forgotten by > all of us. > > Back then we had the patch and discussion first in > http://dpdk.org/dev/patchwork/patch/12103/ > and then > http://dpdk.org/dev/patchwork/patch/12118/ > > Things worked fine as I reported and I integrated the patch in our > packaging as > it fixed a severe issue. Since it was reported by someone else I do not > seem to > be the only one :-) > > So today I rebased the patch including my updates I made based on our > discussion > and I think it would make as much sense as it made back then to fix this. > > Christian Ehrhardt (1): > vhost_user: avoid crash when exeeding file descriptors > > lib/librte_vhost/vhost_user/fd_man.c | 11 ++- > lib/librte_vhost/vhost_user/vhost-net-user.c | 19 +-- > 2 files changed, 23 insertions(+), 7 deletions(-) > > -- > 2.7.4 > >
[dpdk-dev] [PATCH v2] vhost_user: avoid crash when exeeding file descriptors
*update in v2*
- refreshing for DPDK 16.07
- Close fd on vserver->listenfd as suggested in discussion
Original From:
From: Patrik Andersson
Protect against DPDK crash when allocation of listen fd >= 1023.
For events on fd:s >1023, the current implementation will trigger
an abort due to access outside of allocated bit mask.
Corrections would include:
* Match fdset_add() signature in fd_man.c to fd_man.h
* Handling of return codes from fdset_add()
* Addition of check of fd number in fdset_add_fd()
The rationale behind the suggested code change is that,
fdset_event_dispatch() could attempt access outside of the FD_SET
bitmask if there is an event on a file descriptor that in turn
looks up a virtio file descriptor with a value > 1023.
Such an attempt will lead to an abort() and a restart of any
vswitch using DPDK.
A discussion topic exist in the ovs-discuss mailing list that can
provide a little more background:
http://openvswitch.org/pipermail/discuss/2016-February/020243.html
Fixes: 8f972312 ("vhost: support vhost-user")
Signed-off-by: Patrik Andersson
Signed-off-by: Christian Ehrhardt
---
lib/librte_vhost/vhost_user/fd_man.c | 11 ++-
lib/librte_vhost/vhost_user/vhost-net-user.c | 19 +--
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/lib/librte_vhost/vhost_user/fd_man.c
b/lib/librte_vhost/vhost_user/fd_man.c
index 087aaed..c691339 100644
--- a/lib/librte_vhost/vhost_user/fd_man.c
+++ b/lib/librte_vhost/vhost_user/fd_man.c
@@ -71,20 +71,22 @@ fdset_find_free_slot(struct fdset *pfdset)
return fdset_find_fd(pfdset, -1);
}
-static void
+static int
fdset_add_fd(struct fdset *pfdset, int idx, int fd,
fd_cb rcb, fd_cb wcb, void *dat)
{
struct fdentry *pfdentry;
- if (pfdset == NULL || idx >= MAX_FDS)
- return;
+ if (pfdset == NULL || idx >= MAX_FDS || fd >= FD_SETSIZE)
+ return -1;
pfdentry = &pfdset->fd[idx];
pfdentry->fd = fd;
pfdentry->rcb = rcb;
pfdentry->wcb = wcb;
pfdentry->dat = dat;
+
+ return 0;
}
/**
@@ -150,12 +152,11 @@ fdset_add(struct fdset *pfdset, int fd, fd_cb rcb, fd_cb
wcb, void *dat)
/* Find a free slot in the list. */
i = fdset_find_free_slot(pfdset);
- if (i == -1) {
+ if (i == -1 || fdset_add_fd(pfdset, i, fd, rcb, wcb, dat) < 0) {
pthread_mutex_unlock(&pfdset->fd_mutex);
return -2;
}
- fdset_add_fd(pfdset, i, fd, rcb, wcb, dat);
pfdset->num++;
pthread_mutex_unlock(&pfdset->fd_mutex);
diff --git a/lib/librte_vhost/vhost_user/vhost-net-user.c
b/lib/librte_vhost/vhost_user/vhost-net-user.c
index 94f1b92..5743f52 100644
--- a/lib/librte_vhost/vhost_user/vhost-net-user.c
+++ b/lib/librte_vhost/vhost_user/vhost-net-user.c
@@ -257,6 +257,7 @@ vhost_user_add_connection(int fd, struct vhost_user_socket
*vsocket)
int vid;
size_t size;
struct vhost_user_connection *conn;
+ int ret;
conn = malloc(sizeof(*conn));
if (conn == NULL) {
@@ -278,7 +279,15 @@ vhost_user_add_connection(int fd, struct vhost_user_socket
*vsocket)
conn->vsocket = vsocket;
conn->vid = vid;
- fdset_add(&vhost_user.fdset, fd, vhost_user_msg_handler, NULL, conn);
+ ret = fdset_add(&vhost_user.fdset, fd, vhost_user_msg_handler,
+ NULL, conn);
+ if (ret < 0) {
+ free(conn);
+ close(fd);
+ RTE_LOG(ERR, VHOST_CONFIG,
+ "failed to add fd %d into vhost server fdset\n",
+ fd);
+ }
}
/* call back when there is new vhost-user connection from client */
@@ -469,8 +478,14 @@ vhost_user_create_server(struct vhost_user_socket *vsocket)
goto err;
vsocket->listenfd = fd;
- fdset_add(&vhost_user.fdset, fd, vhost_user_server_new_connection,
+ ret = fdset_add(&vhost_user.fdset, fd, vhost_user_server_new_connection,
NULL, vsocket);
+ if (ret < 0) {
+ RTE_LOG(ERR, VHOST_CONFIG,
+ "failed to add listen fd %d to vhost server fdset\n",
+ fd);
+ goto err;
+ }
return 0;
--
2.7.4
[dpdk-dev] [PATCH v2] Memory leak when adding/removing vhost_user ports
Hi, while checking for dpdk 16.07 what backports are accepted in the meantime so I can drop them I found this particular discussion has been silently forgotten by all of us. Back then we had the patch and discussion first in http://dpdk.org/dev/patchwork/patch/12103/ and then http://dpdk.org/dev/patchwork/patch/12118/ Things worked fine as I reported and I integrated the patch in our packaging as it fixed a severe issue. Since it was reported by someone else I do not seem to be the only one :-) So today I rebased the patch including my updates I made based on our discussion and I think it would make as much sense as it made back then to fix this. Christian Ehrhardt (1): vhost_user: avoid crash when exeeding file descriptors lib/librte_vhost/vhost_user/fd_man.c | 11 ++- lib/librte_vhost/vhost_user/vhost-net-user.c | 19 +-- 2 files changed, 23 insertions(+), 7 deletions(-) -- 2.7.4
[dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address.
On 01.07.2016 10:35, Yuanhan Liu wrote:
> Hi,
>
> Sorry for the long delay.
>
> On Fri, May 20, 2016 at 03:50:04PM +0300, Ilya Maximets wrote:
>> In current implementation guest application can reinitialize vrings
>> by executing start after stop. In the same time host application
>> can still poll virtqueue while device stopped in guest and it will
>> crash with segmentation fault while vring reinitialization because
>> of dereferencing of bad descriptor addresses.
>
> Yes, you are right that vring will be reinitialized after restart.
> But even though, I don't see the reason it will cause a vhost crash,
> since the reinitialization will reset all the vring memeory by 0:
>
> memset(vq->vq_ring_virt_mem, 0, vq->vq_ring_size);
>
> That means those bad descriptors will be skipped, safely, at vhost
> side by:
>
> if (unlikely(desc->len < dev->vhost_hlen))
> return -1;
>
>>
>> OVS crash for example:
>> <>
>> [test-pmd inside guest VM]
>>
>> testpmd> port stop all
>> Stopping ports...
>> Checking link statuses...
>> Port 0 Link Up - speed 1 Mbps - full-duplex
>> Done
>> testpmd> port config all rxq 2
>> testpmd> port config all txq 2
>> testpmd> port start all
>> Configuring Port 0 (socket 0)
>> Port 0: 52:54:00:CB:44:C8
>> Checking link statuses...
>> Port 0 Link Up - speed 1 Mbps - full-duplex
>> Done
>>
>> [OVS on host]
>> Program received signal SIGSEGV, Segmentation fault.
>> rte_memcpy (n=2056, src=0xc, dst=0x7ff4d5247000) at rte_memcpy.h
>
> Interesting, so it bypasses the above check since desc->len is non-zero
> while desc->addr is zero. The size (2056) also looks weird.
>
> Do you mind to check this issue a bit deeper, say why desc->addr is
> zero, however, desc->len is not?
OK. I checked this few more times. Actually, I see, that desc->addr is
not zero. All desc memory looks like some rubbish:
<-->
(gdb)
#3 copy_desc_to_mbuf (mbuf_pool=0x7fe9da9f4480, desc_idx=65363,
m=0x7fe9db269400, vq=0x7fe9fff7bac0, dev=0x7fe9fff7cbc0)
desc = 0x2aabc00ff530
desc_addr = 0
mbuf_offset = 0
prev = 0x7fe9db269400
nr_desc = 1
desc_offset = 12
cur = 0x7fe9db269400
hdr = 0x0
desc_avail = 1012591375
mbuf_avail = 1526
cpy_len = 1526
(gdb) p *desc
$2 = {addr = 8507655620301055744, len = 1012591387, flags = 3845, next = 48516}
<-->
And 'desc_addr' equals zero because 'gpa_to_vva' just can't map this huge
address to host's.
Scenario was the same. SIGSEGV received right after 'port start all'.
Another thought:
Actually, there is a race window between 'memset' in guest and reading
of 'desc->len' and 'desc->addr' on host. So, it's possible to read non
zero 'len' and zero 'addr' right after that. But you're right, this
case should be very rare.
>
>> (gdb) bt
>> #0 rte_memcpy (n=2056, src=0xc, dst=0x7ff4d5247000)
>> #1 copy_desc_to_mbuf
>> #2 rte_vhost_dequeue_burst
>> #3 netdev_dpdk_vhost_rxq_recv
>> ...
>>
>> (gdb) bt full
>> #0 rte_memcpy
>> ...
>> #1 copy_desc_to_mbuf
>> desc_addr = 0
>> mbuf_offset = 0
>> desc_offset = 12
>> ...
>> <>
>>
>> Fix that by checking addresses of descriptors before using them.
>>
>> Note: For mergeable buffers this patch checks only guest's address for
>> zero, but in non-meargeable case host's address checked. This is done
>> because checking of host's address in mergeable case requires additional
>> refactoring to keep virtqueue in consistent state in case of error.
>>
>> Signed-off-by: Ilya Maximets
>> ---
>>
>> Actually, current virtio implementation looks broken for me. Because
>> 'virtio_dev_start' breaks virtqueue while it still available from the vhost
>> side.
>
> Yes, this sounds buggy. Maybe we could not reset the avail idx, in such
> case vhost dequeue/enqueue will just return as there are no more packets
> to dequeue and no more space to enqueue, respectively?
Maybe this will be a good fix for virtio because vhost will not try to receive
from wrong descriptors. But this will not help if vhost already tries to receive
something in time of guest's reconfiguration.
Best regards, Ilya Maximets.
[dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type from data
Hi Andrey,
On 07/06/2016 01:59 PM, Chilikin, Andrey wrote:
> Hi Oliver,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
>> Sent: Wednesday, July 6, 2016 8:43 AM
>> To: Liang, Cunming ; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type
>> from data
>>
>> Hi Cunming,
>>
>> On 07/06/2016 08:44 AM, Liang, Cunming wrote:
>>> Hi Olivier,
>>>
>>> On 7/5/2016 11:41 PM, Olivier Matz wrote:
Introduce the function rte_pktmbuf_get_ptype() that parses a mbuf and
returns its packet type. For now, the following packet types are
parsed:
L2: Ether
L3: IPv4, IPv6
L4: TCP, UDP, SCTP
The goal here is to provide a reference implementation for packet
type parsing. This function will be used by testpmd in next commits,
allowing to compare its result with the value given by the hardware.
This function will also be useful when implementing Rx offload
support in virtio pmd. Indeed, the virtio protocol gives the csum
start and offset, but it does not give the L4 protocol nor it tells
if the checksum is relevant for inner or outer. This information has
to be known to properly set the ol_flags in mbuf.
Signed-off-by: Didier Pallard
Signed-off-by: Jean Dao
Signed-off-by: Olivier Matz
---
doc/guides/rel_notes/release_16_11.rst | 5 +
lib/librte_mbuf/Makefile | 5 +-
lib/librte_mbuf/rte_mbuf_ptype.c | 234
+
lib/librte_mbuf/rte_mbuf_ptype.h | 43 ++
lib/librte_mbuf/rte_mbuf_version.map | 1 +
5 files changed, 286 insertions(+), 2 deletions(-)
create mode 100644 lib/librte_mbuf/rte_mbuf_ptype.c
[...]
+
+/* parse mbuf data to get packet type */ uint32_t
+rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
+struct rte_mbuf_hdr_lens *hdr_lens) {
+struct rte_mbuf_hdr_lens local_hdr_lens;
+const struct ether_hdr *eh;
+struct ether_hdr eh_copy;
+uint32_t pkt_type = RTE_PTYPE_L2_ETHER;
+uint32_t off = 0;
+uint16_t proto;
+
+if (hdr_lens == NULL)
+hdr_lens = &local_hdr_lens;
+
+eh = rte_pktmbuf_read(m, off, sizeof(*eh), &eh_copy);
+if (unlikely(eh == NULL))
+return 0;
+proto = eh->ether_type;
+off = sizeof(*eh);
+hdr_lens->l2_len = off;
+
+if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
+const struct ipv4_hdr *ip4h;
+struct ipv4_hdr ip4h_copy;
+
+ip4h = rte_pktmbuf_read(m, off, sizeof(*ip4h), &ip4h_copy);
+if (unlikely(ip4h == NULL))
+return pkt_type;
+
+pkt_type |= ptype_l3_ip(ip4h->version_ihl);
+hdr_lens->l3_len = ip4_hlen(ip4h);
+off += hdr_lens->l3_len;
+if (ip4h->fragment_offset &
+rte_cpu_to_be_16(IPV4_HDR_OFFSET_MASK |
+IPV4_HDR_MF_FLAG)) {
+pkt_type |= RTE_PTYPE_L4_FRAG;
+hdr_lens->l4_len = 0;
+return pkt_type;
+}
+proto = ip4h->next_proto_id;
+pkt_type |= ptype_l4(proto);
+} else if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv6)) {
+const struct ipv6_hdr *ip6h;
+struct ipv6_hdr ip6h_copy;
+int frag = 0;
+
+ip6h = rte_pktmbuf_read(m, off, sizeof(*ip6h), &ip6h_copy);
+if (unlikely(ip6h == NULL))
+return pkt_type;
+
+proto = ip6h->proto;
+hdr_lens->l3_len = sizeof(*ip6h);
+off += hdr_lens->l3_len;
+pkt_type |= ptype_l3_ip6(proto);
+if ((pkt_type & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV6_EXT) {
+proto = skip_ip6_ext(proto, m, &off, &frag);
+hdr_lens->l3_len = off - hdr_lens->l2_len;
+}
+if (proto == 0)
+return pkt_type;
+if (frag) {
+pkt_type |= RTE_PTYPE_L4_FRAG;
+hdr_lens->l4_len = 0;
+return pkt_type;
+}
+pkt_type |= ptype_l4(proto);
+}
+
+if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_UDP) {
+hdr_lens->l4_len = sizeof(struct udp_hdr);
+} else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_TCP) {
+const struct tcp_hdr *th;
+struct tcp_hdr th_copy;
+
+th = rte_pktmbuf_read(m, off, sizeof(*th), &th_copy);
+if (unlikely(th == NULL))
+return pkt_type & (RTE_PTYPE_L2_MASK |
+RTE_PTYPE_L3_MASK);
+hdr_lens->l4_len = (th->data_off & 0xf0) >> 2;
+} else if ((pkt_type & RT
[dpdk-dev] [PATCH 01/18] doc: add template for release notes 16.11
Hi John, On 07/06/2016 01:48 PM, Mcnamara, John wrote: >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz >> Sent: Tuesday, July 5, 2016 4:42 PM >> To: dev at dpdk.org >> Subject: [dpdk-dev] [PATCH 01/18] doc: add template for release notes >> 16.11 > > Hi, > > This is useful but it is probably a little bit early since it should include > the shared lib versions from the final 16.07 release notes. > > Also, is it intentionally part of a patchset for a "software parser for > packet type"? It should probably be separate. Sorry, I should have add an explanation: I just wanted to have the patchset applying on current head (16.07-rc1) without conflicts. Indeed some commits add some entries in the release note. I agree, at the end, this commit should not be part of the patchset. Regards, Olivier
[dpdk-dev] [PATCH 3/3] scripts: check headline of drivers commits
Thomas, On Wed, Jul 06, 2016 at 12:38:50PM +0200, Thomas Monjalon wrote: > From: Nelio Laranjeiro > > A driver patch under net should start with "net/" or if > a patch touch multiple drivers, it should only start with "net:". > The same apply for crypto. > A patch touching all drivers (net + crypto) should start with "drivers:". > > Longer prefixes like "net/mlx:" (for mlx4/mlx5) or "net/e1000/base:" are > handled by not checking the colon. > > Signed-off-by: Nelio Laranjeiro > Signed-off-by: Thomas Monjalon > --- > scripts/check-git-log.sh | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh > index 833aa39..3f3cf19 100755 > --- a/scripts/check-git-log.sh > +++ b/scripts/check-git-log.sh > @@ -70,6 +70,23 @@ bad=$(echo "$headlines" | grep --color=always \ > | sed 's,^,\t,') > [ -z "$bad" ] || printf "Wrong headline format:\n$bad\n" > > +# check headline prefix when touching only drivers/, e.g. net/ > +bad=$(for commit in $commits ; do > + headline=$(git log --format='%s' -1 $commit) > + files=$(git diff-tree --no-commit-id --name-only -r $commit) > + [ -z "$(echo "$files" | grep -v '^drivers/')" ] || continue > + driversgrp=$(echo "$files" | cut -d "/" -f 2 | sort -u) > + drivers=$(echo "$files" | cut -d "/" -f 2,3 | sort -u) > + if [ $(echo "$driversgrp" | wc -l) -gt 1 ] ; then > + bad=$(echo "$headline" | grep -v '^drivers:') I think you forgot the '$' for drivers in the line just above. > + elif [ $(echo "$drivers" | wc -l) -gt 1 ] ; then > + bad=$(echo "$headline" | grep -v "^$driversgrp") > + else > + bad=$(echo "$headline" | grep -v "^$drivers") > + fi > +done | sed 's,^,\t,') > +[ -z "$bad" ] || printf "Wrong headline prefix:\n$bad\n" > + > # check headline label for common typos > bad=$(echo "$headlines" | grep --color=always \ > -e '^example[:/]' \ > -- > 2.7.0 Otherwise it seems good. Regards, -- N?lio Laranjeiro 6WIND
[dpdk-dev] [PATCH] librte_pmd_bond: fix exported symbol versioning
The older versions of rte_eth_bond_8023ad_conf_get and
rte_eth_bond_8023ad_setup were available in the old way since 2.0 - at
least according to the map file.
But versioning in the code was set to 16.04.
That breaks compatibility checks for 2.0 on that library.
For example with the dpdk abi checker:
http://people.canonical.com/~paelzer/compat_report.html
To fix, version the old symbols on the 2.0 version as they were
initially added to the map file.
See http://people.canonical.com/~paelzer/compat_report.html
Fixes: dc40f17a ("net/bonding: allow external state machine in mode 4")
Signed-off-by: Christian Ehrhardt
---
drivers/net/bonding/rte_eth_bond_8023ad.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index 48a50e4..2f7ae70 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -1068,7 +1068,7 @@ bond_mode_8023ad_conf_assign(struct mode8023ad_private
*mode4,
}
static void
-bond_mode_8023ad_setup_v1604(struct rte_eth_dev *dev,
+bond_mode_8023ad_setup_v20(struct rte_eth_dev *dev,
struct rte_eth_bond_8023ad_conf *conf)
{
struct rte_eth_bond_8023ad_conf def_conf;
@@ -1214,7 +1214,7 @@ free_out:
}
int
-rte_eth_bond_8023ad_conf_get_v1604(uint8_t port_id,
+rte_eth_bond_8023ad_conf_get_v20(uint8_t port_id,
struct rte_eth_bond_8023ad_conf *conf)
{
struct rte_eth_dev *bond_dev;
@@ -1229,7 +1229,7 @@ rte_eth_bond_8023ad_conf_get_v1604(uint8_t port_id,
bond_mode_8023ad_conf_get(bond_dev, conf);
return 0;
}
-VERSION_SYMBOL(rte_eth_bond_8023ad_conf_get, _v1604, 16.04);
+VERSION_SYMBOL(rte_eth_bond_8023ad_conf_get, _v20, 2.0);
int
rte_eth_bond_8023ad_conf_get_v1607(uint8_t port_id,
@@ -1278,7 +1278,7 @@ bond_8023ad_setup_validate(uint8_t port_id,
}
int
-rte_eth_bond_8023ad_setup_v1604(uint8_t port_id,
+rte_eth_bond_8023ad_setup_v20(uint8_t port_id,
struct rte_eth_bond_8023ad_conf *conf)
{
struct rte_eth_dev *bond_dev;
@@ -1289,11 +1289,11 @@ rte_eth_bond_8023ad_setup_v1604(uint8_t port_id,
return err;
bond_dev = &rte_eth_devices[port_id];
- bond_mode_8023ad_setup_v1604(bond_dev, conf);
+ bond_mode_8023ad_setup_v20(bond_dev, conf);
return 0;
}
-VERSION_SYMBOL(rte_eth_bond_8023ad_setup, _v1604, 16.04);
+VERSION_SYMBOL(rte_eth_bond_8023ad_setup, _v20, 2.0);
int
rte_eth_bond_8023ad_setup_v1607(uint8_t port_id,
--
2.7.4
[dpdk-dev] [PATCH v3 1/3] kasumi: add new KASUMI PMD
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, July 06, 2016 12:26 PM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Cc: Doherty, Declan; Jain, Deepak K
> Subject: Re: [dpdk-dev] [PATCH v3 1/3] kasumi: add new KASUMI PMD
>
> On 6/20/2016 3:40 PM, Pablo de Lara wrote:
> > Added new SW PMD which makes use of the libsso_kasumi SW library,
> > which provides wireless algorithms KASUMI F8 and F9
> > in software.
> >
> > This PMD supports cipher-only, hash-only and chained operations
> > ("cipher then hash" and "hash then cipher") of the following
> > algorithms:
> > - RTE_CRYPTO_SYM_CIPHER_KASUMI_F8
> > - RTE_CRYPTO_SYM_AUTH_KASUMI_F9
> >
> > Signed-off-by: Pablo de Lara
> > Acked-by: Jain, Deepak K
>
> ...
>
> > --- a/lib/librte_cryptodev/rte_cryptodev.h
> > +++ b/lib/librte_cryptodev/rte_cryptodev.h
> > @@ -59,12 +59,15 @@ extern "C" {
> > /**< Intel QAT Symmetric Crypto PMD device name */
> > #define CRYPTODEV_NAME_SNOW3G_PMD ("cryptodev_snow3g_pmd")
> > /**< SNOW 3G PMD device name */
> > +#define CRYPTODEV_NAME_KASUMI_PMD ("cryptodev_kasumi_pmd")
> > +/**< KASUMI PMD device name */
> >
> > /** Crypto device type */
> > enum rte_cryptodev_type {
> > RTE_CRYPTODEV_NULL_PMD = 1, /**< Null crypto PMD */
> > RTE_CRYPTODEV_AESNI_GCM_PMD,/**< AES-NI GCM PMD */
> > RTE_CRYPTODEV_AESNI_MB_PMD, /**< AES-NI multi buffer PMD
> */
> > + RTE_CRYPTODEV_KASUMI_PMD, /**< KASUMI PMD */
> Does adding new field into middle cause a ABI breakage?
> Since now value of below fields changed.
Right! Thanks for the catch, will send a patch to fix that.
>
> Btw, librte_cryptodev is not listed in release notes, "shared library
> versions" section, not sure if this is intentional.
>
> > RTE_CRYPTODEV_QAT_SYM_PMD, /**< QAT PMD Symmetric
> Crypto */
> > RTE_CRYPTODEV_SNOW3G_PMD, /**< SNOW 3G PMD */
> > };
>
> ...
[dpdk-dev] about rx checksum flags
Hi Olivier, Just to confirm , is this rx checksum patch already submitted in the DPDK ML? We would like to use these flags to speed up the tunneling in OVS. Regards _Sugesh > -Original Message- > From: Chandran, Sugesh > Sent: Friday, June 10, 2016 5:16 PM > To: 'Olivier Matz' ; Ananyev, Konstantin > ; Stephen Hemminger > > Cc: Yuanhan Liu ; dev at dpdk.org; Richardson, > Bruce ; Adrien Mazarguil > ; Tan, Jianfeng > Subject: RE: [dpdk-dev] about rx checksum flags > > > > Regards > _Sugesh > > > -Original Message- > > From: Olivier Matz [mailto:olivier.matz at 6wind.com] > > Sent: Wednesday, June 8, 2016 2:02 PM > > To: Chandran, Sugesh ; Ananyev, Konstantin > > ; Stephen Hemminger > > > > Cc: Yuanhan Liu ; dev at dpdk.org; > > Richardson, Bruce ; Adrien Mazarguil > > ; Tan, Jianfeng > > Subject: Re: [dpdk-dev] about rx checksum flags > > > > Hi, > > > > On 06/08/2016 10:22 AM, Chandran, Sugesh wrote: > > >>> I guess the IP checksum also important as L4. In some cases, UDP > > >>> checksum is zero and no need to validate it. But Ip checksum is > > >>> present on all the packets and that must be validated all the time. > > >>> At higher packet rate, the ip checksum offload can offer slight > > >>> performance > > >> improvement. What do you think?? > > >>> > > >> > > >> Agree, in some situations (and this is even more true with packet > > >> types / smartnics), the application could process without accessing > > >> the packet data if we keep the IP cksum flags. > > > [Sugesh] True, If that's the case, Will you considering to implement > > > IP checksum flags as well along with L4? > > > As you said , this will be useful when we offload packet lookup > > > itself into the NICs(May be when using Flow director) ? > > > > Yes, I plan to implement the same rx status flags (good, bad, unknown, > > none) for rx IP checksum too. > [Sugesh] That's great!, Thank you Olivier. > > > > Regards, > > Olivier
[dpdk-dev] [PATCH v4] eal/linuxapp: fix resource leak
Current code does not munmap 'hugepage' mapping (hugepage info file) on
function exit, leaking resources.
Coverity issue: 97920
Fixes: b6a468ad41d5 ("memory: add --socket-mem option")
Signed-off-by: Daniel Mrzyglod
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 5578c25..b663244 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -1136,7 +1136,7 @@ int
rte_eal_hugepage_init(void)
{
struct rte_mem_config *mcfg;
- struct hugepage_file *hugepage, *tmp_hp = NULL;
+ struct hugepage_file *hugepage = NULL, *tmp_hp = NULL;
struct hugepage_info used_hp[MAX_HUGEPAGE_SIZES];
uint64_t memory[RTE_MAX_NUMA_NODES];
@@ -1479,14 +1479,19 @@ rte_eal_hugepage_init(void)
"of memory.\n",
i, nr_hugefiles, RTE_STR(CONFIG_RTE_MAX_MEMSEG),
RTE_MAX_MEMSEG);
- return -ENOMEM;
+ goto fail;
}
+ munmap(hugepage, nr_hugefiles * sizeof(struct hugepage_file));
+
return 0;
fail:
huge_recover_sigbus();
free(tmp_hp);
+ if (hugepage != NULL)
+ munmap(hugepage, nr_hugefiles * sizeof(struct hugepage_file));
+
return -1;
}
--
2.7.4
[dpdk-dev] [PATCH 3/3] scripts: check headline of drivers commits
From: Nelio Laranjeiro A driver patch under net should start with "net/" or if a patch touch multiple drivers, it should only start with "net:". The same apply for crypto. A patch touching all drivers (net + crypto) should start with "drivers:". Longer prefixes like "net/mlx:" (for mlx4/mlx5) or "net/e1000/base:" are handled by not checking the colon. Signed-off-by: Nelio Laranjeiro Signed-off-by: Thomas Monjalon --- scripts/check-git-log.sh | 17 + 1 file changed, 17 insertions(+) diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh index 833aa39..3f3cf19 100755 --- a/scripts/check-git-log.sh +++ b/scripts/check-git-log.sh @@ -70,6 +70,23 @@ bad=$(echo "$headlines" | grep --color=always \ | sed 's,^,\t,') [ -z "$bad" ] || printf "Wrong headline format:\n$bad\n" +# check headline prefix when touching only drivers/, e.g. net/ +bad=$(for commit in $commits ; do + headline=$(git log --format='%s' -1 $commit) + files=$(git diff-tree --no-commit-id --name-only -r $commit) + [ -z "$(echo "$files" | grep -v '^drivers/')" ] || continue + driversgrp=$(echo "$files" | cut -d "/" -f 2 | sort -u) + drivers=$(echo "$files" | cut -d "/" -f 2,3 | sort -u) + if [ $(echo "$driversgrp" | wc -l) -gt 1 ] ; then + bad=$(echo "$headline" | grep -v '^drivers:') + elif [ $(echo "$drivers" | wc -l) -gt 1 ] ; then + bad=$(echo "$headline" | grep -v "^$driversgrp") + else + bad=$(echo "$headline" | grep -v "^$drivers") + fi +done | sed 's,^,\t,') +[ -z "$bad" ] || printf "Wrong headline prefix:\n$bad\n" + # check headline label for common typos bad=$(echo "$headlines" | grep --color=always \ -e '^example[:/]' \ -- 2.7.0
[dpdk-dev] [PATCH 2/3] scripts: reduce line size of commit checks
Small cleanup to comply with the 80 chars limit.
Signed-off-by: Thomas Monjalon
---
scripts/check-git-log.sh | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh
index a24f101..833aa39 100755
--- a/scripts/check-git-log.sh
+++ b/scripts/check-git-log.sh
@@ -52,8 +52,9 @@ range=${1:-origin/master..}
commits=$(git log --format='%h' $range)
headlines=$(git log --format='%s' $range)
bodylines=$(git log --format='%b' $range)
-tags=$(git log --format='%b' $range | grep -i -e 'by *:' -e 'fix.*:')
fixes=$(git log --format='%h %s' $range | grep -i ': *fix' | cut -d' ' -f1)
+tags=$(git log --format='%b' $range | grep -i -e 'by *:' -e 'fix.*:')
+bytag='\(Reported\|Suggested\|Signed-off\|Acked\|Reviewed\|Tested\)-by:'
# check headline format (spacing, no punctuation, no code)
bad=$(echo "$headlines" | grep --color=always \
@@ -108,11 +109,15 @@ bad=$(echo "$headlines" | grep -E --color=always \
[ -z "$bad" ] || printf "Wrong headline lowercase:\n$bad\n"
# check headline length (60 max)
-bad=$(echo "$headlines" | awk 'length>60 {print}' | sed 's,^,\t,')
+bad=$(echo "$headlines" |
+ awk 'length>60 {print}' |
+ sed 's,^,\t,')
[ -z "$bad" ] || printf "Headline too long:\n$bad\n"
# check body lines length (75 max)
-bad=$(echo "$bodylines" | grep -v '^Fixes:' | awk 'length>75 {print}' | sed
's,^,\t,')
+bad=$(echo "$bodylines" | grep -v '^Fixes:' |
+ awk 'length>75 {print}' |
+ sed 's,^,\t,')
[ -z "$bad" ] || printf "Line too long:\n$bad\n"
# check starting commit message with "It"
@@ -124,7 +129,7 @@ done | sed 's,^,\t,')
# check tags spelling
bad=$(echo "$tags" |
- grep -v
'^\(Reported\|Suggested\|Signed-off\|Acked\|Reviewed\|Tested\)-by: [^,]*
<.*@.*>$' |
+ grep -v "^$bytag [^,]* <.*@.*>$" |
grep -v '^Fixes: [0-9a-f]\{7\}[0-9a-f]* (".*")$' |
sed 's,^.,\t&,')
[ -z "$bad" ] || printf "Wrong tag:\n$bad\n"
--
2.7.0
[dpdk-dev] [PATCH 1/3] scripts: check spacing after commit references
A blank line between "Fixes" and "Signed-off-by" helps to separate information in blocks. Signed-off-by: Thomas Monjalon --- scripts/check-git-log.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh index c7fc0e4..a24f101 100755 --- a/scripts/check-git-log.sh +++ b/scripts/check-git-log.sh @@ -129,6 +129,12 @@ bad=$(echo "$tags" | sed 's,^.,\t&,') [ -z "$bad" ] || printf "Wrong tag:\n$bad\n" +# check blank line after last Fixes: tag +bad=$(echo "$bodylines" | + sed -n 'N;/\nFixes:/D;/\n$/D;/^Fixes:/P' | + sed 's,^.,\t&,') +[ -z "$bad" ] || printf "Missing blank line after 'Fixes' tag:\n$bad\n" + # check missing Fixes: tag bad=$(for fix in $fixes ; do git log --format='%b' -1 $fix | grep -q '^Fixes: ' || -- 2.7.0
[dpdk-dev] [PATCH 0/3] more commits checks
The script check-git-log.sh helps to keep a consistent git history. Scrolling/parsing the history is easier when we are used to some rules. N?lio Laranjeiro (1): scripts: check headline of drivers commits Thomas Monjalon (2): scripts: check spacing after commit references scripts: reduce line size of commit checks scripts/check-git-log.sh | 36 1 file changed, 32 insertions(+), 4 deletions(-) -- 2.7.0
[dpdk-dev] [PATCH v3 1/3] kasumi: add new KASUMI PMD
On 6/20/2016 3:40 PM, Pablo de Lara wrote:
> Added new SW PMD which makes use of the libsso_kasumi SW library,
> which provides wireless algorithms KASUMI F8 and F9
> in software.
>
> This PMD supports cipher-only, hash-only and chained operations
> ("cipher then hash" and "hash then cipher") of the following
> algorithms:
> - RTE_CRYPTO_SYM_CIPHER_KASUMI_F8
> - RTE_CRYPTO_SYM_AUTH_KASUMI_F9
>
> Signed-off-by: Pablo de Lara
> Acked-by: Jain, Deepak K
...
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -59,12 +59,15 @@ extern "C" {
> /**< Intel QAT Symmetric Crypto PMD device name */
> #define CRYPTODEV_NAME_SNOW3G_PMD("cryptodev_snow3g_pmd")
> /**< SNOW 3G PMD device name */
> +#define CRYPTODEV_NAME_KASUMI_PMD("cryptodev_kasumi_pmd")
> +/**< KASUMI PMD device name */
>
> /** Crypto device type */
> enum rte_cryptodev_type {
> RTE_CRYPTODEV_NULL_PMD = 1, /**< Null crypto PMD */
> RTE_CRYPTODEV_AESNI_GCM_PMD,/**< AES-NI GCM PMD */
> RTE_CRYPTODEV_AESNI_MB_PMD, /**< AES-NI multi buffer PMD */
> + RTE_CRYPTODEV_KASUMI_PMD, /**< KASUMI PMD */
Does adding new field into middle cause a ABI breakage?
Since now value of below fields changed.
Btw, librte_cryptodev is not listed in release notes, "shared library
versions" section, not sure if this is intentional.
> RTE_CRYPTODEV_QAT_SYM_PMD, /**< QAT PMD Symmetric Crypto */
> RTE_CRYPTODEV_SNOW3G_PMD, /**< SNOW 3G PMD */
> };
...
[dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type from data
Hi Oliver,
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, July 6, 2016 1:09 PM
> To: Chilikin, Andrey ; Liang, Cunming
> ; dev at dpdk.org
> Cc: Ananyev, Konstantin
> Subject: Re: [dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type
> from data
>
> Hi Andrey,
>
> On 07/06/2016 01:59 PM, Chilikin, Andrey wrote:
> > Hi Oliver,
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> >> Sent: Wednesday, July 6, 2016 8:43 AM
> >> To: Liang, Cunming ; dev at dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH 05/18] mbuf: add function to get
> >> packet type from data
> >>
> >> Hi Cunming,
> >>
> >> On 07/06/2016 08:44 AM, Liang, Cunming wrote:
> >>> Hi Olivier,
> >>>
> >>> On 7/5/2016 11:41 PM, Olivier Matz wrote:
> Introduce the function rte_pktmbuf_get_ptype() that parses a mbuf
> and returns its packet type. For now, the following packet types
> are
> parsed:
> L2: Ether
> L3: IPv4, IPv6
> L4: TCP, UDP, SCTP
>
> The goal here is to provide a reference implementation for packet
> type parsing. This function will be used by testpmd in next
> commits, allowing to compare its result with the value given by the
> hardware.
>
> This function will also be useful when implementing Rx offload
> support in virtio pmd. Indeed, the virtio protocol gives the csum
> start and offset, but it does not give the L4 protocol nor it tells
> if the checksum is relevant for inner or outer. This information
> has to be known to properly set the ol_flags in mbuf.
>
> Signed-off-by: Didier Pallard
> Signed-off-by: Jean Dao
> Signed-off-by: Olivier Matz
> ---
> doc/guides/rel_notes/release_16_11.rst | 5 +
> lib/librte_mbuf/Makefile | 5 +-
> lib/librte_mbuf/rte_mbuf_ptype.c | 234
> +
> lib/librte_mbuf/rte_mbuf_ptype.h | 43 ++
> lib/librte_mbuf/rte_mbuf_version.map | 1 +
> 5 files changed, 286 insertions(+), 2 deletions(-)
> create mode 100644 lib/librte_mbuf/rte_mbuf_ptype.c
>
> [...]
> +
> +/* parse mbuf data to get packet type */ uint32_t
> +rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
> +struct rte_mbuf_hdr_lens *hdr_lens) {
> +struct rte_mbuf_hdr_lens local_hdr_lens;
> +const struct ether_hdr *eh;
> +struct ether_hdr eh_copy;
> +uint32_t pkt_type = RTE_PTYPE_L2_ETHER;
> +uint32_t off = 0;
> +uint16_t proto;
> +
> +if (hdr_lens == NULL)
> +hdr_lens = &local_hdr_lens;
> +
> +eh = rte_pktmbuf_read(m, off, sizeof(*eh), &eh_copy);
> +if (unlikely(eh == NULL))
> +return 0;
> +proto = eh->ether_type;
> +off = sizeof(*eh);
> +hdr_lens->l2_len = off;
> +
> +if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
> +const struct ipv4_hdr *ip4h;
> +struct ipv4_hdr ip4h_copy;
> +
> +ip4h = rte_pktmbuf_read(m, off, sizeof(*ip4h), &ip4h_copy);
> +if (unlikely(ip4h == NULL))
> +return pkt_type;
> +
> +pkt_type |= ptype_l3_ip(ip4h->version_ihl);
> +hdr_lens->l3_len = ip4_hlen(ip4h);
> +off += hdr_lens->l3_len;
> +if (ip4h->fragment_offset &
> +rte_cpu_to_be_16(IPV4_HDR_OFFSET_MASK |
> +IPV4_HDR_MF_FLAG)) {
> +pkt_type |= RTE_PTYPE_L4_FRAG;
> +hdr_lens->l4_len = 0;
> +return pkt_type;
> +}
> +proto = ip4h->next_proto_id;
> +pkt_type |= ptype_l4(proto);
> +} else if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv6)) {
> +const struct ipv6_hdr *ip6h;
> +struct ipv6_hdr ip6h_copy;
> +int frag = 0;
> +
> +ip6h = rte_pktmbuf_read(m, off, sizeof(*ip6h), &ip6h_copy);
> +if (unlikely(ip6h == NULL))
> +return pkt_type;
> +
> +proto = ip6h->proto;
> +hdr_lens->l3_len = sizeof(*ip6h);
> +off += hdr_lens->l3_len;
> +pkt_type |= ptype_l3_ip6(proto);
> +if ((pkt_type & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV6_EXT)
> {
> +proto = skip_ip6_ext(proto, m, &off, &frag);
> +hdr_lens->l3_len = off - hdr_lens->l2_len;
> +}
> +if (proto == 0)
> +return pkt_type;
> +if (frag) {
> +pkt_type |= RTE_PTYPE_L4_FRAG;
> +hdr_lens->l4_len = 0;
> +return pkt_type;
> +}
> +pkt_type |= ptype_l4(proto);
> +}
> +
> +if ((pkt_type &
[dpdk-dev] [PATCH 3/3] scripts: check headline of drivers commits
On Wed, Jul 06, 2016 at 12:38:50PM +0200, Thomas Monjalon wrote: > From: Nelio Laranjeiro > > A driver patch under net should start with "net/" or if > a patch touch multiple drivers, it should only start with "net:". > The same apply for crypto. > A patch touching all drivers (net + crypto) should start with "drivers:". > > Longer prefixes like "net/mlx:" (for mlx4/mlx5) or "net/e1000/base:" are > handled by not checking the colon. > > Signed-off-by: Nelio Laranjeiro > Signed-off-by: Thomas Monjalon > --- > scripts/check-git-log.sh | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh > index 833aa39..3f3cf19 100755 > --- a/scripts/check-git-log.sh > +++ b/scripts/check-git-log.sh > @@ -70,6 +70,23 @@ bad=$(echo "$headlines" | grep --color=always \ > | sed 's,^,\t,') > [ -z "$bad" ] || printf "Wrong headline format:\n$bad\n" > > +# check headline prefix when touching only drivers/, e.g. net/ > +bad=$(for commit in $commits ; do > + headline=$(git log --format='%s' -1 $commit) > + files=$(git diff-tree --no-commit-id --name-only -r $commit) > + [ -z "$(echo "$files" | grep -v '^drivers/')" ] || continue Given the preference for including documentation in with the code changes, we should perhaps exclude any doc changes when making this check. /Bruce
[dpdk-dev] [PATCH v4] Pci: Add the class_id support
On 6/14/2016 3:52 PM, Thomas Monjalon wrote: > 2016-05-24 20:50, Ziye Yang: >> This patch is used to add the class_id (class_code, >> subclass_code, programming_interface) support for >> pci_device probe. With this patch, it will be >> flexible for users to probe a class of devices >> by class_id. >> >> >> Signed-off-by: Ziye Yang > > Applied, thanks > Hi Thomas, Ziye, Is modification in public "struct rte_pci_id" is a ABI break? If so, it requires eal LIBABIVER increase and release notes update. Regards, ferruh
[dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type from data
Hi Oliver,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Wednesday, July 6, 2016 8:43 AM
> To: Liang, Cunming ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type
> from data
>
> Hi Cunming,
>
> On 07/06/2016 08:44 AM, Liang, Cunming wrote:
> > Hi Olivier,
> >
> > On 7/5/2016 11:41 PM, Olivier Matz wrote:
> >> Introduce the function rte_pktmbuf_get_ptype() that parses a mbuf and
> >> returns its packet type. For now, the following packet types are
> >> parsed:
> >> L2: Ether
> >> L3: IPv4, IPv6
> >> L4: TCP, UDP, SCTP
> >>
> >> The goal here is to provide a reference implementation for packet
> >> type parsing. This function will be used by testpmd in next commits,
> >> allowing to compare its result with the value given by the hardware.
> >>
> >> This function will also be useful when implementing Rx offload
> >> support in virtio pmd. Indeed, the virtio protocol gives the csum
> >> start and offset, but it does not give the L4 protocol nor it tells
> >> if the checksum is relevant for inner or outer. This information has
> >> to be known to properly set the ol_flags in mbuf.
> >>
> >> Signed-off-by: Didier Pallard
> >> Signed-off-by: Jean Dao
> >> Signed-off-by: Olivier Matz
> >> ---
> >> doc/guides/rel_notes/release_16_11.rst | 5 +
> >> lib/librte_mbuf/Makefile | 5 +-
> >> lib/librte_mbuf/rte_mbuf_ptype.c | 234
> >> +
> >> lib/librte_mbuf/rte_mbuf_ptype.h | 43 ++
> >> lib/librte_mbuf/rte_mbuf_version.map | 1 +
> >> 5 files changed, 286 insertions(+), 2 deletions(-)
> >> create mode 100644 lib/librte_mbuf/rte_mbuf_ptype.c
> >>
> >> [...]
> >> +
> >> +/* parse mbuf data to get packet type */ uint32_t
> >> +rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
> >> +struct rte_mbuf_hdr_lens *hdr_lens) {
> >> +struct rte_mbuf_hdr_lens local_hdr_lens;
> >> +const struct ether_hdr *eh;
> >> +struct ether_hdr eh_copy;
> >> +uint32_t pkt_type = RTE_PTYPE_L2_ETHER;
> >> +uint32_t off = 0;
> >> +uint16_t proto;
> >> +
> >> +if (hdr_lens == NULL)
> >> +hdr_lens = &local_hdr_lens;
> >> +
> >> +eh = rte_pktmbuf_read(m, off, sizeof(*eh), &eh_copy);
> >> +if (unlikely(eh == NULL))
> >> +return 0;
> >> +proto = eh->ether_type;
> >> +off = sizeof(*eh);
> >> +hdr_lens->l2_len = off;
> >> +
> >> +if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
> >> +const struct ipv4_hdr *ip4h;
> >> +struct ipv4_hdr ip4h_copy;
> >> +
> >> +ip4h = rte_pktmbuf_read(m, off, sizeof(*ip4h), &ip4h_copy);
> >> +if (unlikely(ip4h == NULL))
> >> +return pkt_type;
> >> +
> >> +pkt_type |= ptype_l3_ip(ip4h->version_ihl);
> >> +hdr_lens->l3_len = ip4_hlen(ip4h);
> >> +off += hdr_lens->l3_len;
> >> +if (ip4h->fragment_offset &
> >> +rte_cpu_to_be_16(IPV4_HDR_OFFSET_MASK |
> >> +IPV4_HDR_MF_FLAG)) {
> >> +pkt_type |= RTE_PTYPE_L4_FRAG;
> >> +hdr_lens->l4_len = 0;
> >> +return pkt_type;
> >> +}
> >> +proto = ip4h->next_proto_id;
> >> +pkt_type |= ptype_l4(proto);
> >> +} else if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv6)) {
> >> +const struct ipv6_hdr *ip6h;
> >> +struct ipv6_hdr ip6h_copy;
> >> +int frag = 0;
> >> +
> >> +ip6h = rte_pktmbuf_read(m, off, sizeof(*ip6h), &ip6h_copy);
> >> +if (unlikely(ip6h == NULL))
> >> +return pkt_type;
> >> +
> >> +proto = ip6h->proto;
> >> +hdr_lens->l3_len = sizeof(*ip6h);
> >> +off += hdr_lens->l3_len;
> >> +pkt_type |= ptype_l3_ip6(proto);
> >> +if ((pkt_type & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV6_EXT) {
> >> +proto = skip_ip6_ext(proto, m, &off, &frag);
> >> +hdr_lens->l3_len = off - hdr_lens->l2_len;
> >> +}
> >> +if (proto == 0)
> >> +return pkt_type;
> >> +if (frag) {
> >> +pkt_type |= RTE_PTYPE_L4_FRAG;
> >> +hdr_lens->l4_len = 0;
> >> +return pkt_type;
> >> +}
> >> +pkt_type |= ptype_l4(proto);
> >> +}
> >> +
> >> +if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_UDP) {
> >> +hdr_lens->l4_len = sizeof(struct udp_hdr);
> >> +} else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_TCP) {
> >> +const struct tcp_hdr *th;
> >> +struct tcp_hdr th_copy;
> >> +
> >> +th = rte_pktmbuf_read(m, off, sizeof(*th), &th_copy);
> >> +if (unlikely(th == NULL))
> >> +return pkt_type & (RTE_PTYPE_L2_MASK |
> >> +RTE_PTYPE_L3_MASK);
> >> +hdr_lens->l4_len = (th->data_off & 0xf0) >> 2;
> >> +} else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_SCTP) {
> >> +hdr_lens->l4_len
[dpdk-dev] [PATCH v2] doc: update GSG for i40e firmware version.
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ian Stokes > Sent: Wednesday, July 6, 2016 11:30 AM > To: dev at dpdk.org > Cc: Stokes, Ian > Subject: [dpdk-dev] [PATCH v2] doc: update GSG for i40e firmware version. > > Update the 'High Performance of Small Packets on 40G NIC' section of the > GSG as the firmware version referenced for a NIC using the i40e driver was > firmware version 4.2.5 which is no longer validated. Instruct users to > consult release notes for current validated firmware versions. > > Signed-off-by: Ian Stokes Acked-by: John McNamara
[dpdk-dev] [PATCH v4] eal/linuxapp: fix resource leak
On 06/07/2016 11:44, Daniel Mrzyglod wrote:
> Current code does not munmap 'hugepage' mapping (hugepage info file) on
> function exit, leaking resources.
>
> Coverity issue: 97920
> Fixes: b6a468ad41d5 ("memory: add --socket-mem option")
>
> Signed-off-by: Daniel Mrzyglod
> ---
Please next time remember to keep patch version history after the triple
dashes.
Acked-by: Sergio Gonzalez Monroy
[dpdk-dev] [PATCH 01/18] doc: add template for release notes 16.11
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz > Sent: Tuesday, July 5, 2016 4:42 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 01/18] doc: add template for release notes > 16.11 Hi, This is useful but it is probably a little bit early since it should include the shared lib versions from the final 16.07 release notes. Also, is it intentionally part of a patchset for a "software parser for packet type"? It should probably be separate. John
[dpdk-dev] [PATCH] scripts: add check for net driver names without net prefix
2016-07-06 10:25, Bruce Richardson: > On Wed, Jul 06, 2016 at 11:10:48AM +0200, Thomas Monjalon wrote: > > 2016-07-05 15:40, Bruce Richardson: > > > +# check headline label for net/ prefix if needed > > > +bad=$(echo "$headlines" | grep -E --color=always \ > > > + -e "^($(ls drivers/net | grep -v Makefile | tr '\n' '|')):" \ > > > + | sed 's,^,\t,') > > > +[ -z "$bad" ] || printf "Headline missing 'net/' prefix:\n$bad\n" > > > > This check is definitely a good idea. > > We need the same thing for crypto. > > Few nits: > > - -E is not needed for this regex > > - "/base:" cases are not handled because of the colon at the end > > of the regex. > > Good point. Easy enough to fix, I suspect. > > > - patches touching several drivers are not handled. Examples: > > "mlx:" -> "net/mlx:" > > "drivers/net:" -> "net:" > > > Yes, however, those are in the minority of cases, and we can always add > special case extra regex's for those - hardcoded like the other regex's in the > file. I did the pulling directory list so we don't have to update the checks > every time a new driver was added. Another issue: I suspect you will have false positives with librte_ring and librte_vhost. > > By the way, I am looking at an idea, that Nelio sent me, based on > > modified files. It can complete this check. > > Great. I'll look forward to seeing that. If it works out well, by all means > drop this patch. If it's not coming any time soon though, I can do a V2 of > this patch, but I won't bother right now in the expectation that a better > solution is coming. My concern is that the file-based solution will handle only the patches where every changes are in drivers/ (not config/ or anything else). I'm thinking how to merge both solutions. I'm also concerned by the time passed developing these checks ;)
[dpdk-dev] [PATCH v2] doc: update GSG for i40e firmware version.
Update the 'High Performance of Small Packets on 40G NIC' section of the GSG as the firmware version referenced for a NIC using the i40e driver was firmware version 4.2.5 which is no longer validated. Instruct users to consult release notes for current validated firmware versions. Signed-off-by: Ian Stokes --- v1 -> v2 Specificy GSG in commit subject line. Sepcify section in GSG that is updated in commit body. Remove references to FVL in GSG, replace with 'NIC using i40e driver'. --- doc/guides/linux_gsg/enable_func.rst |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst index ec0e04d..6005932 100644 --- a/doc/guides/linux_gsg/enable_func.rst +++ b/doc/guides/linux_gsg/enable_func.rst @@ -183,8 +183,7 @@ High Performance of Small Packets on 40G NIC As there might be firmware fixes for performance enhancement in latest version of firmware image, the firmware update might be needed for getting high performance. Check with the local Intel's Network Division application engineers for firmware updates. -The base driver to support firmware version of FVL3E will be integrated in the next -DPDK release, so currently the validated firmware version is 4.2.6. +Users should consult the release notes specific to a DPDK release to identify the validated firmware version for a NIC using the i40e driver. Use 16 Bytes RX Descriptor Size ~~~ -- 1.7.4.1
[dpdk-dev] [PATCH] scripts: add check for net driver names without net prefix
On Wed, Jul 06, 2016 at 11:46:23AM +0200, Thomas Monjalon wrote: > 2016-07-06 10:25, Bruce Richardson: > > On Wed, Jul 06, 2016 at 11:10:48AM +0200, Thomas Monjalon wrote: > > > 2016-07-05 15:40, Bruce Richardson: > > > > +# check headline label for net/ prefix if needed > > > > +bad=$(echo "$headlines" | grep -E --color=always \ > > > > + -e "^($(ls drivers/net | grep -v Makefile | tr '\n' '|')):" \ > > > > + | sed 's,^,\t,') > > > > +[ -z "$bad" ] || printf "Headline missing 'net/' prefix:\n$bad\n" > > > > > > This check is definitely a good idea. > > > We need the same thing for crypto. > > > Few nits: > > > - -E is not needed for this regex > > > - "/base:" cases are not handled because of the colon at the end > > > of the regex. > > > > Good point. Easy enough to fix, I suspect. > > > > > - patches touching several drivers are not handled. Examples: > > > "mlx:" -> "net/mlx:" > > > "drivers/net:" -> "net:" > > > > > Yes, however, those are in the minority of cases, and we can always add > > special case extra regex's for those - hardcoded like the other regex's in > > the > > file. I did the pulling directory list so we don't have to update the checks > > every time a new driver was added. > > Another issue: I suspect you will have false positives with librte_ring and > librte_vhost. Yep, good catch there. Need to tune up those filters if I proceed with this. > > > > By the way, I am looking at an idea, that Nelio sent me, based on > > > modified files. It can complete this check. > > > > Great. I'll look forward to seeing that. If it works out well, by all means > > drop this patch. If it's not coming any time soon though, I can do a V2 of > > this patch, but I won't bother right now in the expectation that a better > > solution is coming. > > My concern is that the file-based solution will handle only the patches where > every changes are in drivers/ (not config/ or anything else). > I'm thinking how to merge both solutions. > > I'm also concerned by the time passed developing these checks ;) "Time is an illusion. Lunchtime doubly so."
[dpdk-dev] [PATCH v4] mk: filter duplicate configuration entries
*updates in v4*
- replace awk usage with sed
- re-add the old loop to be able to get rid of awk
- add more explanation to the header of the makefile section
*updates in v3*
- replace tac with sed '1!G;h;$!d' to avoid build time dependency
*updates in v2*
- move to .config target
- fix usage order of tac
- simplify inner section by only using awk (instead of awk+loop+bash+sed)
Due to the hierarchy and the demand to keep the base config showing all
options, some config keys end up multiple times in the .config file.
Due to the way the actual config is sourced only the last entry is
important. That can confuse people changing values in .config which
are then ignored.
A suggested solution was to filter for duplicates at the end of the
actual config step which is implemented here.
Signed-off-by: Christian Ehrhardt
---
mk/rte.sdkconfig.mk | 9 +
1 file changed, 9 insertions(+)
diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
index a3acfe6..70c59d6 100644
--- a/mk/rte.sdkconfig.mk
+++ b/mk/rte.sdkconfig.mk
@@ -79,11 +79,20 @@ $(RTE_OUTPUT):
ifdef NODOTCONF
$(RTE_OUTPUT)/.config: ;
else
+# Generate config from template, if there are duplicates keep only the last.
+# To do so the temp config is checked for duplicate keys with cut/sort/uniq
+# Then for each of those identified duplicates as long as there are more than
+# just one left the last match is removed.
$(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE | $(RTE_OUTPUT)
$(Q)if [ "$(RTE_CONFIG_TEMPLATE)" != "" -a -f "$(RTE_CONFIG_TEMPLATE)"
]; then \
$(CPP) -undef -P -x assembler-with-cpp \
-ffreestanding \
-o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
+ for config in $$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp | cut
-d"=" -f1 | sort | uniq -d); do \
+ while [ $$(grep "^$${config}="
$(RTE_OUTPUT)/.config_tmp -c ) -gt 1 ]; do \
+ sed -i "0,/^$${config}=/{//d}"
$(RTE_OUTPUT)/.config_tmp; \
+ done; \
+ done; \
if ! cmp -s $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config;
then \
cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config ; \
cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config.orig
; \
--
2.7.4
[dpdk-dev] [PATCH v3 4/4] virtio: add neon support
On 5 July 2016 at 20:49, Jerin Jacob wrote: > Added neon based Rx vector implementation. > Selection of the new handler based neon availability at runtime. > Updated the release notes and MAINTAINERS file. > > Signed-off-by: Jerin Jacob > --- > MAINTAINERS | 1 + > doc/guides/rel_notes/release_16_07.rst | 2 + > drivers/net/virtio/Makefile | 2 + > drivers/net/virtio/virtio_rxtx.c | 3 + > drivers/net/virtio/virtio_rxtx_simple_neon.c | 235 > +++ > 5 files changed, 243 insertions(+) > create mode 100644 drivers/net/virtio/virtio_rxtx_simple_neon.c > Acked-by: Jianbo Liu
[dpdk-dev] [PATCH] scripts: add check for net driver names without net prefix
2016-07-05 15:40, Bruce Richardson: > +# check headline label for net/ prefix if needed > +bad=$(echo "$headlines" | grep -E --color=always \ > + -e "^($(ls drivers/net | grep -v Makefile | tr '\n' '|')):" \ > + | sed 's,^,\t,') > +[ -z "$bad" ] || printf "Headline missing 'net/' prefix:\n$bad\n" This check is definitely a good idea. We need the same thing for crypto. Few nits: - -E is not needed for this regex - "/base:" cases are not handled because of the colon at the end of the regex. - patches touching several drivers are not handled. Examples: "mlx:" -> "net/mlx:" "drivers/net:" -> "net:" By the way, I am looking at an idea, that Nelio sent me, based on modified files. It can complete this check.
[dpdk-dev] [PATCH v3] mk: filter duplicate configuration entries
Thanks Ferruh,
I'm personally more an awk guy so that was my natural choice.
But I in general agree, the less tools used the better for dependencies and
stability.
I checked your suggestion and works like a charm.
I'll still follow Bruce guidance to add more explanation.
v4 should show up any minute ...
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Wed, Jul 6, 2016 at 10:57 AM, Ferruh Yigit
wrote:
> On 7/6/2016 9:12 AM, Bruce Richardson wrote:
> > On Wed, Jul 06, 2016 at 07:37:45AM +0200, Christian Ehrhardt wrote:
> >> *updates in v3*
> >> - replace tac with sed '1!G;h;$!d' to avoid build time dependency
> >>
> >> *updates in v2*
> >> - move to .config target
> >> - fix usage order of tac
> >> - simplify inner section by only using awk (instead of
> awk+loop+bash+sed)
> >>
> >> Due to the hierarchy and the demand to keep the base config showing all
> >> options, some config keys end up multiple times in the .config file.
> >>
> >> Due to the way the actual config is sourced only the last entry is
> >> important. That can confuse people changing values in .config which
> >> are then ignored.
> >>
> >> A suggested solution was to filter for duplicates at the end of the
> >> actual config step which is implemented here.
> >>
> >> Signed-off-by: Christian Ehrhardt
> >> ---
> >> mk/rte.sdkconfig.mk | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
> >> index a3acfe6..d031bf4 100644
> >> --- a/mk/rte.sdkconfig.mk
> >> +++ b/mk/rte.sdkconfig.mk
> >> @@ -79,11 +79,17 @@ $(RTE_OUTPUT):
> >> ifdef NODOTCONF
> >> $(RTE_OUTPUT)/.config: ;
> >> else
> >> +# Generate config from template, if there are duplicates keep only the
> last
> >> $(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE | $(RTE_OUTPUT)
> >> $(Q)if [ "$(RTE_CONFIG_TEMPLATE)" != "" -a -f
> "$(RTE_CONFIG_TEMPLATE)" ]; then \
> >> $(CPP) -undef -P -x assembler-with-cpp \
> >> -ffreestanding \
> >> -o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
> >> +sed '1!G;h;$$!d' $(RTE_OUTPUT)/.config_tmp >
> $(RTE_OUTPUT)/.config_tmp_reverse ; \
> >> +awk --field-separator '=' '!/^#/ {if (!seen[$$1]) {print
> ($$0)}; seen[$$1]=1;} \
> >> +/^#/ {print($$0)}'
> $(RTE_OUTPUT)/.config_tmp_reverse \
> >> +| sed '1!G;h;$$!d' > $(RTE_OUTPUT)/.config_tmp ; \
> >> +rm $(RTE_OUTPUT)/.config_tmp_reverse ; \
> >> if ! cmp -s $(RTE_OUTPUT)/.config_tmp
> $(RTE_OUTPUT)/.config; then \
> >> cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config
> ; \
> >> cp $(RTE_OUTPUT)/.config_tmp
> $(RTE_OUTPUT)/.config.orig ; \
> >> --
> >
> > Given the length and complexity of the work being done here, using some
> pretty
> > fancy sed and awk features, I feel that the comment at the top should be
> > expanded to actually explain what is being done and how. I would also
> include
> > in that explanation how sed is being used to reverse a file. Personally,
> I
> > would have preferred to keep the dependency on tac for a readability
> perspective.
> >
>
> By using sed, I didn't really mean using sed instead of tac, but
> something close to first version of this patch [1], these are just
> different ways of doing same thing.
>
> I don't know how common "tac" is, but even a box breaks build because
> off missing tac, that is problem, specially this change is not a must
> but a good to have.
>
> [1]
> for config in $$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp | cut -d"=" -f1
> | sort | uniq -d); do \
> while [ $$(grep "^$${config}=" $(RTE_OUTPUT)/.config_tmp -c ) -gt 1
> ]; do \
> sed -i "0,/^$${config}=/{//d}" $(RTE_OUTPUT)/.config_tmp; \
> done; \
> done; \
>
>
>
>
[dpdk-dev] [PATCH] doc: announce API change for virtual device initialization
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of De Lara Guarch, > Pablo > Sent: Tuesday, July 05, 2016 3:55 PM > To: Thomas Monjalon; Yigit, Ferruh > Cc: dev at dpdk.org; Mcnamara, John > Subject: Re: [dpdk-dev] [PATCH] doc: announce API change for virtual device > initialization > > > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Tuesday, July 05, 2016 2:39 PM > > To: Yigit, Ferruh > > Cc: dev at dpdk.org; De Lara Guarch, Pablo; Mcnamara, John > > Subject: Re: [dpdk-dev] [PATCH] doc: announce API change for virtual device > > initialization > > > > 2016-07-05 14:04, Ferruh Yigit: > > > On 7/4/2016 3:50 PM, Pablo de Lara wrote: > > > > +* The rte_eal_vdev_init function will be changed in 16.11 to return > > > > + the port/device id of the device created, instead of 0, when it has > been > > > > + initialized successfully, so user can use the returned value straight > away > > > > + to call all the device functions that require that parameter. > > > > > > There is another API rte_eth_dev_attach(), which returns port_id, and is > > > a common wrapper both for pdev and vdev. > > > So with proper devargs this API calls rte_eal_vdev_init() and returns > > > port_id (set in argument) without any extra side effect. > > > > I think rte_eth_dev_attach() should be removed from ethdev. > > Hotplugging a device belongs to device management, i.e. EAL. > > Even though rte_eth_dev_attach returns the port id, I think that > rte_eal_vdev_init > can return the port id anyway (and then, we can remove the call to > rte_eth_dev_get_port_by_name > in rte_eth_dev_attach). Also, that function is only applicable to Ethernet devices, so other devices like Crypto devices cannot be used. If we want to use that function for all devices, we should move it to eal, modify it slightly and rename it, and therefore, we will need a deprecation notice as well.
[dpdk-dev] [PATCH v3 6/6] ena: fix for icc compiler
There are no obstacles.
We first produced patches 1-5, then tested on different compilers so patch
no. 6 was made.
Thank you Bruce for support!
I'm still learning DPDK's submission/upstream process so all comments and
gained knowledge will easier future patches.
Jan
2016-07-06 10:14 GMT+02:00 Bruce Richardson :
> On Tue, Jul 05, 2016 at 07:10:54PM +0200, Jan M?dala wrote:
> > Let me point it this way:
> > ??This patch fixes: [dpdk-dev,v3,1/6] ena: update of ENA communication
> layer
> >
> > Jan
>
> Since it fixes another patch in the same series, I think the two patches
> could
> actually be merged, rather than adding code with a known issue and later
> having
> a two-line(ish) patch to fix it.
> I will merge the two on apply, if there is no objection.
>
> /Bruce
>
> >
> > 2016-07-05 19:04 GMT+02:00 Jan M?dala :
> >
> > > Uhm, wait, I think that sha is wrong, please let me check it double
> time.
> > >
> > > Jan
> > >
> > > 2016-07-05 19:03 GMT+02:00 Jan M?dala :
> > >
> > >> Bruce,
> > >>
> > >>
> > >> That'd be very kind of you if you can fix trailing zeros.
> > >>
> > >>
> > >> This patch
> > >>
> > >> Fixes: b5b8cd9 ("ena: update of ENA communication layer")
> > >>
> > >>
> > >> Regards,
> > >>
> > >> Jan
> > >>
> > >> 2016-07-05 18:19 GMT+02:00 Bruce Richardson <
> bruce.richardson at intel.com>:
> > >>
> > >>> On Tue, Jul 05, 2016 at 09:52:09AM +0100, Ferruh Yigit wrote:
> > >>> > On 6/30/2016 4:04 PM, Jan Medala wrote:
> > >>> > > Signed-off-by: Alexander Matushevsky
> > >>> > > Signed-off-by: Jakub Palider
> > >>> > > Signed-off-by: Jan Medala
> > >>> >
> > >>> > The compilation error to fix is [1], it may be good to add what to
> fix
> > >>> > into commit log.
> > >>> >
> > >>> > [1]
> > >>> > == Build drivers/net/ena
> > >>> > CC ena_ethdev.o
> > >>> > /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(943):
> error
> > >>> > #188: enumerated type mixed with another type
> > >>> > struct ena_com_create_io_ctx ctx = { 0 };
> > >>> > ^
> > >>> >
> > >>> > /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(1036):
> > >>> error
> > >>> > #188: enumerated type mixed with another type
> > >>> > struct ena_com_create_io_ctx ctx = { 0 };
> > >>> > ^
> > >>> > ...
> > >>> >
> > >>> > > --- a/drivers/net/ena/ena_ethdev.c
> > >>> > > +++ b/drivers/net/ena/ena_ethdev.c
> > >>> > > @@ -940,7 +940,10 @@ static int ena_tx_queue_setup(struct
> > >>> rte_eth_dev *dev,
> > >>> > > __rte_unused unsigned int socket_id,
> > >>> > > __rte_unused const struct
> rte_eth_txconf
> > >>> *tx_conf)
> > >>> > > {
> > >>> > > - struct ena_com_create_io_ctx ctx = { 0 };
> > >>> > > + struct ena_com_create_io_ctx ctx =
> > >>> > > + /* policy set to _HOST just to satisfy icc compiler
> */
> > >>> > > + { ENA_ADMIN_PLACEMENT_POLICY_HOST,
> > >>> > > + ENA_COM_IO_QUEUE_DIRECTION_TX, 0, 0, 0, 0 };
> > >>> >
> > >>> > Trailing "0" are not required, compiler will take care of them.
> > >>> >
> > >>> Jan,
> > >>>
> > >>> any comment on this? If you want, I can remove the trailing zeros on
> > >>> apply
> > >>> rather than needing a V3. Is that ok?
> > >>>
> > >>> Again a fixes line is missing, can you supply one.
> > >>>
> > >>> /Bruce
> > >>>
> > >>
> > >>
> > >
>
[dpdk-dev] [PATCH] examples/l2fwd-crypto: flush crypto dev buffers
Crypto operations are enqueued in the crypto devices
when the crypto device buffers are full (MAX_PKT_BURST),
in order to be more efficient.
The problem is that operations might be stuck in those buffers,
if they never get full, and therefore, those operations
will never be performed.
Therefore, it is necessary to have a buffer flush mechanism,
similar to the one used for flush the TX buffers, so eventually,
all packets received are ciphered and sent out.
Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application")
Signed-off-by: Pablo de Lara
---
examples/l2fwd-crypto/main.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 8dc616d..23b20b1 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -628,7 +628,7 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
unsigned lcore_id = rte_lcore_id();
uint64_t prev_tsc = 0, diff_tsc, cur_tsc, timer_tsc = 0;
- unsigned i, j, portid, nb_rx;
+ unsigned i, j, portid, nb_rx, len;
struct lcore_queue_conf *qconf = &lcore_queue_conf[lcore_id];
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) /
US_PER_S * BURST_TX_DRAIN_US;
@@ -727,10 +727,18 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
cur_tsc = rte_rdtsc();
/*
-* TX burst queue drain
+* Crypto device/TX burst queue drain
*/
diff_tsc = cur_tsc - prev_tsc;
if (unlikely(diff_tsc > drain_tsc)) {
+ /* Enqueue all crypto ops remaining in buffers */
+ for (i = 0; i < qconf->nb_crypto_devs; i++) {
+ cparams = &port_cparams[i];
+ len = qconf->op_buf[cparams->dev_id].len;
+ l2fwd_crypto_send_burst(qconf, len, cparams);
+ qconf->op_buf[cparams->dev_id].len = 0;
+ }
+ /* Transmit all packets remaining in buffers */
for (portid = 0; portid < RTE_MAX_ETHPORTS; portid++) {
if (qconf->pkt_buf[portid].len == 0)
continue;
--
2.5.5
[dpdk-dev] [PATCH v3] mk: filter duplicate configuration entries
On Wed, Jul 06, 2016 at 09:57:01AM +0100, Ferruh Yigit wrote:
> On 7/6/2016 9:12 AM, Bruce Richardson wrote:
> > On Wed, Jul 06, 2016 at 07:37:45AM +0200, Christian Ehrhardt wrote:
> >> *updates in v3*
> >> - replace tac with sed '1!G;h;$!d' to avoid build time dependency
> >>
> >> *updates in v2*
> >> - move to .config target
> >> - fix usage order of tac
> >> - simplify inner section by only using awk (instead of awk+loop+bash+sed)
> >>
> >> Due to the hierarchy and the demand to keep the base config showing all
> >> options, some config keys end up multiple times in the .config file.
> >>
> >> Due to the way the actual config is sourced only the last entry is
> >> important. That can confuse people changing values in .config which
> >> are then ignored.
> >>
> >> A suggested solution was to filter for duplicates at the end of the
> >> actual config step which is implemented here.
> >>
> >> Signed-off-by: Christian Ehrhardt
> >> ---
> >> mk/rte.sdkconfig.mk | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
> >> index a3acfe6..d031bf4 100644
> >> --- a/mk/rte.sdkconfig.mk
> >> +++ b/mk/rte.sdkconfig.mk
> >> @@ -79,11 +79,17 @@ $(RTE_OUTPUT):
> >> ifdef NODOTCONF
> >> $(RTE_OUTPUT)/.config: ;
> >> else
> >> +# Generate config from template, if there are duplicates keep only the
> >> last
> >> $(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE | $(RTE_OUTPUT)
> >>$(Q)if [ "$(RTE_CONFIG_TEMPLATE)" != "" -a -f "$(RTE_CONFIG_TEMPLATE)"
> >> ]; then \
> >>$(CPP) -undef -P -x assembler-with-cpp \
> >>-ffreestanding \
> >>-o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
> >> + sed '1!G;h;$$!d' $(RTE_OUTPUT)/.config_tmp >
> >> $(RTE_OUTPUT)/.config_tmp_reverse ; \
> >> + awk --field-separator '=' '!/^#/ {if (!seen[$$1]) {print
> >> ($$0)}; seen[$$1]=1;} \
> >> + /^#/ {print($$0)}' $(RTE_OUTPUT)/.config_tmp_reverse \
> >> + | sed '1!G;h;$$!d' > $(RTE_OUTPUT)/.config_tmp ; \
> >> + rm $(RTE_OUTPUT)/.config_tmp_reverse ; \
> >>if ! cmp -s $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config;
> >> then \
> >>cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config ; \
> >>cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config.orig
> >> ; \
> >> --
> >
> > Given the length and complexity of the work being done here, using some
> > pretty
> > fancy sed and awk features, I feel that the comment at the top should be
> > expanded to actually explain what is being done and how. I would also
> > include
> > in that explanation how sed is being used to reverse a file. Personally, I
> > would have preferred to keep the dependency on tac for a readability
> > perspective.
> >
>
> By using sed, I didn't really mean using sed instead of tac, but
> something close to first version of this patch [1], these are just
> different ways of doing same thing.
>
> I don't know how common "tac" is, but even a box breaks build because
> off missing tac, that is problem, specially this change is not a must
> but a good to have.
>
> [1]
> for config in $$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp | cut -d"=" -f1
> | sort | uniq -d); do \
> while [ $$(grep "^$${config}=" $(RTE_OUTPUT)/.config_tmp -c ) -gt 1
> ]; do \
> sed -i "0,/^$${config}=/{//d}" $(RTE_OUTPUT)/.config_tmp; \
> done; \
> done; \
>
Well, at least on my Fedora box, tac is part of coreutils, so it's probably
pretty widespread on Linux. Unfortunately, it's not available out-of-the-box
on FreeBSD.
/Bruce
[dpdk-dev] [PATCH] scripts: add check for net driver names without net prefix
On Wed, Jul 06, 2016 at 11:10:48AM +0200, Thomas Monjalon wrote: > 2016-07-05 15:40, Bruce Richardson: > > +# check headline label for net/ prefix if needed > > +bad=$(echo "$headlines" | grep -E --color=always \ > > + -e "^($(ls drivers/net | grep -v Makefile | tr '\n' '|')):" \ > > + | sed 's,^,\t,') > > +[ -z "$bad" ] || printf "Headline missing 'net/' prefix:\n$bad\n" > > This check is definitely a good idea. > We need the same thing for crypto. > Few nits: > - -E is not needed for this regex > - "/base:" cases are not handled because of the colon at the end > of the regex. Good point. Easy enough to fix, I suspect. > - patches touching several drivers are not handled. Examples: > "mlx:" -> "net/mlx:" > "drivers/net:" -> "net:" > Yes, however, those are in the minority of cases, and we can always add special case extra regex's for those - hardcoded like the other regex's in the file. I did the pulling directory list so we don't have to update the checks every time a new driver was added. > By the way, I am looking at an idea, that Nelio sent me, based on > modified files. It can complete this check. Great. I'll look forward to seeing that. If it works out well, by all means drop this patch. If it's not coming any time soon though, I can do a V2 of this patch, but I won't bother right now in the expectation that a better solution is coming. /Bruce
[dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet type parser
Hi Cunming,
On 07/06/2016 09:08 AM, Liang, Cunming wrote:
> Hi Olivier,
>
> On 7/5/2016 11:41 PM, Olivier Matz wrote:
>> Add a new RTE_PTYPE_L2_ETHER_MPLS packet type, and its support in
>> rte_pktmbuf_get_ptype().
>>
>> Signed-off-by: Didier Pallard
>> Signed-off-by: Olivier Matz
>> ---
>> lib/librte_mbuf/rte_mbuf_ptype.c | 25 +
>> lib/librte_mbuf/rte_mbuf_ptype.h | 9 -
>> lib/librte_net/Makefile | 4 +++-
>> lib/librte_net/rte_ether.h | 2 ++
>> 4 files changed, 38 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c
>> b/lib/librte_mbuf/rte_mbuf_ptype.c
>> index 5d46608..0dea600 100644
>> --- a/lib/librte_mbuf/rte_mbuf_ptype.c
>> +++ b/lib/librte_mbuf/rte_mbuf_ptype.c
>> @@ -41,6 +41,7 @@
>> #include
>> #include
>> #include
>> +#include
>> /* get l3 packet type from ip6 next protocol */
>> static uint32_t
>> @@ -166,6 +167,9 @@ uint32_t rte_pktmbuf_get_ptype(const struct
>> rte_mbuf *m,
>> off = sizeof(*eh);
>> hdr_lens->l2_len = off;
>> +if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4))
>> +goto l3; /* fast path if packet is IPv4 */
>> +
>> if (proto == rte_cpu_to_be_16(ETHER_TYPE_VLAN)) {
>> const struct vlan_hdr *vh;
>> struct vlan_hdr vh_copy;
>> @@ -189,8 +193,29 @@ uint32_t rte_pktmbuf_get_ptype(const struct
>> rte_mbuf *m,
>> off += 2 * sizeof(*vh);
>> hdr_lens->l2_len += 2 * sizeof(*vh);
>> proto = vh->eth_proto;
>> +} else if ((proto == rte_cpu_to_be_16(ETHER_TYPE_MPLS)) ||
>> +(proto == rte_cpu_to_be_16(ETHER_TYPE_MPLSM))) {
>> +unsigned int i;
>> +const struct mpls_hdr *mh;
>> +struct mpls_hdr mh_copy;
>> +
>> +#define MAX_MPLS_HDR 5
>> +for (i = 0; i < MAX_MPLS_HDR; i++) {
>> +mh = rte_pktmbuf_read(m, off + (i * sizeof(*mh)),
>> +sizeof(*mh), &mh_copy);
>> +if (unlikely(mh == NULL))
>> +return pkt_type;
>> +if (mh->bs)
>> +break;
>> +}
>> +if (i == MAX_MPLS_HDR)
>> +return pkt_type;
>> +pkt_type = RTE_PTYPE_L2_ETHER_MPLS;
>> +hdr_lens->l2_len += (sizeof(*mh) * (i + 1));
> [LC] l2_len includes Eth, Vlan(opt.), MPLS(opt.). For VLAN and MPLS, it
> may include #n times overlay.
> These layer recognition knowledge are lost after the detection logic.
> Once the APP takes the ptype, for the layer(L2, L3, L4) which has more
> shim-layer, the xxx_len can't help to avoid the re-parse cost.
This is linked with the definition of packet type. Each layer has a
type, and here we associate it to a length (by the way the length is
something we may consider integrate inside the packet type in the future).
The packet_type model allows to describe many packets kinds. Some will
be difficult to represent (ex: a packet with several different L2 or
L3). But I think this is a good compromise that could help the
application to get some information without looking inside the packet.
Changing the packet type structure to something more flexible/complex
would probably imply to loose time filling it in drivers and parse it in
the application. And we already have a structure that contains all the
information needed by the application: the packet data ;)
In any case, this is not really the topic of the patchset, which just
provide a helper to parse a packet by software and get a packet_type (as
it is defined today).
Regards,
Olivier
[dpdk-dev] [PATCH v3] mk: filter duplicate configuration entries
On 7/6/2016 9:12 AM, Bruce Richardson wrote:
> On Wed, Jul 06, 2016 at 07:37:45AM +0200, Christian Ehrhardt wrote:
>> *updates in v3*
>> - replace tac with sed '1!G;h;$!d' to avoid build time dependency
>>
>> *updates in v2*
>> - move to .config target
>> - fix usage order of tac
>> - simplify inner section by only using awk (instead of awk+loop+bash+sed)
>>
>> Due to the hierarchy and the demand to keep the base config showing all
>> options, some config keys end up multiple times in the .config file.
>>
>> Due to the way the actual config is sourced only the last entry is
>> important. That can confuse people changing values in .config which
>> are then ignored.
>>
>> A suggested solution was to filter for duplicates at the end of the
>> actual config step which is implemented here.
>>
>> Signed-off-by: Christian Ehrhardt
>> ---
>> mk/rte.sdkconfig.mk | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
>> index a3acfe6..d031bf4 100644
>> --- a/mk/rte.sdkconfig.mk
>> +++ b/mk/rte.sdkconfig.mk
>> @@ -79,11 +79,17 @@ $(RTE_OUTPUT):
>> ifdef NODOTCONF
>> $(RTE_OUTPUT)/.config: ;
>> else
>> +# Generate config from template, if there are duplicates keep only the last
>> $(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE | $(RTE_OUTPUT)
>> $(Q)if [ "$(RTE_CONFIG_TEMPLATE)" != "" -a -f "$(RTE_CONFIG_TEMPLATE)"
>> ]; then \
>> $(CPP) -undef -P -x assembler-with-cpp \
>> -ffreestanding \
>> -o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
>> +sed '1!G;h;$$!d' $(RTE_OUTPUT)/.config_tmp >
>> $(RTE_OUTPUT)/.config_tmp_reverse ; \
>> +awk --field-separator '=' '!/^#/ {if (!seen[$$1]) {print
>> ($$0)}; seen[$$1]=1;} \
>> +/^#/ {print($$0)}' $(RTE_OUTPUT)/.config_tmp_reverse \
>> +| sed '1!G;h;$$!d' > $(RTE_OUTPUT)/.config_tmp ; \
>> +rm $(RTE_OUTPUT)/.config_tmp_reverse ; \
>> if ! cmp -s $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config;
>> then \
>> cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config ; \
>> cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config.orig
>> ; \
>> --
>
> Given the length and complexity of the work being done here, using some pretty
> fancy sed and awk features, I feel that the comment at the top should be
> expanded to actually explain what is being done and how. I would also include
> in that explanation how sed is being used to reverse a file. Personally, I
> would have preferred to keep the dependency on tac for a readability
> perspective.
>
By using sed, I didn't really mean using sed instead of tac, but
something close to first version of this patch [1], these are just
different ways of doing same thing.
I don't know how common "tac" is, but even a box breaks build because
off missing tac, that is problem, specially this change is not a must
but a good to have.
[1]
for config in $$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp | cut -d"=" -f1
| sort | uniq -d); do \
while [ $$(grep "^$${config}=" $(RTE_OUTPUT)/.config_tmp -c ) -gt 1
]; do \
sed -i "0,/^$${config}=/{//d}" $(RTE_OUTPUT)/.config_tmp; \
done; \
done; \
[dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type from data
Hi Cunming,
On 07/06/2016 08:44 AM, Liang, Cunming wrote:
> Hi Olivier,
>
> On 7/5/2016 11:41 PM, Olivier Matz wrote:
>> Introduce the function rte_pktmbuf_get_ptype() that parses a
>> mbuf and returns its packet type. For now, the following packet
>> types are parsed:
>> L2: Ether
>> L3: IPv4, IPv6
>> L4: TCP, UDP, SCTP
>>
>> The goal here is to provide a reference implementation for packet type
>> parsing. This function will be used by testpmd in next commits, allowing
>> to compare its result with the value given by the hardware.
>>
>> This function will also be useful when implementing Rx offload support
>> in virtio pmd. Indeed, the virtio protocol gives the csum start and
>> offset, but it does not give the L4 protocol nor it tells if the
>> checksum is relevant for inner or outer. This information has to be
>> known to properly set the ol_flags in mbuf.
>>
>> Signed-off-by: Didier Pallard
>> Signed-off-by: Jean Dao
>> Signed-off-by: Olivier Matz
>> ---
>> doc/guides/rel_notes/release_16_11.rst | 5 +
>> lib/librte_mbuf/Makefile | 5 +-
>> lib/librte_mbuf/rte_mbuf_ptype.c | 234
>> +
>> lib/librte_mbuf/rte_mbuf_ptype.h | 43 ++
>> lib/librte_mbuf/rte_mbuf_version.map | 1 +
>> 5 files changed, 286 insertions(+), 2 deletions(-)
>> create mode 100644 lib/librte_mbuf/rte_mbuf_ptype.c
>>
>> [...]
>> +
>> +/* parse mbuf data to get packet type */
>> +uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
>> +struct rte_mbuf_hdr_lens *hdr_lens)
>> +{
>> +struct rte_mbuf_hdr_lens local_hdr_lens;
>> +const struct ether_hdr *eh;
>> +struct ether_hdr eh_copy;
>> +uint32_t pkt_type = RTE_PTYPE_L2_ETHER;
>> +uint32_t off = 0;
>> +uint16_t proto;
>> +
>> +if (hdr_lens == NULL)
>> +hdr_lens = &local_hdr_lens;
>> +
>> +eh = rte_pktmbuf_read(m, off, sizeof(*eh), &eh_copy);
>> +if (unlikely(eh == NULL))
>> +return 0;
>> +proto = eh->ether_type;
>> +off = sizeof(*eh);
>> +hdr_lens->l2_len = off;
>> +
>> +if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
>> +const struct ipv4_hdr *ip4h;
>> +struct ipv4_hdr ip4h_copy;
>> +
>> +ip4h = rte_pktmbuf_read(m, off, sizeof(*ip4h), &ip4h_copy);
>> +if (unlikely(ip4h == NULL))
>> +return pkt_type;
>> +
>> +pkt_type |= ptype_l3_ip(ip4h->version_ihl);
>> +hdr_lens->l3_len = ip4_hlen(ip4h);
>> +off += hdr_lens->l3_len;
>> +if (ip4h->fragment_offset &
>> +rte_cpu_to_be_16(IPV4_HDR_OFFSET_MASK |
>> +IPV4_HDR_MF_FLAG)) {
>> +pkt_type |= RTE_PTYPE_L4_FRAG;
>> +hdr_lens->l4_len = 0;
>> +return pkt_type;
>> +}
>> +proto = ip4h->next_proto_id;
>> +pkt_type |= ptype_l4(proto);
>> +} else if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv6)) {
>> +const struct ipv6_hdr *ip6h;
>> +struct ipv6_hdr ip6h_copy;
>> +int frag = 0;
>> +
>> +ip6h = rte_pktmbuf_read(m, off, sizeof(*ip6h), &ip6h_copy);
>> +if (unlikely(ip6h == NULL))
>> +return pkt_type;
>> +
>> +proto = ip6h->proto;
>> +hdr_lens->l3_len = sizeof(*ip6h);
>> +off += hdr_lens->l3_len;
>> +pkt_type |= ptype_l3_ip6(proto);
>> +if ((pkt_type & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV6_EXT) {
>> +proto = skip_ip6_ext(proto, m, &off, &frag);
>> +hdr_lens->l3_len = off - hdr_lens->l2_len;
>> +}
>> +if (proto == 0)
>> +return pkt_type;
>> +if (frag) {
>> +pkt_type |= RTE_PTYPE_L4_FRAG;
>> +hdr_lens->l4_len = 0;
>> +return pkt_type;
>> +}
>> +pkt_type |= ptype_l4(proto);
>> +}
>> +
>> +if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_UDP) {
>> +hdr_lens->l4_len = sizeof(struct udp_hdr);
>> +} else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_TCP) {
>> +const struct tcp_hdr *th;
>> +struct tcp_hdr th_copy;
>> +
>> +th = rte_pktmbuf_read(m, off, sizeof(*th), &th_copy);
>> +if (unlikely(th == NULL))
>> +return pkt_type & (RTE_PTYPE_L2_MASK |
>> +RTE_PTYPE_L3_MASK);
>> +hdr_lens->l4_len = (th->data_off & 0xf0) >> 2;
>> +} else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_SCTP) {
>> +hdr_lens->l4_len = sizeof(struct sctp_hdr);
>> +} else {
>> +hdr_lens->l4_len = 0;
>> +}
>> +
>> +return pkt_type;
>> +}
>> diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h
>> b/lib/librte_mbuf/rte_mbuf_ptype.h
>> index 4a34678..f468520 100644
>> --- a/lib/librte_mbuf/rte_mbuf_ptype.h
>> +++ b/lib/librte_mbuf/rte_mbuf_ptype.h
>> @@ -545,6 +545,49 @@ extern "C" {
>> RTE_PTYPE_INNER_L3_MASK |\
>> RTE_PTYPE_INNER_L4_MASK))
>> +struct rte_mbuf;
>> +
>> +/**
>> + * Structure co
[dpdk-dev] Possible Bug: DPDK 16.04 Empty packet_type
Hi, On 7/6/2016 3:54 AM, Craig, Chris A. wrote: > We recently upgraded our environment to the 16.04 version of DPDK on a 14.04 > installation of Ubuntu. After upgrading, we noticed our code was behaving > oddly. After further inspection, we discovered the `packet_type` attribute of > the mbuf is always 0. We had previously used it to detect L2 protocols for > further processing and confirmed our suspicions by seeing the correct bit > flags set in dpdk-2.2.0. In addition, the same behavior is observed after > upgrading the machine to 16.04. Attached and in-line are a small write up of > the observed issue. Has anyone else observed this behavior? Is it expected? This could be related to this commit: commit c8f9e99c7abdd4b2e4aae09313ba8f12df263a2a Author: Jianfeng Tan Date: Fri Mar 25 08:47:47 2016 +0800 config: enable i40e vector driver Previously, vector driver is not the first (default) choice for i40e, as it cannot fill packet type info for l3fwd to work well. Now there is an option for l3fwd to analysis packet type softly. So enable it by default. So could you please have a check what Rx/Tx functions are you using? I40e vector driver does not support setting packet type. Thanks, Jianfeng > == > DPDK 16.04 Bug > CPU: Intel(R) Xeon(R) CPU E5-2687W v3 > NICs: (2) Intel Corporation Ethernet 10G 2P X710 Adapter > OS: Ubuntu 14.04 and 16.04 > Kernel: 3.16.0-60-generic (x84 64) > DPDK: 16.04 > Network devices using DPDK-compatible driver > > :01:00.1 ?Ethernet 10G 2P X710 Adapter? drv=igb_uio unused= > :01:00.2 ?Ethernet 10G 2P X710 Adapter? drv=igb_uio unused= > > Problem: rte eth rx burst(...) is not initializing the rte mbuf struct. > Specifically, mb ? packet type is always 0. However, rte pkt mtod(mb, struct > ether hdr *) does return a pointer at the beginning of the Ethernet header > and parsing other higher level headers (e.g., TCP) works correctly. > Reproducing: Compile dpdk-16.04. Set verbose level=1 in testpmd.c and > compile. Run ?./testpmd ? -i?, ?set fwd rxonly?, ?start?. > > Example output: > src=00:00:00:00:00:01 - dst=00:00:00:00:00:02 - type=0x0800 - length=60 - > nb_segs=1 > Unknown packet type // Should have been RTE_PTYPE_L2_ETHER: > - Receive queue=0x0 > > src=00:00:00:00:00:01 - dst=00:00:00:00:00:02 - type=0x0800 - length=60 - > nb_segs=1 > Unknown packet type // Should have been RTE_PTYPE_L2_ETHER: > - Receive queue=0x0 > ... > Repeating the steps above with dpdk-2.2.0 on the same machine does not have > this issue. Example output on dpdk-2.2.0: > src=00:00:00:00:00:01 - dst=00:00:00:00:00:02 - type=0x0800 - length=60 - > nb_segs=1 >- (outer) L2 type: ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN - (outer) L4 > type: UDP >- Tunnel type: Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - > Inner L4 > type: Unknown > - Receive queue=0x0 > ... > > > -- > Christopher Craig > Cyber Security Software Engineer > Cyber and Information Security Research Group, Oak Ridge National Laboratory > http://www.csiir.ornl.gov || (865) 421 ? 2992 (work)
[dpdk-dev] [app/test/test_cryptodev.c] setup_test_string() - buffer overflow, segfault
Hi,
I was trying to run cryptodev_aesni_mb_autotest with the "test" app.
I ran into an overflow which I think I?debugged.
The initial symptom was at?rte_mempool_lookup()
called?from?rte_cryptodev_sym_session_pool_create(),
strncmp() went on a segfault, because "te"' 's members were NULL.
I set a watchpoint with gdb for that specific "te" memory location and it
appears that it gets overwritten at memset() in?setup_test_string().
If in setup_test_string() I add this code:
struct rte_mbuf *m = rte_pktmbuf_alloc(mpool);
int buf_len = rte_pktmbuf_data_room_size(mpool);
size_t t_len = len - (blocksize ? (len % blocksize) : 0);
printf("[SETUP STRING] m->buf_len = %d mpool->elt_size = %d room_size =
%d\n ",
(int) m->buf_len, (int) mpool->elt_size, buf_len);
memset(m->buf_addr, 0, m->buf_len);
I get this output:
[SETUP STRING] m->buf_len = 2816 mpool->elt_size = 2496 room_size = 2368
I am not very sure what should be used in that memset() (I do not know the API
that well), but buf_len seems bigger then an element size from that memory pool.
If I change that memset() to plain buf_len, the tests run completely.
Cata
[dpdk-dev] [PATCH v3 6/6] ena: fix for icc compiler
On Tue, Jul 05, 2016 at 07:10:54PM +0200, Jan M?dala wrote:
> Let me point it this way:
> ??This patch fixes: [dpdk-dev,v3,1/6] ena: update of ENA communication layer
>
> Jan
Since it fixes another patch in the same series, I think the two patches could
actually be merged, rather than adding code with a known issue and later having
a two-line(ish) patch to fix it.
I will merge the two on apply, if there is no objection.
/Bruce
>
> 2016-07-05 19:04 GMT+02:00 Jan M?dala :
>
> > Uhm, wait, I think that sha is wrong, please let me check it double time.
> >
> > Jan
> >
> > 2016-07-05 19:03 GMT+02:00 Jan M?dala :
> >
> >> Bruce,
> >>
> >>
> >> That'd be very kind of you if you can fix trailing zeros.
> >>
> >>
> >> This patch
> >>
> >> Fixes: b5b8cd9 ("ena: update of ENA communication layer")
> >>
> >>
> >> Regards,
> >>
> >> Jan
> >>
> >> 2016-07-05 18:19 GMT+02:00 Bruce Richardson >> intel.com>:
> >>
> >>> On Tue, Jul 05, 2016 at 09:52:09AM +0100, Ferruh Yigit wrote:
> >>> > On 6/30/2016 4:04 PM, Jan Medala wrote:
> >>> > > Signed-off-by: Alexander Matushevsky
> >>> > > Signed-off-by: Jakub Palider
> >>> > > Signed-off-by: Jan Medala
> >>> >
> >>> > The compilation error to fix is [1], it may be good to add what to fix
> >>> > into commit log.
> >>> >
> >>> > [1]
> >>> > == Build drivers/net/ena
> >>> > CC ena_ethdev.o
> >>> > /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(943): error
> >>> > #188: enumerated type mixed with another type
> >>> > struct ena_com_create_io_ctx ctx = { 0 };
> >>> > ^
> >>> >
> >>> > /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(1036):
> >>> error
> >>> > #188: enumerated type mixed with another type
> >>> > struct ena_com_create_io_ctx ctx = { 0 };
> >>> > ^
> >>> > ...
> >>> >
> >>> > > --- a/drivers/net/ena/ena_ethdev.c
> >>> > > +++ b/drivers/net/ena/ena_ethdev.c
> >>> > > @@ -940,7 +940,10 @@ static int ena_tx_queue_setup(struct
> >>> rte_eth_dev *dev,
> >>> > > __rte_unused unsigned int socket_id,
> >>> > > __rte_unused const struct rte_eth_txconf
> >>> *tx_conf)
> >>> > > {
> >>> > > - struct ena_com_create_io_ctx ctx = { 0 };
> >>> > > + struct ena_com_create_io_ctx ctx =
> >>> > > + /* policy set to _HOST just to satisfy icc compiler */
> >>> > > + { ENA_ADMIN_PLACEMENT_POLICY_HOST,
> >>> > > + ENA_COM_IO_QUEUE_DIRECTION_TX, 0, 0, 0, 0 };
> >>> >
> >>> > Trailing "0" are not required, compiler will take care of them.
> >>> >
> >>> Jan,
> >>>
> >>> any comment on this? If you want, I can remove the trailing zeros on
> >>> apply
> >>> rather than needing a V3. Is that ok?
> >>>
> >>> Again a fixes line is missing, can you supply one.
> >>>
> >>> /Bruce
> >>>
> >>
> >>
> >
[dpdk-dev] [PATCH v3] mk: filter duplicate configuration entries
On Wed, Jul 06, 2016 at 07:37:45AM +0200, Christian Ehrhardt wrote:
> *updates in v3*
> - replace tac with sed '1!G;h;$!d' to avoid build time dependency
>
> *updates in v2*
> - move to .config target
> - fix usage order of tac
> - simplify inner section by only using awk (instead of awk+loop+bash+sed)
>
> Due to the hierarchy and the demand to keep the base config showing all
> options, some config keys end up multiple times in the .config file.
>
> Due to the way the actual config is sourced only the last entry is
> important. That can confuse people changing values in .config which
> are then ignored.
>
> A suggested solution was to filter for duplicates at the end of the
> actual config step which is implemented here.
>
> Signed-off-by: Christian Ehrhardt
> ---
> mk/rte.sdkconfig.mk | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
> index a3acfe6..d031bf4 100644
> --- a/mk/rte.sdkconfig.mk
> +++ b/mk/rte.sdkconfig.mk
> @@ -79,11 +79,17 @@ $(RTE_OUTPUT):
> ifdef NODOTCONF
> $(RTE_OUTPUT)/.config: ;
> else
> +# Generate config from template, if there are duplicates keep only the last
> $(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE | $(RTE_OUTPUT)
> $(Q)if [ "$(RTE_CONFIG_TEMPLATE)" != "" -a -f "$(RTE_CONFIG_TEMPLATE)"
> ]; then \
> $(CPP) -undef -P -x assembler-with-cpp \
> -ffreestanding \
> -o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
> + sed '1!G;h;$$!d' $(RTE_OUTPUT)/.config_tmp >
> $(RTE_OUTPUT)/.config_tmp_reverse ; \
> + awk --field-separator '=' '!/^#/ {if (!seen[$$1]) {print
> ($$0)}; seen[$$1]=1;} \
> + /^#/ {print($$0)}' $(RTE_OUTPUT)/.config_tmp_reverse \
> + | sed '1!G;h;$$!d' > $(RTE_OUTPUT)/.config_tmp ; \
> + rm $(RTE_OUTPUT)/.config_tmp_reverse ; \
> if ! cmp -s $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config;
> then \
> cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config ; \
> cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config.orig
> ; \
> --
Given the length and complexity of the work being done here, using some pretty
fancy sed and awk features, I feel that the comment at the top should be
expanded to actually explain what is being done and how. I would also include
in that explanation how sed is being used to reverse a file. Personally, I
would have preferred to keep the dependency on tac for a readability
perspective.
/Bruce
[dpdk-dev] [PATCH v3] mk: filter duplicate configuration entries
On 7/6/2016 6:37 AM, Christian Ehrhardt wrote: > *updates in v3* > - replace tac with sed '1!G;h;$!d' to avoid build time dependency > > *updates in v2* > - move to .config target > - fix usage order of tac > - simplify inner section by only using awk (instead of awk+loop+bash+sed) > > Due to the hierarchy and the demand to keep the base config showing all > options, some config keys end up multiple times in the .config file. > > Due to the way the actual config is sourced only the last entry is > important. That can confuse people changing values in .config which > are then ignored. > > A suggested solution was to filter for duplicates at the end of the > actual config step which is implemented here. > > Signed-off-by: Christian Ehrhardt Reviewed-by: Ferruh Yigit
[dpdk-dev] xstats performance
On 05/07/2016 19:10, Rasesh Mody wrote: [..] >> For all the current drivers xstats_names[idx].id==idx so it would just >> involve removing the references to the id field and updating the >> documentation. Complication is coordinating with QLogic for the bnx2x & >> qede xstats patches. > > We could incorporate this change in our re-submission. The changes mentioned above have been merged in, so go ahead.. :)
[dpdk-dev] [PATCH v3] mk: filter duplicate configuration entries
*updates in v3*
- replace tac with sed '1!G;h;$!d' to avoid build time dependency
*updates in v2*
- move to .config target
- fix usage order of tac
- simplify inner section by only using awk (instead of awk+loop+bash+sed)
Due to the hierarchy and the demand to keep the base config showing all
options, some config keys end up multiple times in the .config file.
Due to the way the actual config is sourced only the last entry is
important. That can confuse people changing values in .config which
are then ignored.
A suggested solution was to filter for duplicates at the end of the
actual config step which is implemented here.
Signed-off-by: Christian Ehrhardt
---
mk/rte.sdkconfig.mk | 6 ++
1 file changed, 6 insertions(+)
diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
index a3acfe6..d031bf4 100644
--- a/mk/rte.sdkconfig.mk
+++ b/mk/rte.sdkconfig.mk
@@ -79,11 +79,17 @@ $(RTE_OUTPUT):
ifdef NODOTCONF
$(RTE_OUTPUT)/.config: ;
else
+# Generate config from template, if there are duplicates keep only the last
$(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE | $(RTE_OUTPUT)
$(Q)if [ "$(RTE_CONFIG_TEMPLATE)" != "" -a -f "$(RTE_CONFIG_TEMPLATE)"
]; then \
$(CPP) -undef -P -x assembler-with-cpp \
-ffreestanding \
-o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
+ sed '1!G;h;$$!d' $(RTE_OUTPUT)/.config_tmp >
$(RTE_OUTPUT)/.config_tmp_reverse ; \
+ awk --field-separator '=' '!/^#/ {if (!seen[$$1]) {print
($$0)}; seen[$$1]=1;} \
+ /^#/ {print($$0)}' $(RTE_OUTPUT)/.config_tmp_reverse \
+ | sed '1!G;h;$$!d' > $(RTE_OUTPUT)/.config_tmp ; \
+ rm $(RTE_OUTPUT)/.config_tmp_reverse ; \
if ! cmp -s $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config;
then \
cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config ; \
cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config.orig
; \
--
2.7.4
[dpdk-dev] [PATCH v2] mk: filter duplicate configuration entries
Hi,
I came up with something very similar when looking for tac replacements
yesterday, but had no time to finish things.
But your suggestion is even shorter - I had found "sed -n '1{h;T;};G;h;$p;'
file" or "sed -n '1!G;h;$p'".
That removes the tac dependency, which I agree is a good thing.
To chain things up without a temp file one would need the "in-place"
features of sed&awk which I'm not sure they are available (awk >=4.1 and
only GNU awk).
sed -i is only used in validate-abi.sh which might not be used on all
platforms to count as "-i is there already so I can use it".
And I really don't want to break anyone due to that change, just naively
clean up the resulting config a bit.
Also we already have a temp file .config_tmp in the same scope and remove
it on our own.
So it is not that much different to create and remove a second one for that
section.
Thanks for both of your feedback, submitting v3 now ...
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Tue, Jul 5, 2016 at 9:47 PM, Thomas Monjalon
wrote:
> 2016-07-05 17:47, Ferruh Yigit:
> > On 6/30/2016 1:00 PM, Christian Ehrhardt wrote:
> > > + tac $(RTE_OUTPUT)/.config_tmp >
> $(RTE_OUTPUT)/.config_tmp_reverse ; \
> > Now we are adding new binary dependency (tac) to build system
>
> tac can be replaced by sed '1!G;h;$!d'
>
>
[dpdk-dev] [PATCH v1] i40: fix the VXLAN TSO issue
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -801,6 +801,12 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
> union i40e_tx_offload tx_offload,
> uint32_t *cd_tunneling)
> {
> + /* Tx pkts tunnel type*/
> + if ((ol_flags & PKT_TX_TUNNEL_MASK) == PKT_TX_TUNNEL_VXLAN)
> + *cd_tunneling |= I40E_TXD_CTX_UDP_TUNNELING;
> + else if ((ol_flags & PKT_TX_TUNNEL_MASK) ==
> PKT_TX_TUNNEL_GRE)
> + *cd_tunneling |= I40E_TXD_CTX_GRE_TUNNELING;
> +
> /* UDP tunneling packet TX checksum offload */
> if (ol_flags & PKT_TX_OUTER_IP_CKSUM) {
>
Besides the tunnel type programming, please also check the L4TUNLEN in tunnel
parameters.
> @@ -1510,7 +1516,8 @@ i40e_calc_context_desc(uint64_t flags)
>
> /* set i40e TSO context descriptor */
> static inline uint64_t
> -i40e_set_tso_ctx(struct rte_mbuf *mbuf, union i40e_tx_offload tx_offload)
> +i40e_set_tso_ctx(struct rte_mbuf *mbuf,
> + union i40e_tx_offload tx_offload)
> {
> uint64_t ctx_desc = 0;
> uint32_t cd_cmd, hdr_len, cd_tso_len;
> @@ -1537,7 +1544,6 @@ i40e_set_tso_ctx(struct rte_mbuf *mbuf, union
> i40e_tx_offload tx_offload)
Please have a look at the calculation of tso length here. Only tunnel type
added may not be enogh.
>I40E_TXD_CTX_QW1_TSO_LEN_SHIFT) |
> ((uint64_t)mbuf->tso_segsz <<
>I40E_TXD_CTX_QW1_MSS_SHIFT);
> -
> return ctx_desc;
> }
>
This patch contains changes on testpmd, driver and mbuf definition. It's better
to split them and sent to the maintainers.
[dpdk-dev] [PATCH v1] i40: fix the VXLAN TSO issue
Problem:
when using the TSO + VXLAM feature in i40e, the outer UDP len will
sometimes be a invalid value for the multiple UDP segements which
are TSOed by the i40e for the inner TCP.
Fix this problem by add the tunnel type field in the i40e descriptor
which is missed before.
Fixes: 77b8301733c3 ("i40e: VXLAN Tx checksum offload")
Signed-off-by: Zhe Tao
---
app/test-pmd/csumonly.c | 26 +++---
drivers/net/i40e/i40e_rxtx.c | 10 --
lib/librte_mbuf/rte_mbuf.h | 11 +++
3 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index ac4bd8f..d423c20 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -204,7 +204,8 @@ parse_ethernet(struct ether_hdr *eth_hdr, struct
testpmd_offload_info *info)
static void
parse_vxlan(struct udp_hdr *udp_hdr,
struct testpmd_offload_info *info,
- uint32_t pkt_type)
+ uint32_t pkt_type,
+ uint64_t *ol_flags)
{
struct ether_hdr *eth_hdr;
@@ -215,6 +216,7 @@ parse_vxlan(struct udp_hdr *udp_hdr,
RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
return;
+ *ol_flags |= PKT_TX_TUNNEL_VXLAN;
info->is_tunnel = 1;
info->outer_ethertype = info->ethertype;
info->outer_l2_len = info->l2_len;
@@ -231,7 +233,9 @@ parse_vxlan(struct udp_hdr *udp_hdr,
/* Parse a gre header */
static void
-parse_gre(struct simple_gre_hdr *gre_hdr, struct testpmd_offload_info *info)
+parse_gre(struct simple_gre_hdr *gre_hdr,
+ struct testpmd_offload_info *info,
+ uint64_t *ol_flags)
{
struct ether_hdr *eth_hdr;
struct ipv4_hdr *ipv4_hdr;
@@ -242,6 +246,8 @@ parse_gre(struct simple_gre_hdr *gre_hdr, struct
testpmd_offload_info *info)
if ((gre_hdr->flags & _htons(~GRE_SUPPORTED_FIELDS)) != 0)
return;
+ *ol_flags |= PKT_TX_TUNNEL_GRE;
+
gre_len += sizeof(struct simple_gre_hdr);
if (gre_hdr->flags & _htons(GRE_KEY_PRESENT))
@@ -417,7 +423,7 @@ process_inner_cksums(void *l3_hdr, const struct
testpmd_offload_info *info,
* packet */
static uint64_t
process_outer_cksums(void *outer_l3_hdr, struct testpmd_offload_info *info,
- uint16_t testpmd_ol_flags)
+ uint16_t testpmd_ol_flags, uint64_t orig_ol_flags)
{
struct ipv4_hdr *ipv4_hdr = outer_l3_hdr;
struct ipv6_hdr *ipv6_hdr = outer_l3_hdr;
@@ -442,6 +448,9 @@ process_outer_cksums(void *outer_l3_hdr, struct
testpmd_offload_info *info,
* hardware supporting it today, and no API for it. */
udp_hdr = (struct udp_hdr *)((char *)outer_l3_hdr + info->outer_l3_len);
+ if ((orig_ol_flags & PKT_TX_TCP_SEG) &&
+ ((orig_ol_flags & PKT_TX_TUNNEL_MASK) == PKT_TX_TUNNEL_VXLAN))
+ udp_hdr->dgram_cksum = 0;
/* do not recalculate udp cksum if it was 0 */
if (udp_hdr->dgram_cksum != 0) {
udp_hdr->dgram_cksum = 0;
@@ -705,15 +714,18 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
if (info.l4_proto == IPPROTO_UDP) {
struct udp_hdr *udp_hdr;
udp_hdr = (struct udp_hdr *)((char *)l3_hdr +
- info.l3_len);
- parse_vxlan(udp_hdr, &info, m->packet_type);
+ info.l3_len);
+ parse_vxlan(udp_hdr, &info, m->packet_type,
+ &ol_flags);
} else if (info.l4_proto == IPPROTO_GRE) {
struct simple_gre_hdr *gre_hdr;
gre_hdr = (struct simple_gre_hdr *)
((char *)l3_hdr + info.l3_len);
- parse_gre(gre_hdr, &info);
+ parse_gre(gre_hdr, &info, &ol_flags);
} else if (info.l4_proto == IPPROTO_IPIP) {
void *encap_ip_hdr;
+
+ ol_flags |= PKT_TX_TUNNEL_IPIP;
encap_ip_hdr = (char *)l3_hdr + info.l3_len;
parse_encap_ip(encap_ip_hdr, &info);
}
@@ -745,7 +757,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
* processed in hardware. */
if (info.is_tunnel == 1) {
ol_flags |= process_outer_cksums(outer_l3_hdr, &info,
- testpmd_ol_flags);
+ testpmd_ol_flags, ol_flags);
}
/* step 4: fill the mbuf meta data (flags and header lengths) */
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 049a813..272b04c 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -801,6 +801,12 @@ i40e_txd_en
[dpdk-dev] [PATCH v2 3/3] i40e: fix out-of-bounds access
> -Original Message-
> From: Richardson, Bruce
> Sent: Tuesday, July 5, 2016 9:26 PM
> To: Xing, Beilei
> Cc: Wu, Jingjing ; Jastrzebski, MichalX K
> ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 3/3] i40e: fix out-of-bounds access
>
> On Tue, Jul 05, 2016 at 02:10:05PM +0800, Beilei Xing wrote:
> > When calling i40e_flowtype_to_pctype in
> > i40e_get_hash_filter_global_config and
> > i40e_set_hash_filter_global_config, function i40e_flowtype_to_pctype
> > will be possibly out-of-bounds accessed, because size of callee's
> > array is 15. So judge flow type before calling
> > i40e_flowtype_to_pctype.
> > Meanwhile do the same change in other functions.
> >
> > Coverity issue: 37793, 37794
> >
> > Fixes: 782c8c92f13f ("i40e: add hash configuration")
> > Fixes: f2b2e2354bbd ("i40e: split function for hash and flow director
> > input")
> > Fixes: 98f055707685 ("i40e: configure input fields for RSS or flow
> > director")
> >
> > Signed-off-by: Beilei Xing
> > ---
> > drivers/net/i40e/i40e_ethdev.c | 21 -
> > 1 file changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index a1cad37..111a552 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -6908,6 +6908,9 @@ i40e_get_hash_filter_global_config(struct
> i40e_hw *hw,
> > mask &= ~(1UL << i);
> > /* Bit set indicats the coresponding flow type is supported */
> > g_cfg->valid_bit_mask[0] |= (1UL << i);
> > + /* if flowtype is invalid, continue */
> > + if (!I40E_VALID_FLOW(i))
> > + continue;
> > pctype = i40e_flowtype_to_pctype(i);
> > reg = i40e_read_rx_ctl(hw, I40E_GLQF_HSYM(pctype));
> > if (reg & I40E_GLQF_HSYM_SYMH_ENA_MASK)
>
> Rather than having the same check done in multiple places, is there a reason
> why we can't just put the check once in i40e_flowtype_to_pctype?
Since the return value type of i40e_flowtype_to_pctype is " enum
i40e_filter_pctype ", although put the check in i40e_flowtype_to_pctype, we
should check return value after every i40e_flowtype_to_pctype calling. I think
there's no more improvement.
Besides, check valid flow type is called before i40e_flowtype_to_pctype in some
places previously, such as function i40e_hash_filter_inset_select and
i40e_fdir_filter_inset_select.
/Beilei
>
> /Bruce
[dpdk-dev] [PATCH v6 0/4] support reset of VF link
ample is needed to show how to use the reset API. I plan to > modify > the testpmd. > > You may notice this feature is postponed to 16.11. Would you like to wait > > for > the new version that will include an example? > > Hi, > > Unfortunately we need the VF reset working sooner than that, so one way or > the other I'll need to sort it out. Given I've got a use case where this is > happening, > if it can be helpful for you I'm more than happy to help as a guinea pig. If > you > could please give some guidance/guidelines with regards to which API to use to > sort the mbuf problem, I can try it out and give back some feedback. > > Thanks! I made a stupid mistake and deleted all my code. So, I have to take some time to rewrite it :( Attached the example I used to test the reset API. It's modified from the l2fwd example. So you can compare it with l2fwd to see what need to be added. Hopefully it can help :) > > -- > Kind regards, > Luca Boccassi -- next part -- An embedded and charset-unspecified text was scrubbed... Name: main.c URL: <http://dpdk.org/ml/archives/dev/attachments/20160706/1e1df3ba/attachment-0001.c>
