[dpdk-dev] [PATCH] virtio: fix crash if VIRTIO_NET_F_CTRL_VQ is not negotiated

On 17 Sep 2014, at 09:32, Olivier MATZ wrote: > Hello, > > On 09/12/2014 12:25 AM, damarion at cisco.com wrote: >> From: Damjan Marion >> >> If VIRTIO_NET_F_CTRL_VQ is not negotiated hw->cvq will be NULL >> >> Signed-off-by: Damjan Marion >> --- >> lib/librte_pmd_virtio/virtio_rxtx.c | 6

[dpdk-dev] weak functions in some drivers

Hello, We just spent few hours troubleshooting why vPMD is not working in i40e driver. Conclusion was that problem is caused by linker linking the wrong instance of the i40e_rx_vec_dev_conf_condition_check(...). That function is defined 2 times, once in i40e_rxtx.c and once in i40e_rxtx_vec.c.

[dpdk-dev] weak functions in some drivers

> On 21 Jun 2016, at 09:01, Ferruh Yigit wrote: > > Hi Damjan, > > On 6/21/2016 4:01 PM, Damjan Marion (damarion) wrote: >> >> Hello, >> >> We just spent few hours troubleshooting why vPMD is not working >> in i40e driver. Conclusion was tha

[dpdk-dev] mmap fails with more than 40000 hugepages

Hi, I have system with 2 NUMA nodes and 256G RAM total. I noticed that DPDK crashes in rte_eal_init() when number of available hugepages is around 4 or above. Everything works fine with lower values (i.e. 3). I also tried with allocating 4 on node0 and 0 on node1, same crash happens.

[dpdk-dev] mmap fails with more than 40000 hugepages

> On 05 Feb 2015, at 13:59, Neil Horman wrote: > > On Thu, Feb 05, 2015 at 12:00:48PM +0000, Damjan Marion (damarion) wrote: >> Hi, >> >> I have system with 2 NUMA nodes and 256G RAM total. I noticed that DPDK >> crashes in rte_eal_init() >> when number

[dpdk-dev] mmap fails with more than 40000 hugepages

On 05 Feb 2015, at 14:22, Jay Rolette mailto:rolette at infiniteio.com>> wrote: On Thu, Feb 5, 2015 at 6:00 AM, Damjan Marion (damarion) mailto:damarion at cisco.com>> wrote: Hi, I have system with 2 NUMA nodes and 256G RAM total. I noticed that DPDK crashes in rte_eal_init() wh

[dpdk-dev] mmap fails with more than 40000 hugepages

