[dpdk-dev] [RFC] Yet another option for DPDK options

I On Fri, Jun 3, 2016 at 10:23 PM, Wiles, Keith wrote: > > On 6/3/16, 2:18 PM, "Neil Horman" wrote: > > >On Fri, Jun 03, 2016 at 07:07:50PM +, Wiles, Keith wrote: > >> On 6/3/16, 2:00 PM, "dev on behalf of Wiles, Keith" < > dev-bounces at dpdk.org on behalf of keith.wiles at intel.com> wrot

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 3, 2016 at 9:38 PM, Neil Horman wrote: > On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith wrote: > > > > On 6/3/16, 12:44 PM, "Neil Horman" wrote: > > > > >On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote: > > >> Sorry, I deleted all of the text as it was getting a

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/3/16, 2:18 PM, "Neil Horman" wrote: >On Fri, Jun 03, 2016 at 07:07:50PM +, Wiles, Keith wrote: >> On 6/3/16, 2:00 PM, "dev on behalf of Wiles, Keith" > on behalf of keith.wiles at intel.com> wrote: >> >> >On 6/3/16, 1:52 PM, "Arnon Warshavsky" mailto:arnon at >> >qwilt.com>> wrote: >>

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/3/16, 2:00 PM, "dev on behalf of Wiles, Keith" wrote: >On 6/3/16, 1:52 PM, "Arnon Warshavsky" mailto:arnon at >qwilt.com>> wrote: > > > >On Fri, Jun 3, 2016 at 9:38 PM, Neil Horman tuxdriver.com> wrote: >On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/3/16, 1:52 PM, "Arnon Warshavsky" mailto:arnon at qwilt.com>> wrote: On Fri, Jun 3, 2016 at 9:38 PM, Neil Horman mailto:nhorman at tuxdriver.com>> wrote: On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith wrote: > > On 6/3/16, 12:44 PM, "Neil Horman" mailto:nhorman > at tuxdriver.com>

[dpdk-dev] [RFC] Yet another option for DPDK options

On 6/3/16, 12:44 PM, "Neil Horman" wrote: >On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote: >> Sorry, I deleted all of the text as it was getting a bit long. >> >> Here are my thoughts as of now, which is a combination of many suggestions I >> read from everyone?s emails. I hope t

[dpdk-dev] RFC: DPDK Long Term Support

Hi, 2016-06-03 15:07, Mcnamara, John: > Introduction > > > This document sets out a proposal for a DPDK Long Term Support release (LTS). In general, LTS refer to a longer maintenance than than regular one. Here we are talking to doing some maintenance as stable releases first. Curre

[dpdk-dev] [PATCH v2] ivshmem: add all memzones of mempool to metadata

Mempool consist of multiple memzones, at least from two of them. ivshmem assumes mempool and elements are all in same memzone. Updating code to add all memzones when a mempool added. Fixes: d1d914ebbc25 ("mempool: allocate in several memory chunks by default") Signed-off-by: Ferruh Yigit Acked-

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 3, 2016 at 3:53 PM, Panu Matilainen wrote: > On 06/03/2016 03:01 PM, Arnon Warshavsky wrote: > >> >> >> On Fri, Jun 3, 2016 at 2:50 PM, Neil Horman > > wrote: >> >> On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote: >> > On Fri,

[dpdk-dev] [PATCH] ivshmem: add all memzones of mempool to metada

On 6/3/2016 12:05 PM, Ferruh Yigit wrote: > On 6/2/2016 8:04 AM, Olivier MATZ wrote: >> Hi Ferruh, >> >> Thank you for fixing this issue. >> >> On 06/01/2016 03:18 PM, Ferruh Yigit wrote: >>> [PATCH] ivshmem: add all memzones of mempool to metada >> >> Minor comment: it seems the title is truncated

[dpdk-dev] [PATCH v7 1/5] mempool: support external mempool operations

On Fri, Jun 03, 2016 at 11:28:14AM +0100, Hunt, David wrote: > > > > > static inline struct rte_mempool_ops * > > > rte_mempool_ops_get(int ops_index) > > > > > > return &rte_mempool_ops_table.ops[ops_index]; > > |> 2) Considering "get" and "put" are the fast-path callbacks for > > |> pool-manger

