From: Phil Yang
Add 128-bit atomic compare exchange on aarch64.
Suggested-by: Jerin Jacob
Signed-off-by: Phil Yang
Reviewed-by: Honnappa Nagarahalli
Tested-by: Honnappa Nagarahalli
Acked-by: Jerin Jacob
---
v8:
Fixed "WARNING:LONG_LINE: line over 80 characters" warnings with latest kernel
From: Phil Yang
Add 128b atomic compare and swap test for aarch64 and x86_64.
Signed-off-by: Phil Yang
Reviewed-by: Honnappa Nagarahalli
Acked-by: Gage Eads
Acked-by: Jerin Jacob
Tested-by: Jerin Jacob
---
app/test/test_atomic.c | 125 -
1 file chang
From: Phil Yang
Enable both c11 atomic and non c11 atomic lock-free stack for aarch64.
Introduced a new header to reduce the ifdef clutter across generic and c11
files. The rte_stack_lf_stubs.h contains stub implementations of
__rte_stack_lf_count, __rte_stack_lf_push_elems and
__rte_stack_lf_po
> -Original Message-
> From: Xing, Beilei
> Sent: Tuesday, July 23, 2019 1:28 PM
> To: Ye, Xiaolong ; Yigit, Ferruh
> ; Zhang, Qi Z
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH 1/2] net/i40e: fix ether pattern rule for fdir
>
>
>
> > -Original Message-
> > From:
> >
> > [master]dell[dpdk.org] $ ./devtools/checkpatches.sh
>
> Yes. I did this check before upstream this patch.
> I ignored ' WARNING:MACRO_WITH_FLOW_CONTROL: Macros with flow
> control statements should be avoided ' warnings.
> However, I didn't see any LONG_LINE warnings in the CI report here.
> -Original Message-
> From: Ye, Xiaolong
> Sent: Monday, July 22, 2019 8:07 PM
> To: Yigit, Ferruh ; Xing, Beilei
> ; Zhang, Qi Z
> Cc: dev@dpdk.org; Ye, Xiaolong ; sta...@dpdk.org;
> Li, Xiaoyun
> Subject: [PATCH 2/2] net/i40e: fix fdir rule destroy failure
>
> We should tear down t
23/07/2019 07:27, Jerin Jacob Kollanukkaran:
> From: Stojaczyk, Dariusz
> > From: Jerin Jacob Kollanukkaran [mailto:jer...@marvell.com]
> > > From: Stojaczyk, Dariusz
> > > >
> > > > This introduces a regression where uio-bound devies are attached to
> > > > a DPDK app at runtime.
Yes it is a re
> -Original Message-
> From: Xing, Beilei
> Sent: Tuesday, July 23, 2019 3:12 PM
> To: Ye, Xiaolong ; Yigit, Ferruh
> ; Zhang, Qi Z
> Cc: dev@dpdk.org; sta...@dpdk.org; Li, Xiaoyun
> Subject: RE: [PATCH 2/2] net/i40e: fix fdir rule destroy failure
>
>
>
> > -Original Message
> -Original Message-
> From: Zhao1, Wei
> Sent: Tuesday, July 23, 2019 12:13 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Zhang, Qi Z ; Zhao1, Wei
>
> Subject: [PATCH v2] net/ixgbe: fix x550 Reta set fail error
>
> There is a bug in function ixgbevf_dev_info_get(), it do not contain th
Hi,
> -Original Message-
> From: dev On Behalf Of Dekel Peled
> Sent: Monday, July 22, 2019 6:37 PM
> To: Yongseok Koh ; Slava Ovsiienko
> ; Shahaf Shuler
> Cc: Jack Min ; Ori Kam ;
> dev@dpdk.org; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH v2] net/mlx5: fix NVGRE matching
>
> NVGRE h
> -Original Message-
> From: Jerin Jacob Kollanukkaran
> Sent: Tuesday, July 23, 2019 3:10 PM
> To: Phil Yang (Arm Technology China) ; dev@dpdk.org
> Cc: tho...@monjalon.net; gage.e...@intel.com;
> hemant.agra...@nxp.com; Honnappa Nagarahalli
> ; Gavin Hu (Arm Technology China)
> ; nd ; nd
22/07/2019 20:34, Stephen Hemminger:
> On Mon, 22 Jul 2019 19:31:08 +0200
> Thomas Monjalon wrote:
>
> > 22/07/2019 19:13, Stephen Hemminger:
> > > Thomas Monjalon wrote:
> > > > Are the constructors run on dlopen of the bus driver?
> > >
> > > Yes, constructors are run on dlopen.
> > > But
From: Nithin Dabilpuram
This reverts commit 89aac60e0be9ed95a87b16e3595f102f9faaffb4.
"vfio: fix interrupts race condition"
The above mentioned commit moves the interrupt's eventfd setup
to probe time but only enables one interrupt for all types of
interrupt handles i.e VFIO_MSI, VFIO_LEGACY, VF
22/07/2019 20:34, Ferruh Yigit:
> On 7/22/2019 6:57 PM, Lance Richardson wrote:
> > On Mon, Jul 22, 2019 at 11:06 AM Thomas Monjalon
> > wrote:
> >> 22/07/2019 16:57, Ferruh Yigit:
> >>> On 7/18/2019 4:36 AM, Ajit Khaparde wrote:
> From: Lance Richardson
> --- a/config/common_base
> >>
From: Nithin Dabilpuram
Add new ack interrupt API to avoid using
VFIO_IRQ_SET_ACTION_TRIGGER(rte_intr_enable()) for
acking interrupt purpose for VFIO based interrupt handlers.
This implementation is specific to Linux.
Using rte_intr_enable() for acking interrupt has below issues
* Time consumi
From: Nithin Dabilpuram
Replace rte_intr_enable() with rte_intr_ack() API
for acking an interrupt in interrupt handlers and
rx_queue_intr_enable() callbacks of PMD's.
This is inline with original intent of this change in PMDs
to ack interrupts after handling is completed if
device is backed by U
>From Nithin original cover letter:
A final patch for below mentioned RFC patch discussions.
[RFC PATCH v3 1/3] vfio: revert change that does intr eventfd setup at
probe http://mails.dpdk.org/archives/dev/2019-July/138358.html
[RFC PATCH v3 2/3] eal: add mask and unmask interrupt APIs
http://m
From: Kiran Kumar K
Add new rte_flow_item_nsh in order to match the network service header
based on RFC 8300.
Signed-off-by: Kiran Kumar K
---
lib/librte_ethdev/rte_flow.c | 1 +
lib/librte_ethdev/rte_flow.h | 39
2 files changed, 40 insertions(+)
diff --
From: Kiran Kumar K
Add new rte_flow_item_ah in order to match the Authentication Header
based on RFC 2402.
Signed-off-by: Kiran Kumar K
---
lib/librte_ethdev/rte_flow.c | 1 +
lib/librte_ethdev/rte_flow.h | 31 +++
2 files changed, 32 insertions(+)
diff --git a/l
From: Kiran Kumar K
Add new rte_flow_item_igmp in order to match the Internet Group
Management Protocol based on RFC 2236.
Signed-off-by: Kiran Kumar K
---
lib/librte_ethdev/rte_flow.c | 1 +
lib/librte_ethdev/rte_flow.h | 31 +++
2 files changed, 32 insertions(+)
On 19-07-22 14:44, Bruce Richardson wrote:
> External Email
>
> --
> On Mon, Jul 22, 2019 at 02:39:59PM +0200, kka...@marvell.com wrote:
> > From: Krzysztof Kanas
> >
> > gcc prior 9 don't will add additional warning for unrecog
Hi Ferruh,
> >> Duplication is bad, it is bad to have two different ways to do same thing.
> >> I am not sure if Vivek is aware of duplicated functions but
> >> explicitly prefers to update old versions.
> >> I suggest lets stop improving these ones and get rid of them asap.
> >
> > Testpmd is w
On 22-Jul-19 6:03 PM, Thomas Monjalon wrote:
22/07/2019 18:55, Thomas Monjalon:
When using --no-huge mode, dynamic allocation is not supported.
Because of this limitation, the option --legacy-mem is implied
and -m may be needed to specify the amount of memory to allocate.
Otherwise the default a
rte_eth_dev_info_get() returns void and caller does know if the function
does its job or not. Changing of the return value to int would be
API/ABI breakage which requires deprecation process and cannot be
backported to stable branches. For now, make sure that device info is
initialized even in the
On 23-Jul-19 6:27 AM, Jerin Jacob Kollanukkaran wrote:
-Original Message-
From: Stojaczyk, Dariusz
Sent: Tuesday, July 23, 2019 10:24 AM
To: Jerin Jacob Kollanukkaran ; Thomas Monjalon
; David Marchand ;
Burakov, Anatoly
Cc: dev@dpdk.org
Subject: [EXT] RE: [dpdk-dev] [PATCH v4 0/4] Fixe
When using IOVA as VA mode, there is no need to map segments
page by page. This normally isn't a problem, but it becomes one
when attempting to use DPDK in no-huge mode, where VFIO subsystem
simply runs out of space to store mappings.
Fix this for x86 by triggering different callbacks based on whe
23/07/2019 10:04, David Marchand:
> From Nithin original cover letter:
> This patch set basically reverts vfio patch that moves eventfd setup
> to probe time (1/3) because msix initialization is broken.
> It adds new ack interrupt api for purposes of simple and light
> weight ack method and also t
This patch fixes the issue of memory overwrite after the end of
the output buffer by calculating its size as the number of all
segments multipled by the output segment size.
Additionally buffer overflow errors returned by PMD driver are
detected and shown, ending the test.
Also the output buffer s
23/07/2019 11:57, Burakov, Anatoly:
> A machine without an IOMMU shouldn't have picked IOVA as VA in the first
> place. Perhaps this is something we could fix? I'm not sure how to
> detected that condition though, i don't think there's a mechanism to
> know that for sure. Some kernels create a "
Subject: [PATCH] vfio: use contiguous mapping for IOVA as VA mode
When using IOVA as VA mode, there is no need to map segments page by page. This
normally isn't a problem, but it becomes one when attempting to use DPDK in
no-huge mode, where VFIO subsystem simply runs out of space to store ma
On 7/23/2019 10:13 AM, Andrew Rybchenko wrote:
> rte_eth_dev_info_get() returns void and caller does know if the function
> does its job or not. Changing of the return value to int would be
> API/ABI breakage which requires deprecation process and cannot be
> backported to stable branches. For now,
On 7/23/2019 7:39 AM, Raslan Darawsheh wrote:
> Tested-by: Raslan Darawsheh
> Seems OK for me,
>
> Kindest regards,
> Raslan Darawsheh
>
>> -Original Message-
>> From: Stephen Hemminger
>> Sent: Monday, July 22, 2019 8:20 PM
>> To: Ferruh Yigit
>> Cc: Adrien Mazarguil ; Wenzhuo Lu
>>
On 7/23/19 8:38 AM, vattun...@marvell.com wrote:
From: Vamsi Attunuru
When KNI operates in IOVA = VA mode, it requires mbuf memory
to be physically contiguous to ensure KNI kernel module could
translate IOVA addresses properly. Patch adds a KNI specific
mempool create routine to populate the KN
On 7/22/2019 3:51 PM, Matan Azrad wrote:
> From: Dekel Peled
>
> A variable of type struct ibv_cq_ex is declared in 2 unions, but
> isn't used.
> This patch removes the 2 redundant declarations.
This is not a fix, but I think it still make sense to request backporting these
kind of refactoring to
Yes, the platform can be detected at runtime
from the PCI device ID. This would be a better
approach than adding a configuration parameter,
I think. I'll take a look.
Thanks,
Lance
On Tue, Jul 23, 2019 at 4:04 AM Thomas Monjalon wrote:
>
> 22/07/2019 20:34, Ferruh Yigit:
> > On 7/22/2019 6:5
On 7/23/19 8:38 AM, vattun...@marvell.com wrote:
From: Vamsi Attunuru
Current KNI implementation only operates in IOVA=PA mode, patch adds
required functionality in KNI lib to support IOVA=VA mode.
KNI kernel module requires device info to get iommu domain related
information for IOVA addr rel
This was missed when promoting this API to stable.
Fixes: 7a0ac7cdb454 ("service: promote experimental functions to stable")
Signed-off-by: David Marchand
---
lib/librte_eal/common/include/rte_service.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_serv
> -Original Message-
> From: Andrew Rybchenko
> Sent: Tuesday, July 23, 2019 4:20 PM
> To: Vamsi Krishna Attunuru ; dev@dpdk.org
> Cc: tho...@monjalon.net; Jerin Jacob Kollanukkaran ;
> olivier.m...@6wind.com; ferruh.yi...@intel.com; anatoly.bura...@intel.com;
> Kiran Kumar Kokkilagadda
CID 340857: Null pointer dereferences (NULL_RETURNS)
CID 340856: (CONSTANT_EXPRESSION_RESULT)
Fixes: 3be12ea52ad8 ("test/compress: improve debug trace setup")
Signed-off-by: Adam Dybkowski
---
app/test/test_compressdev.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --
On 7/23/19 8:38 AM, vattun...@marvell.com wrote:
From: Vamsi Attunuru
Patch adds a routine to populate mempool from page aligned and
page sized chunks of memory to ensures memory objs do not fall
across the page boundaries. It's useful for applications that
require physically contiguous mbuf me
On Tue, Jul 16, 2019 at 5:29 PM Ferruh Yigit wrote:
>
> On 7/16/2019 4:00 PM, Andrew Rybchenko wrote:
> > On 7/16/19 5:28 PM, Bruce Richardson wrote:
> >> On Tue, Jul 16, 2019 at 03:23:03PM +0100, Ferruh Yigit wrote:
> >>> On 7/16/2019 1:23 PM, Andrew Rybchenko wrote:
> On 7/15/19 5:53 PM, Fe
On 7/19/19 7:56 PM, Stephen Hemminger wrote:
Tell users about upcoming changes to rte_ether_addr and
rte_ether_header.
Signed-off-by: Stephen Hemminger
Acked-by: Bruce Richardson
Acked-by: Andrew Rybchenko
Hi,
>-Original Message-
>From: Bruce Richardson [mailto:bruce.richard...@intel.com]
>Sent: Monday, July 22, 2019 7:23 PM
>To: Thomas Monjalon
>Cc: Parthasarathy, JananeeX M ;
>dev@dpdk.org; Michael Santana Francisco ; Aaron
>Conole ; Hari Kumar Vemula
>; Pattan, Reshma
>; Mcnamara, John ;
Hi Ferruh
From: Ferruh Yigit
> On 7/22/2019 3:51 PM, Matan Azrad wrote:
> > From: Dekel Peled
> >
> > A variable of type struct ibv_cq_ex is declared in 2 unions, but isn't
> > used.
> > This patch removes the 2 redundant declarations.
> This is not a fix, but I think it still make sense to req
rte_eth_dev_info_get() returns void and caller does know if the function
does its job or not. Changing of the return value to int would be
API/ABI breakage which requires deprecation process and cannot be
backported to stable branches. For now, make sure that device info is
initialized even in the
Added new unit test cases to cover the below
functions defined in rte_mbuf.h
rte_validate_tx_offload,
rte_pktmbuf_alloc_bulk,
rte_pktmbuf_read,
rte_pktmbuf_ext_shinfo_init_helper,
rte_pktmbuf_attach_extbuf,
rte_mbuf_ext_refcnt_read,
rte_mbuf_ext_refcnt_update,
rte_mbuf_ext_refcnt_set,
rte_pktmbuf_d
This patchset contains unit testcases added to increase the
functional and decision coverage for the library functions
defined in rte_mbuf.h and rte_mbuf.c
1/2: unit test cases added for rte_mbuf.h
2/2: unit test cases added for rte_mbuf.c
Patch 2/2 depends on 1/2
Signed-off-by: Lavanya Govinda
On 7/23/19 1:40 PM, Ferruh Yigit wrote:
On 7/23/2019 10:13 AM, Andrew Rybchenko wrote:
rte_eth_dev_info_get() returns void and caller does know if the function
does its job or not. Changing of the return value to int would be
API/ABI breakage which requires deprecation process and cannot be
back
From: Pallantla Poornima
Added UT for the below four functions in test_mbuf.c
rte_get_rx_ol_flag_list
rte_get_tx_ol_flag_list
rte_get_rx_ol_flag_name
rte_get_tx_ol_flag_name
Signed-off-by: Pallantla Poornima
---
app/test/test_mbuf.c | 260 +++
1 file cha
> -Original Message-
> From: Andrew Rybchenko
> Sent: Tuesday, July 23, 2019 4:38 PM
> To: Vamsi Krishna Attunuru ; dev@dpdk.org
> Cc: tho...@monjalon.net; Jerin Jacob Kollanukkaran ;
> olivier.m...@6wind.com; ferruh.yi...@intel.com;
> anatoly.bura...@intel.com; Kiran Kumar Kokkilagadda
On Mon, Jul 22, 2019 at 11:53:26AM -0700, Stephen Hemminger wrote:
> On Mon, 22 Jul 2019 19:31:08 +0200
> Thomas Monjalon wrote:
>
> > 22/07/2019 19:13, Stephen Hemminger:
> > > Thomas Monjalon wrote:
> > > > Are the constructors run on dlopen of the bus driver?
> > >
> > > Yes, constructor
> -Original Message-
> From: Ferruh Yigit
> Sent: Wednesday, July 10, 2019 5:07 PM
> To: Jakub Grajciar -X (jgrajcia - PANTHEON TECHNOLOGIES at Cisco)
> ; dev@dpdk.org
> Cc: anatoly.bura...@intel.com
> Subject: Re: [dpdk-dev] [PATCH v4] net/memif: zero-copy slave
>
> On 7/9/2019 9:22 AM
23/07/2019 14:16, Andrew Rybchenko:
> On 7/23/19 1:40 PM, Ferruh Yigit wrote:
> > On 7/23/2019 10:13 AM, Andrew Rybchenko wrote:
> >> rte_eth_dev_info_get() returns void and caller does know if the function
> >> does its job or not. Changing of the return value to int would be
> >> API/ABI breakage
23/07/2019 14:11, Andrew Rybchenko:
> rte_eth_dev_info_get() returns void and caller does know if the function
> does its job or not. Changing of the return value to int would be
> API/ABI breakage which requires deprecation process and cannot be
> backported to stable branches. For now, make sure
On Tue, Jul 23, 2019 at 09:05:50AM +, Krzysztof Kanas wrote:
> On 19-07-22 14:44, Bruce Richardson wrote:
> > External Email
> >
> > --
> > On Mon, Jul 22, 2019 at 02:39:59PM +0200, kka...@marvell.com wrote:
> > > From: Krzysz
Currently, primary process holds an exclusive lock on the config
file, thereby preventing other primaries from spinning up. However,
when the primary dies, the lock is no longer being held, even though
there might be other secondary processes still running.
The fix is two-fold. First of all, downg
Thanks David.
> -Original Message-
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Tuesday, July 23, 2019 6:00 AM
> To: dev@dpdk.org
> Cc: Eads, Gage ; Van Haaren, Harry
>
> Subject: [PATCH] service: remove experimental banner in API description
>
> This was missed when
On 7/23/19 4:14 PM, Thomas Monjalon wrote:
23/07/2019 14:11, Andrew Rybchenko:
rte_eth_dev_info_get() returns void and caller does know if the function
does its job or not. Changing of the return value to int would be
API/ABI breakage which requires deprecation process and cannot be
backported t
23/07/2019 15:34, Andrew Rybchenko:
> On 7/23/19 4:14 PM, Thomas Monjalon wrote:
> > 23/07/2019 14:11, Andrew Rybchenko:
> >> rte_eth_dev_info_get() returns void and caller does know if the function
> >> does its job or not. Changing of the return value to int would be
> >> API/ABI breakage which r
On 23-Jul-19 11:25 AM, Thomas Monjalon wrote:
23/07/2019 11:57, Burakov, Anatoly:
A machine without an IOMMU shouldn't have picked IOVA as VA in the first
place. Perhaps this is something we could fix? I'm not sure how to
detected that condition though, i don't think there's a mechanism to
know
void return value is bad for get API (like rte_eth_dev_info-get())
since caller does not know if the function does its job or not and
output value is filled in.
void return value is bad for state changing API (like
rte_eth_promiscuous_enable()) since caller should use get API
to understand if stat
On 7/23/2019 3:07 PM, Andrew Rybchenko wrote:
> void return value is bad for get API (like rte_eth_dev_info-get())
> since caller does not know if the function does its job or not and
> output value is filled in.
>
> void return value is bad for state changing API (like
> rte_eth_promiscuous_enabl
> -Original Message-
> From: Burakov, Anatoly
> Sent: Tuesday, July 23, 2019 7:27 PM
> To: Thomas Monjalon
> Cc: Jerin Jacob Kollanukkaran ; Stojaczyk, Dariusz
> ; David Marchand
> ; dev@dpdk.org
> Subject: [EXT] Re: [dpdk-dev] [PATCH v4 0/4] Fixes on IOVA mode selection
>
>
On 23-Jul-19 2:56 PM, Burakov, Anatoly wrote:
On 23-Jul-19 11:25 AM, Thomas Monjalon wrote:
23/07/2019 11:57, Burakov, Anatoly:
A machine without an IOMMU shouldn't have picked IOVA as VA in the first
place. Perhaps this is something we could fix? I'm not sure how to
detected that condition tho
> -Original Message-
> From: Burakov, Anatoly
> Sent: Tuesday, July 23, 2019 8:00 PM
> To: Thomas Monjalon
> Cc: Jerin Jacob Kollanukkaran ; Stojaczyk, Dariusz
> ; David Marchand
> ; dev@dpdk.org
> Subject: [EXT] Re: [dpdk-dev] [PATCH v4 0/4] Fixes on IOVA mode selection
> On 23-Jul-19 2:
On Tue, 23 Jul 2019 15:07:51 +0100
Andrew Rybchenko wrote:
> void return value is bad for get API (like rte_eth_dev_info-get())
> since caller does not know if the function does its job or not and
> output value is filled in.
>
> void return value is bad for state changing API (like
> rte_eth_pr
On 7/23/19 5:38 PM, Stephen Hemminger wrote:
On Tue, 23 Jul 2019 15:07:51 +0100
Andrew Rybchenko wrote:
void return value is bad for get API (like rte_eth_dev_info-get())
since caller does not know if the function does its job or not and
output value is filled in.
void return value is bad for
Function mlx5_rxq_release() calls mlx5_release_dbr() to release the
doorbell allocated for this Rx queue.
This call is relevant only for Rx queue objects created using
DevX API.
This patch adds the required check, to call mlx5_release_dbr()
only when relevant.
It also updates mlx5_release_dbr() to
Hello,
We are chasing an interesting NIC transmit issue where after some period of
time with normal operation the NIC enters a state where it refuses to transmit
frames from our DPDK application via rte_eth_tx_burst(). All indications are
the port is up and otherwise operational and is still re
On 07/23, Wei Zhao wrote:
>There is a bug in function ixgbevf_dev_info_get(), it do not
>contain the reta table size get function for vf port, and this
>will cause error when update reta for x550 vf port. And also
>when function ixgbe_reta_size_get() is called, it should return
>other ixgbe NIC vf
Function rxq_release_rq_resources() releases resources of RQ object
created by DevX API.
This patch updates this function to properly clear the released
resources, to avoid repeated release of the same resource.
Fixes: 69abf7b1db4a ("net/mlx5: create advanced RxQ using new API")
Signed-off-by: D
The rte_wait_until_equalxx APIs abstract the functionality of 'polling
for a memory location to become equal to a given value'.
Signed-off-by: Gavin Hu
Reviewed-by: Ruifeng Wang
Reviewed-by: Steve Capper
Reviewed-by: Ola Liljedahl
Reviewed-by: Honnappa Nagarahalli
Acked-by: Pavan Nikhilesh
-
In acquiring a spinlock, cores repeatedly poll the lock variable.
This is replaced by rte_wait_until_equal API.
5~10% performance gain was measured by running spinlock_autotest on
14 isolated cores of ThunderX2.
Signed-off-by: Gavin Hu
Reviewed-by: Ruifeng Wang
Reviewed-by: Phil Yang
Reviewed-
Instead of polling for tail to be updated, use wfe instruction.
Signed-off-by: Gavin Hu
Reviewed-by: Ruifeng Wang
Reviewed-by: Steve Capper
Reviewed-by: Ola Liljedahl
Reviewed-by: Honnappa Nagarahalli
---
lib/librte_ring/rte_ring_c11_mem.h | 4 ++--
lib/librte_ring/rte_ring_generic.h | 3 +--
While using ticket lock, cores repeatedly poll the lock variable.
This is replaced by rte_wait_until_equal API.
Running ticketlock_autotest on ThunderX2, with different numbers of cores
and depths of rings, 3%~8% performance gains were measured.
Signed-off-by: Gavin Hu
Reviewed-by: Honnappa Naga
Add the RTE_USE_WFE configuration entry for aarch64, disabled by default.
It can be enabled selectively based on the performance benchmarking.
Signed-off-by: Gavin Hu
Reviewed-by: Ruifeng Wang
Reviewed-by: Steve Capper
Reviewed-by: Honnappa Nagarahalli
Acked-by: Pavan Nikhilesh
---
config/ar
DPDK has multiple use cases where the core repeatedly polls a location in
memory. This polling results in many cache and memory transactions.
Arm architecture provides WFE (Wait For Event) instruction, which allows
the cpu core to enter a low power state until woken up by the update to the
memory
On 23-Jul-19 3:36 PM, Jerin Jacob Kollanukkaran wrote:
-Original Message-
From: Burakov, Anatoly
Sent: Tuesday, July 23, 2019 8:00 PM
To: Thomas Monjalon
Cc: Jerin Jacob Kollanukkaran ; Stojaczyk, Dariusz
; David Marchand
; dev@dpdk.org
Subject: [EXT] Re: [dpdk-dev] [PATCH v4 0/4] Fixes
Hi Stephen,
> -Original Message-
> From: Pavan Nikhilesh Bhagavatula
> Sent: Saturday, July 20, 2019 3:03 PM
> To: Gavin Hu (Arm Technology China) ; dev@dpdk.org
> Cc: nd
> Subject: RE: [dpdk-dev] [RFC v2 5/5] config: add WFE config entry for
> aarch64
>
>
>
> >-Original Message---
>
> Hello,
>
> We are chasing an interesting NIC transmit issue where after some period of
> time with normal operation the NIC enters a state where it
> refuses to transmit frames from our DPDK application via rte_eth_tx_burst().
> All indications are the port is up and otherwise operation
Some builds with clang report an error because '<>' rather than '""' were
used for including the ioat spec header file.
Target: x86_64-native-bsdapp-clang
22:10: error: 'rte_ioat_spec.h' file not found with include; use
"quotes" instead
#include
^
"rt
Konstantin,
Thank you for the prompt reply on this posting. In looking at the single
use-case in test-pmd's csumonly.c, it would seem prepare + retry_enabled may
have some shortcomings as currently coded when nb_prep < nb_rx. Has anyone
looked at this? I happened to notice this when looking for
On Tue, 23 Jul 2019 23:43:46 +0800
Gavin Hu wrote:
> Add the RTE_USE_WFE configuration entry for aarch64, disabled by default.
> It can be enabled selectively based on the performance benchmarking.
>
> Signed-off-by: Gavin Hu
> Reviewed-by: Ruifeng Wang
> Reviewed-by: Steve Capper
> Reviewed-
On Tue, 23 Jul 2019 13:30:33 +0100
Bruce Richardson wrote:
> On Mon, Jul 22, 2019 at 11:53:26AM -0700, Stephen Hemminger wrote:
> > On Mon, 22 Jul 2019 19:31:08 +0200
> > Thomas Monjalon wrote:
> >
> > > 22/07/2019 19:13, Stephen Hemminger:
> > > > Thomas Monjalon wrote:
> > > > > Are
On Tue, 23 Jul 2019 09:59:04 +0200
Thomas Monjalon wrote:
> 22/07/2019 20:34, Stephen Hemminger:
> > On Mon, 22 Jul 2019 19:31:08 +0200
> > Thomas Monjalon wrote:
> >
> > > 22/07/2019 19:13, Stephen Hemminger:
> > > > Thomas Monjalon wrote:
> > > > > Are the constructors run on dlopen
23/07/2019 20:29, Stephen Hemminger:
> On Tue, 23 Jul 2019 09:59:04 +0200
> Thomas Monjalon wrote:
>
> > 22/07/2019 20:34, Stephen Hemminger:
> > > On Mon, 22 Jul 2019 19:31:08 +0200
> > > Thomas Monjalon wrote:
> > >
> > > > 22/07/2019 19:13, Stephen Hemminger:
> > > > > Thomas Monjalon w
On Tue, 23 Jul 2019 14:19:53 +0100
Anatoly Burakov wrote:
> diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
> index 34db78753..54feb24a3 100644
> --- a/lib/librte_eal/linux/eal/eal.c
> +++ b/lib/librte_eal/linux/eal/eal.c
> @@ -83,6 +83,13 @@ static struct flock wr_lo
23/07/2019 15:39, Thomas Monjalon:
> 23/07/2019 15:34, Andrew Rybchenko:
> > On 7/23/19 4:14 PM, Thomas Monjalon wrote:
> > > 23/07/2019 14:11, Andrew Rybchenko:
> > >> rte_eth_dev_info_get() returns void and caller does know if the function
> > >> does its job or not. Changing of the return value
On Tue, 23 Jul 2019 13:30:33 +0100
Bruce Richardson wrote:
> On Mon, Jul 22, 2019 at 11:53:26AM -0700, Stephen Hemminger wrote:
> > On Mon, 22 Jul 2019 19:31:08 +0200
> > Thomas Monjalon wrote:
> >
> > > 22/07/2019 19:13, Stephen Hemminger:
> > > > Thomas Monjalon wrote:
> > > > > Are
23/07/2019 12:30, Sirvys, Andrius:
> When using IOVA as VA mode, there is no need to map segments page by page.
> This normally isn't a problem, but it becomes one when attempting to use DPDK
> in no-huge mode, where VFIO subsystem simply runs out of space to store
> mappings.
>
> Fix this for
23/07/2019 18:26, Bruce Richardson:
> Some builds with clang report an error because '<>' rather than '""' were
> used for including the ioat spec header file.
>
> Target: x86_64-native-bsdapp-clang
> 22:10: error: 'rte_ioat_spec.h' file not found with include; use
> "quotes" instead
> #in
On Tue, Jul 23, 2019 at 6:27 PM Bruce Richardson
wrote:
>
> Some builds with clang report an error because '<>' rather than '""' were
> used for including the ioat spec header file.
>
> Target: x86_64-native-bsdapp-clang
> 22:10: error: 'rte_ioat_spec.h' file not found with include; use
> "q
>
> On Tue, 23 Jul 2019 23:43:46 +0800
> Gavin Hu wrote:
>
> > Add the RTE_USE_WFE configuration entry for aarch64, disabled by default.
> > It can be enabled selectively based on the performance benchmarking.
> >
> > Signed-off-by: Gavin Hu
> > Reviewed-by: Ruifeng Wang
> > Reviewed-by: Steve
Hi Gavin,
I think this should have been V1 (I mean, no versioning, just 'PATCH'),
since it is converted to patch. I think we should be able to resend it as V1
and mark this V3 as 'superseded'.
Hi Thomas,
Please let us know if it is worth/helps fixing the version.
Thanks,
Honnapp
On 7/23/19 3:28 PM, Vamsi Krishna Attunuru wrote:
-Original Message-
From: Andrew Rybchenko
Sent: Tuesday, July 23, 2019 4:38 PM
To: Vamsi Krishna Attunuru ; dev@dpdk.org
Cc: tho...@monjalon.net; Jerin Jacob Kollanukkaran ;
olivier.m...@6wind.com; ferruh.yi...@intel.com;
anatoly.bura...@
> -Original Message-
> From: Zhang, Qi Z
> Sent: Monday, July 22, 2019 8:51 PM
> To: Yang, Qiming ; Lu, Wenzhuo
>
> Cc: Stillwell Jr, Paul M ; dev@dpdk.org; Zhang,
> Qi Z
> Subject: [PATCH 0/6] net/ice/base: couple share code fix
>
> Qi Zhang (6):
> net/ice/base: fix inner TCP and UD
23/07/2019 21:15, Honnappa Nagarahalli:
> Hi Gavin,
> I think this should have been V1 (I mean, no versioning, just 'PATCH'),
> since it is converted to patch. I think we should be able to resend it as V1
> and mark this V3 as 'superseded'.
>
> Hi Thomas,
> Please let us know if it i
On Mon, Jul 22, 2019 at 2:34 PM Ferruh Yigit wrote:
> I dropped this patch from next-net since discussion is going on, I did my best
> to resolve the conflicts but please confirm the final result in next-net.
>
I did some basic testing of the current head of dpdk-next-net and diffed
against the
A new DPDK release candidate is ready for testing:
https://git.dpdk.org/dpdk/tag/?id=v19.08-rc2
277 patches were integrated.
The release notes so far:
http://doc.dpdk.org/guides/rel_notes/release_19_08.html
It should be completed with a list of tested hardware.
Highlights of 19.08
Konstantin,
The recommended use of rte_eth_tx_prepare() had no effect, which after looking
at it, makes sense. We are using "large" mbufs to support Jumbo frames, so
nb-seg will always == 1. Additionally, we are not currently leveraging any HW
offload capabilities. As such, rte_eth_tx_prepare()
1 - 100 of 119 matches
Mail list logo
