Hello Patrick,
External email: Use caution opening links or attachments
Thank you for sharing Gregory. I did not get an opportunity to look through the
code today, but I did run
through the presentation. A few points I noted:
1. The presentation shows an example testpmd testcase for creating a
On 1/25/2024 4:07 PM, Sivaramakrishnan Venkat wrote:
> Missing "RTE_PTYPE_UNKNOWN" ptype causes buffer overflow.
> Enhance code such that the dev_supported_ptypes_get()
> function pointer now returns the number of elements to
> eliminate the need for "RTE_PTYPE_UNKNOWN" as the last item.
>
> Sign
Hi,
> -Original Message-
> From: Ferruh Yigit
> Sent: Wednesday, January 31, 2024 1:19 AM
> To: Suanming Mou ; Ori Kam ;
> Aman Singh ; Yuying Zhang
> ; Dariusz Sosnowski ; Slava
> Ovsiienko ; Matan Azrad ; NBU-
> Contact-Thomas Monjalon (EXTERNAL) ; Andrew
> Rybchenko
> Cc: dev@dpdk.org
Hi,
> -Original Message-
> From: Ferruh Yigit
> Sent: Wednesday, January 31, 2024 1:34 AM
> To: Suanming Mou ; Ori Kam ;
> Aman Singh ; Yuying Zhang
> ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; Andrew Rybchenko
>
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v3 2/3] ethdev: add compare item
On 1/30/2024 2:09 PM, Sivaramakrishnan Venkat wrote:
> Maintainers remove the Cc author line when merging the patch.
> So, the guidelines is updated with a suggestion for the placement
> of Cc lines in a commit message for easy merging.
>
> Signed-off-by: Sivaramakrishnan Venkat
> ---
> v2:
>
From: Long Li
Secondary processes are started after primary, and in most cases with
the device already started. Make them being able to process packets as
soon as they start.
This also works with the case where the primary process decides to start
the device at a later time after secondary proce
Remove use of statement expression syntax in expansion of
MOVEUNALIGNED_LEFT47_IMM and MOVEUNALIGNED_LEFT47 macro expansions.
There appears to be no need to use the statement expression compiler
extension a simple block should work.
Signed-off-by: Tyler Retzlaff
---
lib/eal/x86/include/rte_memc
Replace the use of RTE_MARKER with C11 anonymous unions to improve
code portability between toolchains.
Update use of rte_mbuf rearm_data field in net/ionic, net/sfc and
net/virtio which were accessing field as a zero-length array.
Signed-off-by: Tyler Retzlaff
---
drivers/net/ionic/ionic_lif.c
The zero sized RTE_MARKER typedefs are a GCC extension unsupported by
MSVC. Replace the use of the RTE_MARKER typedefs with anonymous unions.
both lib/mbuf and consuming drivers have been updated in the same commit
to avoid driver build break.
note:
since rte_mbuf is a public structure it might
On 1/29/2024 6:20 PM, Harman Kalra wrote:
> Hi Ferruh
>
> Thanks for the review
> Please find response inline
>
>
>> -Original Message-
>> From: Ferruh Yigit
>> Sent: Friday, January 26, 2024 7:13 PM
>> To: Harman Kalra ; dev@dpdk.org; Thomas Monjalon
>> ; Andrew Rybchenko
>> ; Ajit Kha
On 1/30/2024 4:43 PM, Stephen Hemminger wrote:
> On Tue, 30 Jan 2024 10:19:32 +
> Ferruh Yigit wrote:
>
>>> -mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq)
>>> +mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq, uint32_t count)
>>> {
>>> int ret;
>>> uint32_t i;
>>> + struct rte_
> Subject: Re: [Patch v2] net/mana: use rte_pktmbuf_alloc_bulk for allocating RX
> WQEs
>
> On 1/30/2024 9:30 PM, Long Li wrote:
> >> Can you please quantify the performance improvement (as percentage),
> >> this clarifies the impact of the modification.
> >
> > I didn't see any meaningful perform
On 1/30/2024 9:30 PM, Long Li wrote:
>> Can you please quantify the performance improvement (as percentage), this
>> clarifies the impact of the modification.
>
> I didn't see any meaningful performance improvements in benchmarks. However,
> this should improve CPU cycles and reduce potential loc
Thank you for sharing Gregory. I did not get an opportunity to look through
the code today, but I did run through the presentation. A few points I
noted:
1. The presentation shows an example testpmd testcase for creating a flow
rule, and then shows a validation step in which standard out is compar
> Can you please quantify the performance improvement (as percentage), this
> clarifies the impact of the modification.
I didn't see any meaningful performance improvements in benchmarks. However,
this should improve CPU cycles and reduce potential locking conflicts in
real-world applications.
On Tue, Jan 30, 2024 at 05:33:06PM +, Bruce Richardson wrote:
> On Tue, Jan 30, 2024 at 09:18:49AM -0800, Stephen Hemminger wrote:
> > While reworking tap device, one issue is how to keep (or drop) the support
> > of older Enterprise releases. The tap flow support is doing some workarounds
> >
On Tue, Jan 30, 2024 at 03:42:05PM +, bugzi...@dpdk.org wrote:
> https://bugs.dpdk.org/show_bug.cgi?id=1376
>
> Bug ID: 1376
>Summary: A BPF can no longer include header rte_mbuf_core.h
>Product: DPDK
>Version: 23.11
> Hardware: x86
>
Hello Ferruh,
Template table creation API sets table flows capacity.
If application needs more flows then the table was designed for,
the following procedures must be completed:
1. Create a new template table with larger flows capacity.
2. Re-create existing flows in the new table and delete flo
On Sat, Jan 27, 2024 at 09:34:24PM +0100, Mattias Rönnblom wrote:
> On 2024-01-26 22:35, Tyler Retzlaff wrote:
> >On Fri, Jan 26, 2024 at 11:52:11AM +0100, Morten Brørup wrote:
> >>>From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> >>>Sent: Friday, 26 January 2024 09.07
> >>>
> >>>On 2024-01-
On 2024-01-30 18:59, Bruce Richardson wrote:
On Tue, Jan 30, 2024 at 09:39:28AM -0800, Tyler Retzlaff wrote:
On Tue, Jan 30, 2024 at 09:08:21AM +0100, Mattias Rönnblom wrote:
Sorry if I've missed some discussion on the list, but the current
pattern of putting __rte_aligned(X) at the end does
This patch reworks the async flow API functions called in data path,
to reduce the overhead during flow operations at the library level.
Main source of the overhead was indirection and checks done while
ethdev library was fetching rte_flow_ops from a given driver.
This patch introduces rte_flow_fp
Hello Ferruh,
So, by design, driver will keep the old table when it is resized.
- Can this have a performance impact, like when rules
updated/removed/inserted driver will need to look more tables?
- Or can this cause additional capacity complexity, like total number of
rules will be sum of rules
On Tue, Jan 30, 2024 at 08:43:52AM -0800, Stephen Hemminger wrote:
> On Tue, 30 Jan 2024 10:19:32 +
> Ferruh Yigit wrote:
>
> > > -mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq)
> > > +mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq, uint32_t count)
> > > {
> > > int ret;
> > > uint3
On Tue, Jan 30, 2024 at 05:59:25PM +, Bruce Richardson wrote:
> On Tue, Jan 30, 2024 at 09:39:28AM -0800, Tyler Retzlaff wrote:
> > On Tue, Jan 30, 2024 at 09:08:21AM +0100, Mattias Rönnblom wrote:
>
> > >
> > > Sorry if I've missed some discussion on the list, but the current
> > > pattern o
On Tue, Jan 30, 2024 at 05:59:25PM +, Bruce Richardson wrote:
> On Tue, Jan 30, 2024 at 09:39:28AM -0800, Tyler Retzlaff wrote:
> > On Tue, Jan 30, 2024 at 09:08:21AM +0100, Mattias Rönnblom wrote:
>
> > >
> > > Sorry if I've missed some discussion on the list, but the current
> > > pattern o
On Tue, Jan 30, 2024 at 09:39:28AM -0800, Tyler Retzlaff wrote:
> On Tue, Jan 30, 2024 at 09:08:21AM +0100, Mattias Rönnblom wrote:
> >
> > Sorry if I've missed some discussion on the list, but the current
> > pattern of putting __rte_aligned(X) at the end doesn't work with MSVC,
> > or why are w
On Tue, Jan 30, 2024 at 09:09:20AM +0100, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> > Sent: Monday, 29 January 2024 20.44
> >
> > On Sun, Jan 28, 2024 at 11:00:31AM +0100, Mattias Rönnblom wrote:
> > > On 2024-01-28 09:57, Morten Brørup wrote:
> > > >>Fr
On Tue, 30 Jan 2024 17:33:06 +
Bruce Richardson wrote:
> On Tue, Jan 30, 2024 at 09:18:49AM -0800, Stephen Hemminger wrote:
> > While reworking tap device, one issue is how to keep (or drop) the support
> > of older Enterprise releases. The tap flow support is doing some workarounds
> > to in
On Tue, Jan 30, 2024 at 09:08:21AM +0100, Mattias Rönnblom wrote:
> On 2024-01-29 20:43, Tyler Retzlaff wrote:
> >On Sun, Jan 28, 2024 at 11:00:31AM +0100, Mattias Rönnblom wrote:
> >>On 2024-01-28 09:57, Morten Brørup wrote:
> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> Sent: S
On 1/15/2024 9:13 AM, Suanming Mou wrote:
> The new item type is added for the case user wants to match traffic
> based on packet field compare result with other fields or immediate
> value.
>
> e.g. take advantage the compare item user will be able to accumulate
> a IPv4/TCP packet's TCP data_off
On Tue, Jan 30, 2024 at 09:18:49AM -0800, Stephen Hemminger wrote:
> While reworking tap device, one issue is how to keep (or drop) the support
> of older Enterprise releases. The tap flow support is doing some workarounds
> to include missing support, but these are not the right way to do it.
>
>
On 1/15/2024 9:13 AM, Suanming Mou wrote:
> Current rte_flow_action_modify_data struct describes the pkt
> field perfectly and is used only in action.
>
> It is planned to be used for item as well. This commit renames
> it to "rte_flow_field_data" making it compatible to be used by item.
>
ack t
20/12/2023 10:11, Bruce Richardson:
> On Tue, Dec 19, 2023 at 12:17:37PM -0800, Tyler Retzlaff wrote:
> > rte_os.h includes sched.h so install sched.h to allow DPDK installed to
> > DESTDIR to be usable.
Why other files don't need to be exported as well?
> > Signed-off-by: Tyler Retzlaff
> > ---
On Tue, 30 Jan 2024 10:19:32 +
Ferruh Yigit wrote:
> > -mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq)
> > +mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq, uint32_t count)
> > {
> > int ret;
> > uint32_t i;
> > + struct rte_mbuf **mbufs;
> > +
> > + mbufs = rte_calloc_socket
07/12/2023 20:49, Tyler Retzlaff:
> Remove Windows maintainers who are no longer working on DPDK and add
> myself.
>
> Signed-off-by: Tyler Retzlaff
Applied, thanks.
> -Original Message-
> From: Juraj Linkeš
> Sent: Monday, January 29, 2024 2:15 PM
> To: Pavan Nikhilesh Bhagavatula
> Cc: Jerin Jacob ; ruifeng.w...@arm.com;
> n...@arm.com; Bruce Richardson ;
> dev@dpdk.org
> Subject: Re: [EXT] Re: [PATCH 1/2] config/arm: avoid mcpu and march
> confli
> -Original Message-
> From: Ferruh Yigit
> Sent: Tuesday, January 30, 2024 13:17
> To: Dariusz Sosnowski ; Stephen Hemminger
>
> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ;
> Andrew Rybchenko ; Ori Kam
> ; dev@dpdk.org
> Subject: Re: [RFC] ethdev: fast path async flow API
>
> On 1/30/
https://bugs.dpdk.org/show_bug.cgi?id=1376
Bug ID: 1376
Summary: A BPF can no longer include header rte_mbuf_core.h
Product: DPDK
Version: 23.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: major
On 12/17/2023 9:32 AM, Gregory Etelson wrote:
> Template table creation API sets table flows capacity.
> If application needs more flows then the table was designed for,
> the following procedures must be completed:
> 1. Create a new template table with larger flows capacity.
> 2. Re-create existin
On 1/30/2024 12:46 PM, Etelson, Gregory wrote:
> Hello Ferruh,
>
>>
>> If a multi-threaded application can add new and updated old
>> simultaneously, this should be done via monolithic API, like:
>> {
>> lock
>> resize
>> unlock
>> for each flow
>> lock
>> update
>> unlock
>> }
>>
>
SW PMDs increment IPsec Multi-buffer version to 1.4.
A minimum IPsec Multi-buffer version of 1.4 or greater is now required.
Signed-off-by: Sivaramakrishnan Venkat
Acked-by: Ciara Power
---
v2:
- Removed unused macro in ipsec_mb_ops.c
- set_gcm_job() modified correctly to keep multi_
Maintainers remove the Cc author line when merging the patch.
So, the guidelines is updated with a suggestion for the placement
of Cc lines in a commit message for easy merging.
Signed-off-by: Sivaramakrishnan Venkat
---
v2:
- Samples updated to the desired format for the "Cc:" line in the com
> From: Morten Brørup [mailto:m...@smartsharesystems.com]
> Sent: Tuesday, 30 January 2024 11.17
>
> > From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> > Sent: Tuesday, 30 January 2024 10.28
> >
> > On 2024-01-30 09:09, Morten Brørup wrote:
> > >> From: Tyler Retzlaff [mailto:roret...@linux
Hello Ferruh,
If a multi-threaded application can add new and updated old
simultaneously, this should be done via monolithic API, like:
{
lock
resize
unlock
for each flow
lock
update
unlock
}
The flow template API was designed for performance.
Application that implements the f
On 30/01/2024 12:07, Ferruh Yigit wrote:
> On 1/24/2024 9:25 AM, Chaoyong He wrote:
>> From: Long Wu
>>
>> Stop cpp service if all representors are closed and cpp service is running.
>>
>> Fixes: bab0e6f48b6d ("net/nfp: fix infinite loop")
>> Cc: chaoyong...@corigine.com
>> Cc: sta...@dpdk.org
>>
On 1/30/2024 12:06 PM, Dariusz Sosnowski wrote:
> Hi Ferruh,
>
>> -Original Message-
>> From: Ferruh Yigit
>> Sent: Monday, January 29, 2024 18:36
>> To: Dariusz Sosnowski ; Stephen Hemminger
>>
>> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ;
>> Andrew Rybchenko ; Ori Kam
>> ; dev@dpdk.o
On 1/24/2024 9:25 AM, Chaoyong He wrote:
> From: Long Wu
>
> Stop cpp service if all representors are closed and cpp service is running.
>
> Fixes: bab0e6f48b6d ("net/nfp: fix infinite loop")
> Cc: chaoyong...@corigine.com
> Cc: sta...@dpdk.org
>
This fix is using a new function that is introd
Hi Ferruh,
> -Original Message-
> From: Ferruh Yigit
> Sent: Monday, January 29, 2024 18:36
> To: Dariusz Sosnowski ; Stephen Hemminger
>
> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ;
> Andrew Rybchenko ; Ori Kam
> ; dev@dpdk.org
> Subject: Re: [RFC] ethdev: fast path async flow API
>
Currently, DPDK supports VXLAN and VXLAN-GPE with similar header
structures and we are working on adding support for VXLAN-GBP which is
another extension to VXLAN. More extension of VXLAN may be added in the
future.
VXLAN and VXLAN-GBP use the same UDP port(4789) while VXLAN-GPE uses a
different o
This patch is to extend standard VXLAN header to support more extensions
Gavin Li (1):
net: extend VXLAN header to support more extensions
---
changelog:
v0->v1
- Addressed bit fields definition bug in union
---
doc/guides/rel_notes/deprecation.rst | 5 +++
lib/ethdev/rte_flow.h
On 1/30/2024 1:13 AM, lon...@linuxonhyperv.com wrote:
> From: Long Li
>
> Instead of allocating mbufs one by one during RX, use rte_pktmbuf_alloc_bulk()
> to allocate them in a batch.
>
> Signed-off-by: Long Li
>
Can you please quantify the performance improvement (as percentage),
this clarifi
> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> Sent: Tuesday, 30 January 2024 10.28
>
> On 2024-01-30 09:09, Morten Brørup wrote:
> >> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> >> Sent: Monday, 29 January 2024 20.44
> >>
> >> On Sun, Jan 28, 2024 at 11:00:31AM +0100,
When vf issues a reset to pf there is a 50 msec wait plus an additional
max of 1 msec for the pf to indicate the reset is complete before
timeout.
In some cases, it is seen that the reset is timing out, in which case
the reset does not complete and an error is returned.
In order to account for th
Currently, DPDK supports VXLAN and VXLAN-GPE with similar header
structures and we are working on adding support for VXLAN-GBP which is
another extension to VXLAN. More extension of VXLAN may be added in the
future.
VXLAN and VXLAN-GBP use the same UDP port(4789) while VXLAN-GPE uses a
different o
On 2024-01-30 09:09, Morten Brørup wrote:
From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
Sent: Monday, 29 January 2024 20.44
On Sun, Jan 28, 2024 at 11:00:31AM +0100, Mattias Rönnblom wrote:
On 2024-01-28 09:57, Morten Brørup wrote:
From: Mattias Rönnblom [mailto:hof...@lysator.liu
On 1/29/2024 3:08 PM, Etelson, Gregory wrote:
> Hello Ferruh,
>
>>
>> Hi Gregory, Ori,
>>
>> Why we need three separate APIs,
>> rte_flow_template_table_resize
>> rte_flow_async_update_resized
>> rte_flow_template_table_resize_complete
>>
>> Why not 'rte_flow_template_table_resize()' update existi
> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Monday, 29 January 2024 20.44
>
> On Sun, Jan 28, 2024 at 11:00:31AM +0100, Mattias Rönnblom wrote:
> > On 2024-01-28 09:57, Morten Brørup wrote:
> > >>From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> > >>Sent: Saturday, 2
On 2024-01-29 20:43, Tyler Retzlaff wrote:
On Sun, Jan 28, 2024 at 11:00:31AM +0100, Mattias Rönnblom wrote:
On 2024-01-28 09:57, Morten Brørup wrote:
From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
Sent: Saturday, 27 January 2024 20.15
On 2024-01-26 11:18, Morten Brørup wrote:
From: Ma
58 matches
Mail list logo