[dpdk-dev] [PATCH v7 5/5] mbuf: allow apps to change default mempool ops

On 06/03/2016 04:06 PM, Hunt, David wrote: > > > On 6/3/2016 1:28 PM, Olivier MATZ wrote: >>> [PATCH v7 5/5] mbuf: allow apps to change default mempool ops >> Should the title be fixed? >> I don't feel this allows application to change the default ops. > > Allow _user_ to change default mempoo

[dpdk-dev] [RFC] Yet another option for DPDK options

Regards, Keith On 6/3/16, 11:04 AM, "dev on behalf of Wiles, Keith" wrote: >Sorry, I deleted all of the text as it was getting a bit long. > >Here are my thoughts as of now, which is a combination of many suggestions I >read from everyone?s emails. I hope this is not too hard to understand.

[dpdk-dev] [RFC] Yet another option for DPDK options

+1 We're using INI in our app, turned out to be quite simple, like this: [eal] ;; EAL common options: ;; -c COREMASK Hexadecimal bitmask of cores to run on # coremask = fff ;; -l CORELIST List of cores to run on corelist = 3,4,5 ;; --lcores COREMAPMap lcore set to phys

[dpdk-dev] [RFC] Yet another option for DPDK options

Sorry, I deleted all of the text as it was getting a bit long. Here are my thoughts as of now, which is a combination of many suggestions I read from everyone?s emails. I hope this is not too hard to understand. - Break out the current command line options out of the DPDK common code and move i

[dpdk-dev] [PATCH 1/2] qede: rename config option

