Change rule type to be uintptr_t (instead of currently uint32_t) to be
able to accomodate larger IDs, as a pre-step towards allowing user-id
to flows.
Signed-off-by: Eli Britstein
---
app/test-pmd/cmdline_flow.c | 12 ++--
app/test-pmd/config.c | 34
destroy 0 rule 0x1234 user_id
Flow rule #0 destroyed, user-id 0x1234
Signed-off-by: Eli Britstein
---
app/test-pmd/cmdline_flow.c | 72 +++--
app/test-pmd/config.c | 34 +++---
app/test-pmd/testpmd.h | 12 +
>-Original Message-
>From: Ilya Maximets
>Sent: Friday, October 14, 2022 3:37 PM
>To: fengchengwen ; dev@dpdk.org; Ori Kam
>; NBU-Contact-Thomas Monjalon (EXTERNAL)
>; Eli Britstein
>Cc: i.maxim...@ovn.org; Ajit Khaparde ;
>Somnath Kotur ; Rahul Lakkireddy
>
Hi Aman,
No, the group attribute has its own meaning, so it cannot be used for this
purpose, unless I misunderstood your meaning.
Thanks,
Eli
>-Original Message-
>From: Singh, Aman Deep
>Sent: Thursday, July 28, 2022 5:07 PM
>To: dev@dpdk.org; Eli Britstein
>Cc: Slava
Upon creation of a flow, testpmd assigns it a flow ID. Later, the flow
ID is used for flow operations (query, destroy, dump).
The testpmd application allows to manage flow rules with its IDs.
The flow ID is known only when the flow is created.
In order to prepare a complete sequence of testpmd com
ing an array cell of index
. This array is mistakenly [MAX_PKT_BURST] size. Receiving
the maximum burst will cause out of bound write.
Enlarge the spread stats array by one cell to fix it.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Eli Britstein
Revi
On 10/21/2021 6:48 PM, Stephen Hemminger wrote:
External email: Use caution opening links or attachments
On Thu, 21 Oct 2021 11:51:30 +0300
Eli Britstein wrote:
In rte_vlan_insert there is a casting of rte_pktmbuf_prepend returned
value to (struct rte_ether_hdr *), which causes cast-align
af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Eli Britstein
Acked-by: Olivier Matz
---
lib/mbuf/rte_mbuf_core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
index fdaaaf67f2..dd08d42
ignment, add first a (void *) or (const
void *) castings, to avoid the warnings.
Fixes: 9484092baad3 ("eal/x86: optimize memcpy for AVX512 platforms")
Cc: sta...@dpdk.org
Signed-off-by: Eli Britstein
---
lib/eal/x86/include/rte_memcpy.h | 80 ++--
1 file
he warning.
Fixes: c974021a5949 ("ether: add soft vlan encap/decap")
Cc: sta...@dpdk.org
Signed-off-by: Eli Britstein
Acked-by: Olivier Matz
---
lib/net/rte_ether.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/net/rte_ether.h b/lib/net/rte_ether.h
index b83e0d3fc
75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Eli Britstein
Reviewed-by: Matan Azrad
---
app/test-pmd/testpmd.c | 2 +-
app/test-pmd/testpmd.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpm
Hi Olivier,
On 8/1/2021 11:06 AM, Eli Britstein wrote:
On 7/30/2021 2:10 PM, Olivier Matz wrote:
External email: Use caution opening links or attachments
Hi Eli,
On Thu, Jul 29, 2021 at 10:13:45AM +0300, Eli Britstein wrote:
On 7/28/2021 6:28 PM, Olivier Matz wrote:
External email: Use
nvgre
testpmd> flow tunnel create 0 type gre
port 0: flow tunnel #3 type gre
testpmd> flow tunnel create 0 type geneve
port 0: flow tunnel #4 type geneve
Fixes: 1b9f274623b8 ("app/testpmd: add commands for tunnel offload")
Cc: sta...@dpdk.org
Signed-off-by: Eli Britstein
---
app/
Accept RTE_FLOW_ITEM_TYPE_GRE, RTE_FLOW_ITEM_TYPE_NVGRE and
RTE_FLOW_ITEM_TYPE_GENEVE as valid tunnel types.
Fixes: 4ec6360de37d ("net/mlx5: implement tunnel offload")
Cc: sta...@dpdk.org
Signed-off-by: Eli Britstein
---
drivers/net/mlx5/mlx5_flow.c | 3 +++
1 file changed, 3
Current testpmd implementation supports VXLAN only for tunnel offload.
Add GRE, NVGRE and GENEVE for tunnel offload flow matches.
Signed-off-by: Eli Britstein
---
app/test-pmd/config.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/app/test-pmd/config.c b/app/test-pmd
Accept RTE_FLOW_ITEM_TYPE_GRE, RTE_FLOW_ITEM_TYPE_NVGRE and
RTE_FLOW_ITEM_TYPE_GENEVE as valid tunnel types.
Signed-off-by: Eli Britstein
---
drivers/net/mlx5/mlx5_flow.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index
On 8/24/2021 6:47 PM, Ilya Maximets wrote:
External email: Use caution opening links or attachments
On 8/24/21 5:25 PM, Eli Britstein wrote:
On 8/24/2021 6:08 PM, Finn, Emma wrote:
External email: Use caution opening links or attachments
-Original Message-
From: Eli Britstein
On 8/1/2021 1:22 PM, Andrew Rybchenko wrote:
External email: Use caution opening links or attachments
By its very name, action PORT_ID means that packets hit an ethdev with the
given DPDK port ID. At least the current comments don't state the opposite.
That said, since port representors had b
On 7/30/2021 2:10 PM, Olivier Matz wrote:
External email: Use caution opening links or attachments
Hi Eli,
On Thu, Jul 29, 2021 at 10:13:45AM +0300, Eli Britstein wrote:
On 7/28/2021 6:28 PM, Olivier Matz wrote:
External email: Use caution opening links or attachments
On Tue, Jul 13
On 7/28/2021 6:28 PM, Olivier Matz wrote:
External email: Use caution opening links or attachments
On Tue, Jul 13, 2021 at 09:49:09AM +0300, Eli Britstein wrote:
In rte_pktmbuf_mtod_offset macro, there is a casting from char * to type
't', which may cause cast-align warning when
st __m128i *)(const __m128i *)src);
| ^
As the code assumes correct alignment, add first a (void *) or (const
void *) castings, to avoid the warnings.
Fixes: 9484092baad3 ("eal/x86: optimize memcpy for AVX512 platforms")
Cc: sta...@dpdk.org
723 | ((t)((char *)(m)->buf_addr + (m)->data_off + (o)))
| ^
As the code assumes correct alignment, add first a (void *) casting, to
avoid the warning.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Eli Britstein
---
lib/mbuf/rte_m
to
avoid the warning.
Fixes: c974021a5949 ("ether: add soft vlan encap/decap")
Cc: sta...@dpdk.org
Signed-off-by: Eli Britstein
---
lib/net/rte_ether.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/net/rte_ether.h b/lib/net/rte_ether.h
index 7ee5e9a292..6
. I do not have a system in which I
encounter such warnings, so currently I do not post any change for it.
Eli Britstein (3):
net: avoid cast-align warning in VLAN insert function
mbuf: avoid cast-align warning in pktmbuf mtod offset macro
eal/x86: avoid cast-align warning in x86 memcpy
On 6/2/2021 1:50 PM, Andrew Rybchenko wrote:
External email: Use caution opening links or attachments
On 6/2/21 12:57 PM, Eli Britstein wrote:
On 6/1/2021 5:53 PM, Andrew Rybchenko wrote:
External email: Use caution opening links or attachments
On 6/1/21 5:44 PM, Eli Britstein wrote:
On
On 6/1/2021 5:53 PM, Andrew Rybchenko wrote:
External email: Use caution opening links or attachments
On 6/1/21 5:44 PM, Eli Britstein wrote:
On 6/1/2021 5:35 PM, Andrew Rybchenko wrote:
External email: Use caution opening links or attachments
On 6/1/21 4:24 PM, Eli Britstein wrote:
On
On 6/1/2021 5:35 PM, Andrew Rybchenko wrote:
External email: Use caution opening links or attachments
On 6/1/21 4:24 PM, Eli Britstein wrote:
On 6/1/2021 3:10 PM, Ilya Maximets wrote:
External email: Use caution opening links or attachments
On 6/1/21 1:14 PM, Ivan Malov wrote:
By its
On 6/1/2021 3:10 PM, Ilya Maximets wrote:
External email: Use caution opening links or attachments
On 6/1/21 1:14 PM, Ivan Malov wrote:
By its very name, action PORT_ID means that packets hit an ethdev with the
given DPDK port ID. At least the current comments don't state the opposite.
That
I used "rawio".
I think "raw IO" misses that meaning. What do you think?
01/04/2021 09:49, Eli Britstein:
For an application to be able to create "transfer" rte_flows for mlx5
What is "tranfer" rule?
https://doc.dpdk.org/guides/prog_guide/rte_fl
For an application to be able to create "transfer" rte_flows for mlx5
devices, it should have cap_sys_rawio capability.
Document it.
Fixes: f772cc424c45 ("doc: add required Linux capabilities in mlx5 guide")
Cc: sta...@dpdk.org
Signed-off-by: Eli Britstein
Reviewed-by: Ga
On 3/3/2021 4:03 PM, Ivan Malov wrote:
Hi,
Could someone please also clarify the meaning (from PMD standpoint and
from application's standpoint) of the 64-bit field "tun_id" in
"rte_flow_tunnel"? The current comment reads: "Tunnel identification",
which is quite ambiguous, not to mention th
ingress pattern eth / ipv6 has_frag_ext is 0 / end actions
drop / end
Fix the validation only on proto asked by the user.
Fixes: 92be60e1b541 ("net/mlx5: enforce limitation on IPv6 next proto")
Signed-off-by: Eli Britstein
Acked-by: Dekel Peled
Acked-by: Matan Azrad
---
driver
++
On 10/20/2020 4:19 PM, Eli Britstein wrote:
Previous patch added validation of the IPv6 next proto field, in order
to overcome a known limitation.
One of the values checked is IPPROTO_HOPOPTS, which is defined as 0.
If proto field is not specified for matching, or mask=0, as in the
following
ingress pattern eth / ipv6 has_frag_ext is 0 / end actions
drop / end
Fix the validation only on proto asked by the user.
Fixes: 55e4c1d1ba73 ("net/mlx5: enforce limitation on IPv6 next proto")
Signed-off-by: Eli Britstein
Acked-by: Dekel Peled
---
drivers/net/mlx5/mlx5_flow.c | 2
if the compiler does provide stdatomic.h header,
passing -Wsystem-headers in the CFLAGS will also cause that failure.
Fix it by changing the argument name 'memory_order' to 'memorder'.
Fixes: 672a15056380 ("eal: add wrapper for C11 atomic thread fence")
Signed-off-b
omic.h), will
fail compilation with:
error: declaration of 'memory_order' shadows a global declaration
[-Werror=shadow]
rte_atomic_thread_fence(int memory_order)
Fix it by changing the argument name 'memory_order' to 'memorder'.
Fixes: 672a15056380 ("
On 8/4/2020 6:36 PM, Dekel Peled wrote:
In existing code the match on tagged/untagged packets is not explicit.
Recent documentation update [1] describes the different patterns and
clarifies the intended use of different patterns.
This patch proposes an update to ETH item struct, to clearly def
Introduce a heler function to set the ip_version match.
Signed-off-by: Eli Britstein
Acked-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_flow_dv.c | 38 --
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b
The HW is optimized for IPv4/IPv6. For such cases avoid matching on
ethertype, and use ip_version field instead.
Signed-off-by: Eli Britstein
Acked-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_flow_dv.c | 53 +++--
1 file changed, 41 insertions(+), 12
The HW is optimized for IPv4/IPv6. For such cases avoid matching on
ethertype, and use ip_version field instead.
Eli Britstein (2):
net/mlx5: introduce a helper to set IP version match
net/mlx5: optimize performance for IPv4/IPv6 ethertype
drivers/net/mlx5/mlx5_flow_dv.c | 91
Introduce a heler function to set the ip_version match.
Signed-off-by: Eli Britstein
Acked-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_flow_dv.c | 38 --
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b
The HW is optimized for IPv4/IPv6. For such cases avoid matching on
ethertype, and use ip_version field instead.
Signed-off-by: Eli Britstein
Acked-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_flow_dv.c | 51 +++--
1 file changed, 39 insertions(+), 12
The HW is optimized for IPv4/IPv6. For such cases avoid matching on
ethertype, and use ip_version field instead.
Eli Britstein (2):
net/mlx5: introduce a helper to set IP version match
net/mlx5: optimize performance for IPv4/IPv6 ethertype
drivers/net/mlx5/mlx5_flow_dv.c | 89
Acked-by: Eli Britstein
On 8/5/2019 2:51 PM, Dekel Peled wrote:
> Function flow_dv_zero_encap_udp_csum() uses a while loop to iterate
> over vlan items in flow rule.
> Pointer next_hdr is incremented to the next item before it is used,
> so the first item is skipped.
>
> Th
Hi
In your PMD, you should mark your init function as constructor, in which you
should register your PMD as a DPDK driver.
You can look at Intel's "memnic" example (though not maintained, and not being
compiled with recent versions, you can take it as a reference).
The function I mean from it:
Integrating Tetsuya's last comments on top of the latest message and reply.
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Eli Britstein
> Sent: Tuesday, 19 July, 2016 5:34 PM
> To: Declan Doherty; Tetsuya Mukawa; dev at dpdk.org
> Cc
> -Original Message-
> From: Declan Doherty [mailto:declan.doherty at intel.com]
> Sent: Tuesday, 19 July, 2016 5:15 PM
> To: Eli Britstein; Tetsuya Mukawa; dev at dpdk.org
> Cc: Iremonger, Bernard
> Subject: Re: [dpdk-dev] SRIOV hot unplug
>
> On 07/19/2016 12:18
> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Tuesday, 19 July, 2016 5:49 AM
> To: Eli Britstein; dev at dpdk.org
> Cc: Iremonger, Bernard
> Subject: Re: [dpdk-dev] SRIOV hot unplug
>
> Hi Eli,
>
> On 2016/07/18 17:4
side, which I would like to
avoid.
Do you think might there be any other way for the application to handle such
event in a smooth way?
Thanks,
Eli
> -Original Message-
> From: Iremonger, Bernard [mailto:bernard.iremonger at intel.com]
> Sent: Sunday, 17 July, 2016 11:53 PM
>
Hello,
A DPDK application with a DPDK bond device, with 2 slaves: one vnic, and
another is a SRIOV VF connected as a pathrough.
The bond device is configured as ACTIVE/BACKUP, and the primary is the VF slave.
Now, I do "virsh detach-device" from the host, and the DPDK process in the VM
gets segm
Hello,
In librte_eal, in eal_ivshmem.c, in function map_all_segments, there is mapping
of segments from the metadata to the same virtual address as written in the
metadata.
Is there a method to guarantee that this mapping won't fail, even for different
processes, that might have large code o
51 matches
Mail list logo