> On 05 Feb 2015, at 15:59, Neil Horman wrote: > > On Thu, Feb 05, 2015 at 01:20:01PM +0000, Damjan Marion (damarion) wrote: >> >>> On 05 Feb 2015, at 13:59, Neil Horman wrote: >>> >>> On Thu, Feb 05, 2015 at 12:00:48PM +, Damjan Marion (damarion

[dpdk-dev] mmap fails with more than 40000 hugepages

> On 06 Feb 2015, at 11:26, De Lara Guarch, Pablo intel.com> wrote: > > > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Linhaifeng >> Sent: Friday, February 06, 2015 2:04 AM >> To: Damjan Marion (damarion); de

[dpdk-dev] 16.07-rc2 issue with rte_rtm_init(void) constructor

Folks, I have issues with linking application to 16.07-rc2. Looks like reason is constructor function in include file, so our unit test apps are failing to link as they are not linked with dpdk libs. (and they should not be as they are not calling any dpdk function). static inline void __attri

[dpdk-dev] 16.07-rc2 issue with rte_rtm_init(void) constructor

> On 14 Jul 2016, at 10:20, Thomas Monjalon > wrote: > > 2016-07-13 22:58, Damjan Marion: >> I have issues with linking application to 16.07-rc2. >> >> Looks like reason is constructor function in include file, >> so our unit test apps are failing to link as they are not linked with dpdk >> l

[dpdk-dev] 16.07-rc2 issue with rte_rtm_init(void) constructor

> On 14 Jul 2016, at 13:30, Thomas Monjalon > wrote: > > 2016-07-14 09:36, Damjan Marion: linking fails with: dpdk/include/rte_spinlock.h:103: undefined reference to `rte_cpu_get_flag_enabled? Is there any chance that this one is moved to some .c file, so it is

[dpdk-dev] spinlock: Move constructor function out of header file

Dear Jan, Thank you for your comments. A bit too much overhead to submit simple patch so let?s forget about it. I will just add it as it is to our private collection of patches. If anybody wants to pick it from here, please do... Thanks, Damjan > On 14 Jul 2016, at 20:03, Jan Viktorin wrote

[dpdk-dev] spinlock: Move constructor function out of header file

> On 15 Jul 2016, at 00:06, Thomas Monjalon > wrote: > > 2016-07-14 18:10, Damjan Marion: >> Dear Jan, >> >> Thank you for your comments. A bit too much overhead to submit simple patch >> so let?s forget about it. I will just add it as it is to our private >> collection of patches. > > These

[dpdk-dev] spinlock: Move constructor function out of header file

> On 15 Jul 2016, at 10:31, Thomas Monjalon > wrote: > > 2016-07-14 22:20, Damjan Marion: >> >>> On 15 Jul 2016, at 00:06, Thomas Monjalon >>> wrote: >>> >>> 2016-07-14 18:10, Damjan Marion: Dear Jan, Thank you for your comments. A bit too much overhead to submit simple patc

[dpdk-dev] spinlock: Move constructor function out of header file

> On 15 Jul 2016, at 12:09, Thomas Monjalon > wrote: > > 2016-07-15 09:54, Damjan Marion: >> So we don?t have much pending beside 2 patches for i40e which >> Jeff submitted yesterday and they will i guess need to wait for 16.11. > > Yes these i40e patches will probably have to wait 16.11. >

[dpdk-dev] spinlock: Move constructor function out of header file

> On 15 Jul 2016, at 17:08, Thomas Monjalon > wrote: > > 2016-07-15 16:37, Thomas Monjalon: >> I will apply it with trivial changes suggested by Jan and >> the small needed changes that I describe below: >> >> 2016-07-14 20:03, Jan Viktorin: >>> On Thu, 14 Jul 2016 15:27:29 +0200 >>> damarion

Re: [dpdk-dev] [PATCH] vfio: remove deprecated DMA mapping functions

> On 25 Oct 2019, at 00:32, Thomas Monjalon wrote: > > 24/10/2019 21:09, David Marchand: >> On Thu, Oct 24, 2019 at 2:18 PM Anatoly Burakov >> wrote: >>> >>> The rte_vfio_dma_map/unmap API's have been marked as deprecated in >>> release 19.05. Remove them. >>> >>> Signed-off-by: Anatoly Bura

Re: [dpdk-dev] [PATCH] vfio: remove deprecated DMA mapping functions

On 25 Oct 2019, at 14:23, Burakov, Anatoly mailto:anatoly.bura...@intel.com>> wrote: On 25-Oct-19 12:13 PM, Damjan Marion (damarion) wrote: On 25 Oct 2019, at 00:32, Thomas Monjalon mailto:tho...@monjalon.net>> wrote: 24/10/2019 21:09, David Marchand: On Thu, Oct 24, 2019 at 2:1

Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information

rruh >> ; jerinjac...@gmail.com; Ye, Xiaolong >> ; Kinsella, Ray ; Sun, >> Chenmin ; Slava Ovsiienko >> ; Damjan Marion (damarion) >> ; Liu, Yu Y >> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode >> information >> >

Re: [dpdk-dev] [PATCH] vfio: remove deprecated DMA mapping functions

On 25 Oct 2019, at 15:02, Damjan Marion (damarion) mailto:damar...@cisco.com>> wrote: On 25 Oct 2019, at 14:23, Burakov, Anatoly mailto:anatoly.bura...@intel.com>> wrote: On 25-Oct-19 12:13 PM, Damjan Marion (damarion) wrote: On 25 Oct 2019, at 00:32, Thomas Monjalon

Re: [dpdk-dev] [PATCH] vfio: remove deprecated DMA mapping functions

On 27 Oct 2019, at 08:00, Shahaf Shuler mailto:shah...@mellanox.com>> wrote: -Original Message- From: Damjan Marion (damarion) mailto:damar...@cisco.com>> Sent: Friday, October 25, 2019 2:14 PM To: Thomas Monjalon mailto:tho...@monjalon.net>> Cc: David Marchand

Re: [dpdk-dev] [PATCH] vfio: remove deprecated DMA mapping functions

> On 4 Nov 2019, at 18:27, Burakov, Anatoly wrote: > > On 04-Nov-19 1:57 PM, Damjan Marion (damarion) wrote: >>> On 25 Oct 2019, at 15:02, Damjan Marion (damarion) >> <mailto:damar...@cisco.com>> wrote: >>> >>> >>> >>>

Re: [dpdk-dev] [PATCH] vfio: remove deprecated DMA mapping functions

On 4 Nov 2019, at 18:42, Burakov, Anatoly mailto:anatoly.bura...@intel.com>> wrote: On 04-Nov-19 5:34 PM, Damjan Marion (damarion) wrote: On 4 Nov 2019, at 18:27, Burakov, Anatoly mailto:anatoly.bura...@intel.com>> wrote: On 04-Nov-19 1:57 PM, Damjan Marion (damarion) wrote: On

Re: [dpdk-dev] [RFC v5] /net: memory interface (memif)

> On 6 May 2019, at 13:00, Jakub Grajciar -X (jgrajcia - PANTHEON TECHNOLOGIES > at Cisco) wrote: > > > > From: Honnappa Nagarahalli > Sent: Friday, May 3, 2019 6:27 AM > To: Jakub Grajciar; Ferruh Yigit; dev@dpdk.org; Honnappa Nagarahalli > Cc: nd; n

Re: [dpdk-dev] [RFC v5] /net: memory interface (memif)

-- Damjan On 7 May 2019, at 13:29, Honnappa Nagarahalli mailto:honnappa.nagaraha...@arm.com>> wrote: On 3/22/2019 11:57 AM, Jakub Grajciar wrote: Memory interface (memif), provides high performance packet transfer over shared memory. Signed-off-by: Jakub Grajciar mailto:jgraj...@cisco.com>>

[dpdk-dev] Adding API to force freeing consumed buffers in TX ring

Hi, Currently in VPP we do memcpy of whole packet when we need to do replication as we cannot know if specific buffer is transmitted from tx ring before we update it again (i.e. l2 header rewrite). Unless there is already a way to address this issue in DPDK which I?m not aware of my proposal is

[dpdk-dev] [PATCH v2 2/2] i40e: Enable bad checksum flags in i40e vPMD

On 6 Oct 2016, at 04:19, Jeff Shaw mailto:jeffrey.b.shaw at intel.com>> wrote: On Wed, Oct 05, 2016 at 04:57:28PM -0700, Chen, Jing D wrote: Hi, -Original Message- From: Shaw, Jeffrey B Sent: Wednesday, October 5, 2016 5:13 PM To: dev at dpdk.org Cc: Zhang, Helin

[dpdk-dev] rte_mbuf.next in 2nd cacheline

Hi, We noticed 7% performance improvement by simply moving rte_mbuf.next field to the 1st cache line. Currently, it falls under /* second cache line - fields only used in slow path or on TX */ but it is actually used at several places in rx fast path. (e.g.: i40e_rx_alloc_bufs() is setting th

[dpdk-dev] rte_mbuf.next in 2nd cacheline

> On 15 Jun 2015, at 16:12, Bruce Richardson > wrote: > > The next pointers always start out as NULL when the mbuf pool is created. The > only time it is set to non-NULL is when we have chained mbufs. If we never > have > any chained mbufs, we never need to touch the next field, or even read i

[dpdk-dev] rte_mbuf.next in 2nd cacheline

> On 17 Jun 2015, at 16:06, Bruce Richardson > wrote: > > On Wed, Jun 17, 2015 at 01:55:57PM +0000, Damjan Marion (damarion) wrote: >> >>> On 15 Jun 2015, at 16:12, Bruce Richardson >>> wrote: >>> >>> The next pointers always sta