On Mon, May 30, 2016 at 03:38:41PM +0100, Bruce Richardson wrote: > On Fri, May 06, 2016 at 09:21:30PM -0700, Rasesh Mody wrote: > > Rename RTE_LIBRTE_QEDE_DEBUG_DRV to RTE_LIBRTE_QEDE_DEBUG_DRIVER > > > > Fixes: 425cba2a5176 ("qede: enable PMD build") > > Fixes: 33e9ff1b72ca ("qede: add core driv

[dpdk-dev] [PATCH v8 3/3] mbuf: make default mempool ops configurable at build

By default, the mempool ops used for mbuf allocations is a multi producer and multi consumer ring. We could imagine a target (maybe some network processors?) that provides an hardware-assisted pool mechanism. In this case, the default configuration for this architecture would contain a different va

[dpdk-dev] [PATCH v8 2/3] app/test: test external mempool manager

Use a minimal custom mempool external ops and check that it also passes basic mempool autotests. Signed-off-by: Olivier Matz Signed-off-by: David Hunt --- app/test/test_mempool.c | 114 1 file changed, 114 insertions(+) diff --git a/app/test/tes

[dpdk-dev] [PATCH v8 1/3] mempool: support external mempool operations

Until now, the objects stored in a mempool were internally stored in a ring. This patch introduces the possibility to register external handlers replacing the ring. The default behavior remains unchanged, but calling the new function rte_mempool_set_handler() right after rte_mempool_create_empty()

[dpdk-dev] [PATCH v8 0/5] mempool: add external mempool manager

Here's the latest version of the External Mempool Manager patchset. It's re-based on top of the latest head as of 19/5/2016, including Olivier's 35-part patch series on mempool re-org [1] [1] http://dpdk.org/ml/archives/dev/2016-May/039229.html v8 changes: * merged first three patches in the se

[dpdk-dev] [PATCH 1/2] qede: rename config option

Thanks! > From: Bruce Richardson [mailto:bruce.richardson at intel.com] > Sent: Friday, June 03, 2016 8:02 AM > > On Mon, May 30, 2016 at 03:38:41PM +0100, Bruce Richardson wrote: > > On Fri, May 06, 2016 at 09:21:30PM -0700, Rasesh Mody wrote: > > > Rename RTE_LIBRTE_QEDE_DEBUG_DRV to > RTE_LIBR

[dpdk-dev] [RFC] Yet another option for DPDK options

On 06/03/2016 03:01 PM, Arnon Warshavsky wrote: > > > On Fri, Jun 3, 2016 at 2:50 PM, Neil Horman > wrote: > > On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote: > > On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote: > > >

[dpdk-dev] [PATCH v5 0/6] Virtio-net PMD: QEMU QTest extension for container

2016-06-03 12:17, Yuanhan Liu: > On Thu, Jun 02, 2016 at 06:30:18PM +0900, Tetsuya Mukawa wrote: > > Hi Yuanhan, > > > > On 2016/06/02 16:31, Yuanhan Liu wrote: > > > But still, I'd ask do we really need 2 virtio for container solutions? > > > > I appreciate your comments. > > No, I appreciate y

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 07:07:50PM +, Wiles, Keith wrote: > On 6/3/16, 2:00 PM, "dev on behalf of Wiles, Keith" on behalf of keith.wiles at intel.com> wrote: > > >On 6/3/16, 1:52 PM, "Arnon Warshavsky" mailto:arnon at > >qwilt.com>> wrote: > > > > > > > >On Fri, Jun 3, 2016 at 9:38 PM, Neil

[dpdk-dev] [PATCH v7 2/5] mempool: remove rte_ring from rte_mempool struct

On 6/3/2016 1:28 PM, Olivier MATZ wrote: > > On 06/02/2016 03:27 PM, David Hunt wrote: >> Now that we're moving to an external mempoool handler, which >> uses a void *pool_data as a pointer to the pool data, remove the >> unneeded ring pointer from the mempool struct. >> >> Signed-off-by: David H

[dpdk-dev] [RFC] Yet another option for DPDK options

On 06/03/2016 02:50 PM, Neil Horman wrote: > On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote: >> On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote: >>> On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles,

[dpdk-dev] [PATCH v7 5/5] mbuf: allow apps to change default mempool ops

On 6/3/2016 3:10 PM, Olivier Matz wrote: > > On 06/03/2016 04:06 PM, Hunt, David wrote: >> >> On 6/3/2016 1:28 PM, Olivier MATZ wrote: [PATCH v7 5/5] mbuf: allow apps to change default mempool ops >>> Should the title be fixed? >>> I don't feel this allows application to change the default o

[dpdk-dev] RFC: DPDK Long Term Support

Introduction This document sets out a proposal for a DPDK Long Term Support release (LTS). The purpose of the DPDK LTS will be to maintain a stable release of DPDK with backported bug fixes over an extended period of time. This will provide downstream consumers of DPDK with a stable

[dpdk-dev] [PATCH v7 5/5] mbuf: allow apps to change default mempool ops

On 6/3/2016 1:28 PM, Olivier MATZ wrote: >> [PATCH v7 5/5] mbuf: allow apps to change default mempool ops > Should the title be fixed? > I don't feel this allows application to change the default ops. Allow _user_ to change default mempool ops, I think.

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 3, 2016 at 2:50 PM, Neil Horman wrote: > On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote: > > On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote: > > > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: > > > > On Thu, Jun 02, 2016 at 07:41:10P

[dpdk-dev] about rx checksum flags

Hi, On 06/02/2016 09:42 AM, Chandran, Sugesh wrote: Do you also suggest to drop IP checksum flags? >>> > > >>> > > IP checksum offload is mostly useless. If application needs to look at >>> > > IP, it can do whole checksum in very few instructions, the whole >>> > > header is in the same cach

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 07:23:39PM +, Wiles, Keith wrote: > If someone needs or wants default values in the API call then a wrapper > functions around the basic keystore APIs can be done by the developer or we > can add a new set of APIs to provide that type of feature, just like the > varia

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 03:18:04PM -0400, Neil Horman wrote: > I'm not opposed to default values, but it seems to me that if we are splitting > out a configuration storage library from dpdk, part of the initzliation of > that > library can be installing default values. That is to say, instead of

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 07:07:50PM +, Wiles, Keith wrote: > If I understand your code above the API would pass in a default value if one > did not exist in the storage, which I guess is reasonable. Anyone think this > is a good idea or not? This model has worked very well in my code at least

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 09:52:40PM +0300, Arnon Warshavsky wrote: > What about the data types of the values? > I would assume that as a library it can provide the service of typed > get/set and not leave conversion and validation to the app. > > rte_map_get_int(map,section,key) > rte_map_get_doubl

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith wrote: > > On 6/3/16, 12:44 PM, "Neil Horman" wrote: > > >On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote: > >> Sorry, I deleted all of the text as it was getting a bit long. > >> > >> Here are my thoughts as of now, which is a

[dpdk-dev] [PATCH v7 5/5] mbuf: allow apps to change default mempool ops

> [PATCH v7 5/5] mbuf: allow apps to change default mempool ops Should the title be fixed? I don't feel this allows application to change the default ops.

[dpdk-dev] [PATCH v7 2/5] mempool: remove rte_ring from rte_mempool struct

On 06/02/2016 03:27 PM, David Hunt wrote: > Now that we're moving to an external mempoool handler, which > uses a void *pool_data as a pointer to the pool data, remove the > unneeded ring pointer from the mempool struct. > > Signed-off-by: David Hunt > --- > app/test/test_mempool_perf.c |

[dpdk-dev] [PATCH v7 1/5] mempool: support external mempool operations

Hi, Some comments below. On 06/02/2016 03:27 PM, David Hunt wrote: > --- a/lib/librte_mempool/rte_mempool.h > +++ b/lib/librte_mempool/rte_mempool.h > +/** > + * prototype for implementation specific data provisioning function > + * The function should provide the implementation specific memory f

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote: > Sorry, I deleted all of the text as it was getting a bit long. > > Here are my thoughts as of now, which is a combination of many suggestions I > read from everyone?s emails. I hope this is not too hard to understand. > > - Break ou

[dpdk-dev] [PATCH v7 1/5] mempool: support external mempool operations

Hello, sorry for top-posting. I vote for passing rte_mempool instead of void *. This is what I've already pointed at, a kind of type-safety...? Passing uint64_t just hides the problem. Another way is to name the union and pass it as eg. union rte_mempool_priv * to the callbacks. Jan?Viktorin R

[dpdk-dev] [PATCH v7 1/5] mempool: support external mempool operations

On 6/3/2016 12:07 PM, Olivier MATZ wrote: > > On 06/03/2016 12:28 PM, Hunt, David wrote: >> On 6/3/2016 7:38 AM, Jerin Jacob wrote: >>> On Thu, Jun 02, 2016 at 02:27:19PM +0100, David Hunt wrote: +/** + * @internal wrapper for external mempool manager put callback. + * + * @pa

[dpdk-dev] [PATCH v7 1/5] mempool: support external mempool operations

On 06/03/2016 12:28 PM, Hunt, David wrote: > On 6/3/2016 7:38 AM, Jerin Jacob wrote: >> On Thu, Jun 02, 2016 at 02:27:19PM +0100, David Hunt wrote: >>> +/** >>> + * @internal wrapper for external mempool manager put callback. >>> + * >>> + * @param mp >>> + * Pointer to the memory pool. >>> + *

[dpdk-dev] [PATCH v2] mempool: replace c memcpy code semantics with optimized rte_memcpy

On Thu, Jun 02, 2016 at 11:16:16PM +0200, Olivier MATZ wrote: Hi Olivier, > This is probably more a measure of the pure CPU cost of the mempool > function, without considering the memory cache aspect. So, of course, > a real use-case test should be done to confirm or not that it increases > the pe

[dpdk-dev] [PATCH v5 0/6] Virtio-net PMD: QEMU QTest extension for container

On Thu, Jun 02, 2016 at 06:30:18PM +0900, Tetsuya Mukawa wrote: > Hi Yuanhan, > > On 2016/06/02 16:31, Yuanhan Liu wrote: > > But still, I'd ask do we really need 2 virtio for container solutions? > > I appreciate your comments. No, I appreciate your effort for contributing to DPDK! vhost-pmd st

[dpdk-dev] [PATCH v7 1/5] mempool: support external mempool operations

On Thu, Jun 02, 2016 at 02:27:19PM +0100, David Hunt wrote: [snip] > /* create the internal ring if not already done */ > if ((mp->flags & MEMPOOL_F_RING_CREATED) == 0) { |> 1) May be RING can be replaced with some other higher abstraction name |> for the internal MEMPOOL_F_RING_CREA

[dpdk-dev] [PATCH] ivshmem: add all memzones of mempool to metada

On 6/2/2016 8:04 AM, Olivier MATZ wrote: > Hi Ferruh, > > Thank you for fixing this issue. > > On 06/01/2016 03:18 PM, Ferruh Yigit wrote: >> [PATCH] ivshmem: add all memzones of mempool to metada > > Minor comment: it seems the title is truncated > Right, I will fix in next version of patch.

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote: > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: > > On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote: > > > > > > On 6/2/16, 12:11 PM, "Neil Horman" wrote: > > > > > > > > > > >1) The definition of a con

