> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Wednesday, 25 September 2019 16.56
>
> Add support for a new build option to turn off certain drivers. Any
> other
> drivers which depend on the one being disabled will also be disabled
> with a
> suitable debug message.
>
> Sig
reported by code analysis tool C++test (version 10.4):
> /build/dpdk-20.11/drivers/bus/ifpga/ifpga_bus.c
> 67Condition "afu_dev" is always evaluated to true
> 81Condition "afu_dev" is always evaluated to true
The "for" loop already checks that afu_dev is not NULL.
Fixes: 05fa3d4a6539 ("b
reported by code analysis tool C++test (version 10.4):
> /build/dpdk-20.11/drivers/net/nfp/nfp_net.c
> 546 Conditions "(hw->ctrl &NFP_NET_CFG_CTRL_ENABLE) &&
!! (hw->cap &NFP_NET_CFG_C" is always evaluated to false
> 547 Condition "! (hw->cap &NFP_NET_CFG_C" is always evaluated to fals
reported by code analysis tool C++test (version 10.4):
> /build/dpdk-20.11/drivers/net/nfp/nfpcore/nfp_target.h
> 375 Condition "island < 1" is always evaluated to false
> 415 Condition "island < 1" is always evaluated to false
> 547 Condition "target < 0" is always evaluated to false
All o
Hi Stephen,
Thanks for getting back. But I am looking at storing logs with timestamps in a
file, basically something similar to syslog. Could you help me with that ?
Regards,
Soumya
On 1/5/22, 8:17 AM, "Stephen Hemminger" wrote:
WARNING: This email originated from outside of Gigamon. Use
Hi,
> -Original Message-
> From: Michael Baum
> Sent: Thursday, November 25, 2021 12:03 AM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Slava Ovsiienko ; Michael
> Baum ; sta...@dpdk.org
> Subject: [PATCH] common/mlx5: fix error handling in multi-class probe
>
> From: Mich
Hi,
> -Original Message-
> From: Michael Baum
> Sent: Wednesday, December 8, 2021 4:52 PM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Slava Ovsiienko ; Michael
> Baum ; sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix the memory socket selection in ASO
> management
>
> Fr
Hi,
> -Original Message-
> From: Michael Baum
> Sent: Thursday, December 16, 2021 8:41 PM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Slava Ovsiienko ; Michael
> Baum ; sta...@dpdk.org
> Subject: [PATCH] common/mlx5: fix missing validation in devargs parsing
>
> From: Mic
Hi Olivier,
The data_room_size parameter description for the mbuf pool creation functions
says:
"Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM."
Furthermore, both rte_mbuf_data_iova_default() and rte_mbuf_data_addr_default()
simply add RTE_PKTMBUF_HEADROOM to the return value
On Wed, Jan 5, 2022 at 7:30 PM Tomasz Duszynski wrote:
>
> This series introduces a new rawdevice PMD which allows
> to manage userspace GPIOs and install custom GPIO interrupt
> handlers which bypass kernel. This is especially useful for
> applications that, besides providing standard dataplane f
06/01/2022 09:23, Morten Brørup:
> > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > Sent: Wednesday, 25 September 2019 16.56
> >
> > Add support for a new build option to turn off certain drivers. Any
> > other
> > drivers which depend on the one being disabled will also be disable
Hi Morten,
On Thu, Jan 06, 2022 at 10:29:11AM +0100, Morten Brørup wrote:
> Hi Olivier,
>
> The data_room_size parameter description for the mbuf pool creation functions
> says:
> "Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM."
>
> Furthermore, both rte_mbuf_data_iova_defaul
On Mon, Jan 3, 2022 at 4:08 PM Akhil Goyal wrote:
>
> As discussed in the RFC[1] sent in 21.11, a new offload is
> introduced in ethdev for IP reassembly.
>
> This patchset add the RX offload and an application to test it.
> Currently, the offload is tested along with inline IPsec processing.
> It
> > Akhil Goyal (8):
> > ethdev: introduce IP reassembly offload
> > ethdev: add dev op for IP reassembly configuration
> > ethdev: add mbuf dynfield for incomplete IP reassembly
> > security: add IPsec option for IP reassembly
> > app/test: add unit cases for inline IPsec offload
> > a
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Thursday, 6 January 2022 10.49
>
> 06/01/2022 09:23, Morten Brørup:
> > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > Sent: Wednesday, 25 September 2019 16.56
> > >
> > > Add support for a new build option to turn of
Hi Andrzej,
On Mon, Jan 03, 2022 at 03:22:01PM +0100, Andrzej Ostruszka wrote:
> ring: fix off by 1 mistake
I suggest something less scary for the title:
ring: optimize corner case for enqueue/dequeue
> When enqueueing/dequeueing to/from the ring we try to optimize by manual
> loop unrolling.
> From: Olivier Matz [mailto:olivier.m...@6wind.com]
> Sent: Thursday, 6 January 2022 10.49
Thank you for the thorough explanation, Olivier.
Somewhat exotic scenarios, but they do make sense!
As you might have guessed, I was wondering if rte_pktmbuf_reset_headroom()
could be optimized by simply
A flush threshold for the mempool cache was introduced in DPDK version
1.3, but rte_mempool_do_generic_get() was not completely updated back
then.
The incompleteness did not cause any functional bugs, so this patch
could be considered refactoring for the purpose of cleaning up.
This patch complet
On Tue, Nov 30, 2021 at 11:11 AM Ashwin Sekhar T K wrote:
>
> When PLT_CACHE_LINE_SIZE is set to 64B, the memzone size reserved for
> NPA stack could be a multiple of 64B. In such a case, when NDC SYNC
> is initiated for the NPA LF, it could go and corrupt an additional
> 64B bytes as NDC flushes
On Tue, Nov 30, 2021 at 11:17 AM Ashwin Sekhar T K wrote:
>
> Before issuing the batch alloc, we clear the first word of
> cache lines so that NPA can update the status. Make sure that
> this line clear is flushed before the batch alloc is issued.
>
> Signed-off-by: Ashwin Sekhar T K
Changed cas
On Thu, Jan 06, 2022 at 11:50:54AM +0100, Morten Brørup wrote:
> > From: Olivier Matz [mailto:olivier.m...@6wind.com]
> > Sent: Thursday, 6 January 2022 10.49
>
> Thank you for the thorough explanation, Olivier.
>
> Somewhat exotic scenarios, but they do make sense!
>
> As you might have guessed
> From: Olivier Matz [mailto:olivier.m...@6wind.com]
> Sent: Thursday, 6 January 2022 13.41
>
> On Thu, Jan 06, 2022 at 11:50:54AM +0100, Morten Brørup wrote:
> > > From: Olivier Matz [mailto:olivier.m...@6wind.com]
> > > Sent: Thursday, 6 January 2022 10.49
> >
> > Thank you for the thorough expl
On 1/4/2022 9:10 PM, Li, Xiaoyun wrote:
Hi
-Original Message-
From: Li, Xiaoyun
Sent: Tuesday, January 4, 2022 15:19
To: Singh, Aman Deep; Yigit, Ferruh
;olivier.m...@6wind.com;
m...@smartsharesystems.com; Ananyev, Konstantin
;step...@networkplumber.org;
Medvedkin, Vladimir
Cc:dev@dpdk
On Tue, Nov 30, 2021 at 11:20 AM Ashwin Sekhar T K wrote:
>
> Update the CPU directive in ROC NPA assembly code snippets.
>
> Signed-off-by: Ashwin Sekhar T K
Update the git commit as
common/cnxk: update CPU directive in NPA assembly code
Use arch_extension instead of .cpu directive i
Added functions to calculate UDP/TCP checksum for packets which may be
over multi-segments and fix the checksum issue with testpmd csum
forwarding mode.
Xiaoyun Li (2):
net: add functions to calculate UDP/TCP cksum in mbuf
testpmd: fix l4 sw csum over multi segments
---
v5:
* Fixed commit lo
Add functions to call rte_raw_cksum_mbuf() to calculate IPv4/6
UDP/TCP checksum in mbuf which can be over multi-segments.
Signed-off-by: Xiaoyun Li
Acked-by: Aman Singh
Tested-by: Sunil Pai G
---
doc/guides/rel_notes/release_22_03.rst | 11 ++
lib/net/rte_ip.h | 186
In csum forwarding mode, software UDP/TCP csum calculation only takes
the first segment into account while using the whole packet length so
the calculation will read invalid memory region with multi-segments
packets and will get wrong value.
This patch fixes this issue.
Signed-off-by: Xiaoyun Li
29/11/2021 17:08, Josh Soref:
> -* external phy devices registred through kerenl apis
> +* external phy devices registred through kernel apis
another spelling to fix:
"registred"
and while at it, "apis" should be "APIs"
- * When set to zero, simple forwaring path is eanbl
29/11/2021 17:08, Josh Soref:
> -* dequeueing once we've filled up the queue, we have to benchmark it
> +* dequeuing once we've filled up the queue, we have to benchmark it
I think "dequeueing" is correct.
On Thu, Jan 6, 2022 at 5:54 PM Morten Brørup wrote:
>
> A flush threshold for the mempool cache was introduced in DPDK version
> 1.3, but rte_mempool_do_generic_get() was not completely updated back
> then.
>
> The incompleteness did not cause any functional bugs, so this patch
> could be consider
30 matches
Mail list logo
