summaryrefslogtreecommitdiffstats
path: root/src/plugins/dpdk/buffer.c
AgeCommit message (Collapse)AuthorFilesLines
2017-10-25vlib: add support for multiple buffer poolsDamjan Marion1-11/+11
Change-Id: Icaf7d7ad47284aea7a56e8006b69f45874d64202 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-10-14plugins/dpdk: align memory to avoid potential segfault and false sharingGeorgina Sheehan1-1/+1
Made Update to src/plugins/dpdk/buffer.c Change-Id: I87bb8f38974a7be274c1b1d205f5513e7d068e48 Signed-off-by: Georgina <georgina.sheehan@intel.com>
2017-10-10dpdk: fix mempool size calculationDamjan Marion1-2/+3
Change-Id: I5b48310c46ca8a2143b2132110240d7e9a52c25d Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-10-04dpdk: use vpp physmem allocator for dpdk buffersDamjan Marion1-19/+66
This allows us to have single contignuous allocation for DPDK buffers with single mmap FD, so buffer memory can be easily shared with diffrent process. As a consequence dpdk socket-mem is no longer in charge for allocating buffer memory, but still we need some space allocated for dpdk structures so default socket-mem is reduced form 256 to 64 MB. For a default of 16K buffers per numa node, physmem allocation is now 40MB, so basically this change reduces footprint from 256MB per socket to 48 (64 + 40). Change-Id: Ic8cfe83930a18411545b37a12b14aac89affd04f Signed-off-by: Damjan Marion <damarion@cisco.com> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com> Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-09-15dpdk: cli to check for buffer leakageFlorin Coras1-1/+62
Use buffer pre_data and existing buffer trace trajectory code to find out dpdk buffer leakages. Change-Id: I26a5d8bd2f23d01cb6070ffc3ddcc6d3d863b575 Signed-off-by: Florin Coras <fcoras@cisco.com>
2017-08-25dpdk: bump to dpdk 17.08, remove support for dpdk 17.02Damjan Marion1-17/+0
Change-Id: I674fb1212e48693939045523df085326a4dd1809 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-07-13dpdk: fix dpdk_buffer_pool_create nameChris Luke1-1/+1
- vnet_buffer_pool_create should probably be named dpdk_buffer_pool_create since that is what it does. - Its prototype should also be in a DPDK plugin header, not in vlib/buffer_funcs.h, since the implementation is in the plugin and nobody else should be calling it. Change-Id: I7ba259afa4b888bc94f3ad257305e286b41e7370 Signed-off-by: Chris Luke <chrisy@flirble.org>
2017-07-10vlib: store buffer memory information in the buffer_mainDamjan Marion1-65/+4
Currently, buffer index is calculated as a offset to the physmem region shifted by log2_cacheline size. When DPDK is used we "hack" physmem data with information taken from dpdk mempool. This makes physmem code not usable with DPDK. This change makes buffer memory start and size independent of physmem basically allowing physmem to be used when DPDK plugin is loaded. Change-Id: Ieb399d398f147583b9baab467152a352d58c9c31 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-05-17dpdk: Do not check and set rte_mbuf refcnt if dpdk ver >= 17.05Damjan Marion1-0/+4
According to DPDK release notes this is done by DPDK. Also, it fixes assers in debug image. Change-Id: Ida1d25f8cd0c2232110e44eabd7dc3e512336758 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-05-09Fix remaining 32-bit compile issuesDamjan Marion1-3/+3
Change-Id: I9664214652229b663c3e3ba7406b4ede96bfb123 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-04-06Use thread local storage for thread indexDamjan Marion1-1/+1
This patch deprecates stack-based thread identification, Also removes requirement that thread stacks are adjacent. Finally, possibly annoying for some folks, it renames all occurences of cpu_index and cpu_number with thread index. Using word "cpu" is misleading here as thread can be migrated ti different CPU, and also it is not related to linux cpu index. Change-Id: I68cdaf661e701d2336fc953dcb9978d10a70f7c1 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-03-01dpdk: be a pluginDamjan Marion1-0/+588
Change-Id: I238258cdeb77035adc5e88903d824593d0a1da90 Signed-off-by: Damjan Marion <damarion@cisco.com>