[dpdk-dev] [PATCH v2] doc: add pep8 as the python code style guidelines

On Fri, May 27, 2016 at 03:57:15PM +0100, John McNamara wrote: > Added PEP8 to the DPDK Coding Style guidelines to cover Python > contributions to DPDK. > > Signed-off-by: John McNamara > --- > v2: fixed section level. > > > doc/guides/contributing/coding_style.rst | 8 > 1 file chang

[dpdk-dev] Can't build DPDK-16.04 on CentOS 6.8

On 6/1/2016 9:07 PM, Martinx - ? wrote: > Guys, > > I'm trying to build DPDK-16.04 on CentOS 6.8, but it is failing, here is > the error: > > --- > ... > == Build lib/librte_eal/linuxapp > == Build lib/librte_eal/linuxapp/eal > == Build lib/librte_eal/linuxapp/igb_uio > CC eal.o > CC eal

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: > On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote: > > > > On 6/2/16, 12:11 PM, "Neil Horman" wrote: > > > > > > > >1) The definition of a config structure that can be passed to rte_eal_init, > > >defining the configuratio

[dpdk-dev] [PATCH v7 1/5] mempool: support external mempool operations

On 6/3/2016 7:38 AM, Jerin Jacob wrote: > On Thu, Jun 02, 2016 at 02:27:19PM +0100, David Hunt wrote: > > [snip] > >> /* create the internal ring if not already done */ >> if ((mp->flags & MEMPOOL_F_RING_CREATED) == 0) { > |> 1) May be RING can be replaced with some other higher abstrac

[dpdk-dev] Can't build DPDK-16.04 on CentOS 6.8

On 3 June 2016 at 06:45, Ferruh Yigit wrote: > On 6/1/2016 9:07 PM, Martinx - ? wrote: > > Guys, > > > > I'm trying to build DPDK-16.04 on CentOS 6.8, but it is failing, here is > > the error: > > > > --- > > ... > > == Build lib/librte_eal/linuxapp > > == Build lib/librte_eal/linuxapp/eal >

[dpdk-dev] RFC: DPDK Long Term Support

On Fri, Jun 03, 2016 at 03:07:49PM +, Mcnamara, John wrote: > What changes should be backported > - > > * Bug fixes that don't break the ABI. > > > What changes should not be backported > - > > * API or ABI breaking changes

[dpdk-dev] [PATCH v2 3/3] examples/l2fwd-crypto: enable AES counter mode cipher algorithm

This patch enables AES counter mode algorithm support to l2fwd-crypto sample application. Signed-off-by: Fan Zhang --- examples/l2fwd-crypto/main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c index d18c813..66fc874 100644 --- a/

[dpdk-dev] [PATCH v2 2/3] app/test: add aes-ni multi-buffer pmd test cases for AES CTR

Added tests cases for AES-NI MB PMD working in counter mode. Signed-off-by: Fan Zhang --- app/test/test_cryptodev.c | 13 + 1 file changed, 13 insertions(+) diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c index 03d6f02..45e6daa 100644 --- a/app/test/test_cryptodev

[dpdk-dev] [PATCH v2 1/3] aesni_mb: add counter mode support

This patch provides counter mode support to AES-NI multi-buffer library. The following cipher algorithm is enabled: - RTE_CRYPTO_CIPHER_AES_CTR Signed-off-by: Fan Zhang --- doc/guides/cryptodevs/aesni_mb.rst | 3 +++ doc/guides/cryptodevs/overview.rst | 6 +++--- doc/g

[dpdk-dev] [PATCH v2 0/3] Add AES Counter mode support for AES-NI MB PMD

This patchset adds counter mode support to AES-NI multi-buffer library and appropriate test cases. This patchset depends on the following patch/patchsets "doc: fix supported AES-CBC key lengths" (http://dpdk.org/dev/patchwork/patch/12398/) and "Added AES counter mode capability" (http://dpdk.org/

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 10:57:22AM +0100, Bruce Richardson wrote: > On Thu, Jun 02, 2016 at 07:17:05PM -0700, Matthew Hall wrote: > > On Thu, Jun 02, 2016 at 06:34:58PM -0400, Neil Horman wrote: > > > > This sort of code is very 1970s / ioctl / messy binary. And doesn't buy > > > > any > > > > pe

[dpdk-dev] [PATCH v2] e1000: configure VLAN TPID

This patch enables configuring the ether types of both inner and outer VLANs. Note that outer TPID of single VLAN and inner TPID of double VLAN are read only. Signed-off-by: Beilei Xing --- v2 changes: Modify return value. Cause inner tpid is not supported by single vlan, return -ENOTSUP. Add

[dpdk-dev] [PATCH v2] ixgbe: configure VLAN TPID

The patch enables configuring the ether types of both inner and outer VLANs. Signed-off-by: Beilei Xing --- v2 changes: Modify return value. since inner tpid is not supported by single vlan, return -ENOTSUP. Change meanning of function vlan_tpid_set. drivers/net/ixgbe/ixgbe_ethdev.c | 30 +++

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 07:17:05PM -0700, Matthew Hall wrote: > On Thu, Jun 02, 2016 at 06:34:58PM -0400, Neil Horman wrote: > > > This sort of code is very 1970s / ioctl / messy binary. And doesn't buy > > > any > > > performance advantage because it's just for config. > > > > > What!? I can't

[dpdk-dev] [PATCH v3] virtio: split virtio rx/tx queue

On Thu, Jun 02, 2016 at 12:12:13AM +0800, Huawei Xie wrote: > We keep a common vq structure, containing only vq related fields, > and then split others into RX, TX and control queue respectively. > > Signed-off-by: Huawei Xie Acked-by: Yuanhan Liu And applied to dpdk-next-virtio. Thanks.

[dpdk-dev] [PATCH] eal/x86: fix clang build with -O0

2016-06-03 10:16, Olivier MATZ: > On 06/03/2016 10:15 AM, Thomas Monjalon wrote: > > From: Damjan Marion > > > > Clang seems to have a bug with asm inside inline function rte_xabort(): > > > > rte_rtm.h:56:15: error: invalid operand for inline asm constraint 'i' > > asm volatile(".byte 0

[dpdk-dev] [PATCH] eal/x86: fix clang build with -O0

Hi Thomas, On 06/03/2016 10:15 AM, Thomas Monjalon wrote: > From: Damjan Marion > > Clang seems to have a bug with asm inside inline function rte_xabort(): > > rte_rtm.h:56:15: error: invalid operand for inline asm constraint 'i' > asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "m

[dpdk-dev] [PATCH] eal/x86: fix clang build with -O0

From: Damjan Marion Clang seems to have a bug with asm inside inline function rte_xabort(): rte_rtm.h:56:15: error: invalid operand for inline asm constraint 'i' asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); ^ It is seen only when building with EXT

[dpdk-dev] [PATCH 4/6] testpmd: handle all rxqs in rss setup

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wang, Zhihong > Sent: Thursday, May 26, 2016 10:55 AM > To: Thomas Monjalon > Cc: dev at dpdk.org; Ananyev, Konstantin ; > Richardson, Bruce ; De Lara Guarch, Pablo > > Subject: Re: [dpdk-dev] [PATCH 4/6] tes

[dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address.

On 02.06.2016 19:22, Rich Lane wrote: > On Thu, Jun 2, 2016 at 3:46 AM, Ilya Maximets > wrote: > > Hi, Rich. > Thank you for testing and analysing. > > On 01.06.2016 01:06, Rich Lane wrote: > > On Fri, May 20, 2016 at 5:50 AM, Ilya Maximets sams

[dpdk-dev] [PATCH 1/3] vhost: pre update used ring for Tx and Rx

On 6/1/2016 2:53 PM, Yuanhan Liu wrote: > On Wed, Jun 01, 2016 at 06:40:41AM +, Xie, Huawei wrote: >>> /* Retrieve all of the head indexes first to avoid caching issues. */ >>> for (i = 0; i < count; i++) { >>> - desc_indexes[i] = vq->avail->ring[(vq->last_used_idx + i) & >>>

[dpdk-dev] [PATCH v3 12/13] enic: expand local Tx mbuf flags variable to 64-bits

> Coverity issue: 13218 > Fixes: fefed3d1e62c ("enic: new driver") > > Suggested-by: Piotr Azarewicz > Signed-off-by: John Daley > --- > This is essentially patch http://www.dpdk.org/dev/patchwork/patch/12642 > applied after the enic_send_packet function was melded into the main > transmit funci

[dpdk-dev] [RFC] Yet another option for DPDK options

On Thu, Jun 02, 2016 at 07:17:05PM -0700, Matthew Hall wrote: > On Thu, Jun 02, 2016 at 06:34:58PM -0400, Neil Horman wrote: > > > This sort of code is very 1970s / ioctl / messy binary. And doesn't buy > > > any > > > performance advantage because it's just for config. > > > > > What!? I can't

[dpdk-dev] [RFC] Yet another option for DPDK options

On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote: > On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote: > > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote: > > > On Thu, Jun 02, 2016 at 07:41:10PM +, Wiles, Keith wrote: > > > > > > > > On 6/2/16, 12:1

[dpdk-dev] [PATCH 2/3] vhost: optimize dequeue for small packets

On 5/3/2016 8:42 AM, Yuanhan Liu wrote: > Both current kernel virtio driver and DPDK virtio driver use at least > 2 desc buffer for Tx: the first for storing the header, and the others > for storing the data. > > Therefore, we could fetch the first data desc buf before the main loop, > and do the c

[dpdk-dev] [PATCH 2/3] vhost: optimize dequeue for small packets

On 6/1/2016 2:41 PM, Yuanhan Liu wrote: > On Wed, Jun 01, 2016 at 06:24:18AM +, Xie, Huawei wrote: >> On 5/3/2016 8:42 AM, Yuanhan Liu wrote: >>> Both current kernel virtio driver and DPDK virtio driver use at least >>> 2 desc buffer for Tx: the first for storing the header, and the others >>>

[dpdk-dev] [PATCH v1] i40e: fix olflags for vector RX

Hi, > --- a/drivers/net/i40e/i40e_rxtx_vec.c > +++ b/drivers/net/i40e/i40e_rxtx_vec.c > @@ -149,7 +149,7 @@ desc_to_olflags_v(__m128i descs[4], struct rte_mbuf > **rx_pkts) > > /* mask everything except rss and vlan flags > *bit2 is for vlan tag, bits 13:12 for rss > */ Please,

[dpdk-dev] [PATCH v2] e1000: configure VLAN TPID

Hi, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Beilei Xing > Sent: Friday, June 3, 2016 10:59 AM > To: Lu, Wenzhuo > Cc: dev at dpdk.org; Xing, Beilei > Subject: [dpdk-dev] [PATCH v2] e1000: configure VLAN TPID > > This patch enables configuring the e

[dpdk-dev] [PATCH v2] ixgbe: configure VLAN TPID

Hi, > -Original Message- > From: Xing, Beilei > Sent: Friday, June 3, 2016 10:58 AM > To: Lu, Wenzhuo > Cc: dev at dpdk.org; Xing, Beilei > Subject: [PATCH v2] ixgbe: configure VLAN TPID > > The patch enables configuring the ether types of both inner and outer VLANs. > > Signed-off-by:

[dpdk-dev] [PATCH] ethdev: change comments of VLAN type

> -Original Message- > From: Lu, Wenzhuo > Sent: Friday, June 3, 2016 10:53 AM > To: Xing, Beilei ; Wu, Jingjing intel.com> > Cc: dev at dpdk.org; Xing, Beilei > Subject: RE: [dpdk-dev] [PATCH] ethdev: change comments of VLAN type > > Hi Beilei, > > > > -Original Message- > >

[dpdk-dev] [PATCH] e1000: configure VLAN TPID

> -Original Message- > From: Wang, Xiao W > Sent: Thursday, June 2, 2016 2:44 PM > To: Xing, Beilei ; Lu, Wenzhuo > > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH] e1000: configure VLAN TPID > > Hi Beilei, > > > -Original Message- > > From: dev [mailto:dev-bounces at dpd

[dpdk-dev] [PATCH] ethdev: change comments of VLAN type

Hi Beilei, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Beilei Xing > Sent: Thursday, May 26, 2016 3:28 PM > To: Wu, Jingjing > Cc: dev at dpdk.org; Xing, Beilei > Subject: [dpdk-dev] [PATCH] ethdev: change comments of VLAN type > > If the packet carries