gned int rather than a bit field. We also
now use the atomic built-ins to read/write the value of the remove flag
to ensure thread-safety.
Fixes: 598fb8aec6f6 ("net/failsafe: support device removal")
Cc: Gaetan Rivet
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
drivers/net/failsa
lsafe
device.
Fixes: ae80146c5a1b ("net/failsafe: fix removed device handling")
Cc: Matan Azrad
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
drivers/net/failsafe/failsafe_ops.c | 37 +
1 file changed, 17 insertions(+), 20 deletions(-)
diff --git a/drive
ng
done in rte_eth_dev_release_port).
Fixes: fac0ae546e5f ("net/failsafe: free port by dedicated function")
Cc: Matan Azrad
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
drivers/net/failsafe/failsafe_ether.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/fails
-by: Luc Pelletier
---
drivers/net/failsafe/failsafe_rxtx.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/failsafe/failsafe_rxtx.c
b/drivers/net/failsafe/failsafe_rxtx.c
index 707fe60a36..6d8ab0a6e7 100644
--- a/drivers/net/failsafe/failsafe_rxtx.c
+++ b
rmance.
Fixes: 7a0935239b9e ("ethdev: make fast-path functions to use new flat array")
Cc: Konstantin Ananyev
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
drivers/net/failsafe/failsafe_ether.c | 2 -
drivers/net/failsafe/failsafe_private.h | 8 ---
drivers/net/failsafe
v2:
* fixed git commit hashes in commit message
v3:
* address comments / split into several commits
v4:
* fix checkpatch warnings
Luc Pelletier (5):
failsafe: fix segfault on hotplug event
failsafe: use public rx/tx burst API
failsafe: fix double release of port
failsafe: use public APIs
gned int rather than a bit field. We also
now use the atomic built-ins to read/write the value of the remove flag
to ensure thread-safety.
Fixes: 598fb8aec6f6 ("net/failsafe: support device removal")
Cc: Gaetan Rivet
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
drivers/net/failsa
lsafe
device.
Fixes: ae80146c5a1b ("net/failsafe: fix removed device handling")
Cc: Matan Azrad
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
drivers/net/failsafe/failsafe_ops.c | 38 ++---
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drive
-by: Luc Pelletier
---
drivers/net/failsafe/failsafe_rxtx.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/failsafe/failsafe_rxtx.c
b/drivers/net/failsafe/failsafe_rxtx.c
index 707fe60a36..6d8ab0a6e7 100644
--- a/drivers/net/failsafe/failsafe_rxtx.c
+++ b
ng
done in rte_eth_dev_release_port).
Fixes: fac0ae546e5f ("net/failsafe: free port by dedicated function")
Cc: Matan Azrad
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
drivers/net/failsafe/failsafe_ether.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/fails
rmance.
Fixes: 7a0935239b9e ("ethdev: make fast-path functions to use new flat array")
Cc: Konstantin Ananyev
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
drivers/net/failsafe/failsafe_ether.c | 2 -
drivers/net/failsafe/failsafe_private.h | 8 ---
drivers/net/failsafe
Following the comments on v1 and v2 of the patch, I've tried to
address all issues that were mentioned. I've also fixed other issues
discovered during testing. I've split the changes into several
commits. Please note that only the bug fix commits have been marked
for back-porting
Hi Konstantin,
> It is not recommended way to update rte_eth_fp_ops[] contents directly.
> There are eth_dev_fp_ops_setup()/ eth_dev_fp_ops_reset() that supposed
> to be used for that.
Good to know. I see another fix that was made in a different PMD that
does exactly the same thing:
https://gith
ns
should have been used.
To fix the problem, the failsafe PMD code was changed to update the
function pointers in the rte_eth_fp_ops array when a hotplug event
occurs.
Fixes: 7a0935239b9e ("ethdev: make fast-path functions to use new flat array")
Cc: Konstantin Ananyev
Cc: sta...@dpdk.or
have been used.
To fix the problem, the failsafe PMD code was changed to update the
function pointers in the rte_eth_fp_ops array when a hotplug event
occurs.
Fixes: 7a0935239b ("ethdev: make fast-path functions to use new flat array")
Cc: Konstantin Ananyev
Cc: sta...@dpdk.
Hi David,
> > Actually, looking again at the history, it fixes:
> > Fixes: f5472703c0bd ("eal: optimize aligned memcpy on x86")
>
> Nop, that's probably even older, could you double check?
> I'll hold on pushing this fix.
It seems you still haven't received a response. I'll take a stab at this.
Hi David,
Le jeu. 7 avr. 2022 à 11:24, David Marchand
a écrit :
> > As a side note, we probably need to check other similar places in DPDK code.
>
> What would be the best way to detect those problematic places?
As far as I'm aware, there is no silver bullet to detect all strict
aliasing violat
/store
operations. This results in code that has the same performance as the
original code and that is also C standards-compliant.
Fixes: d35cc1fe6a7a ("eal/x86: revert select optimized memcpy at run-time")
Cc: Xiaoyun Li
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
v7:
* Fix co
Hi,
This patch can be abandoned. As indicated in another thread
(http://mails.dpdk.org/archives/dev/2022-February/234889.html), there
is no requirement/desire to make this change.
Thanks.
Le sam. 15 janv. 2022 à 14:39, Luc Pelletier a écrit :
>
> Calls to rte_memcpy_aligned could res
/store
operations. This results in code that has the same performance as the
original code and that is also C standard-compliant.
Fixes: d35cc1fe6a7a ("eal/x86: revert select optimized memcpy at run-time")
Cc: Xiaoyun Li
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
v6:
* Refoc
Hi Konstantin,
> Indeed it looks like a problem.
> Thanks for pointing it out.
> Was able to reproduce it with gcc 11 (clang 13 seems fine).
> Actually, adding ' __attribute__ ((__may_alias__))' for both dst and src
> didn't quire the problem.
__may_alias__ works if it's applied to a typedef, see
Hi Konstantin,
> > Thanks for your input Konstantin. Much appreciated. Just to make sure
> > I understand, can you please confirm that we do not want to fix the
> > fact that unaligned access in C is undefined behaviour?
>
> Yes, I don't think it is a real problem in that particular case.
Perfect
> > Calls to rte_memcpy_generic could result in unaligned loads/stores for
> > 1 < n < 16. This is undefined behavior according to the C standard,
> > and it gets flagged by the clang undefined behavior sanitizer.
> >
> > rte_memcpy_generic is called with unaligned src and dst addresses.
> > When 1
Hi,
It's been several days and I haven't received any additional feedback
on this patch (and the other patch related to this one:
http://mails.dpdk.org/archives/dev/2022-January/232491.html). I would
welcome any kind of feedback. Ideally, I'm hoping an authoritative
voice would indicate if there's
Hi Georg,
> perhaps it's worth mentioning that the Linux Kernel is compiled with
> -fno-strict-aliasing, because it contains code which violates the C
> strict aliasing rules. Such code yields undefined behavior and is thus
> unsafe when compiling with optmizing compilers such as GCC and Clang, by
d35cc1fe6a7a ("eal/x86: revert select optimized memcpy at run-time")
Cc: Xiaoyun Li
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
Thanks to Stephen's pointer to look at the linux kernel, I was able to
find a way to perform the unaligned load/store using pure C code. The
new
86: revert select optimized memcpy at run-time")
Cc: Xiaoyun Li
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
Added volatile for asm statements. I had been testing with clang and it
was working but it seems gcc requires this, otherwise the asm is
completely discarded by the optimizer. The
lp in making
improvements.
Le dim. 16 janv. 2022 à 09:15, Luc Pelletier a écrit :
>
> Calls to rte_memcpy_generic could result in unaligned loads/stores for
> 1 < n < 16. This is undefined behavior according to the C standard,
> and it gets flagged by the clang undefined behavior
86: revert select optimized memcpy at run-time")
Cc: Xiaoyun Li
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
Please note that I didn't write the entire function in inline assembly.
The reason why I kept the bitwise ands as C code is so the optimizer can
remove the branches when n is k
> X86 always allows unaligned access. Irregardless of what tools say.
> Why impose additional overhead in performance critical code.
Let me preface my response by saying that I'm not a C compiler developer.
Hopefully someone who is will read this and chime in.
I agree that X86 allows unaligned st
produce
even more optimized results.
Fixes: d35cc1fe6a7a ("eal/x86: revert select optimized memcpy at run-time")
Cc: Xiaoyun Li
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
I forgot that code under x86 also needs to compile for 32-bit
(obviously). So, I did some more experiment
select optimized memcpy at run-time")
Cc: Xiaoyun Li
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
I have just submitted another patch related to rte_memcpy. The changes
in the other patch are straightforward. The changes in this patch are
likely to require more discussion, so I&#
ue.
Fixes: d35cc1fe6a7a ("eal/x86: revert select optimized memcpy at run-time")
Cc: Xiaoyun Li
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
lib/eal/x86/include/rte_memcpy.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/lib/eal/x86/includ
Hi Honnappa,
(Sorry if you get this message twice, I forgot to reply all the first time)
Sorry for the late reply. I was also away.
I have only made one small contribution to DPDK so I'll defer to
others to decide whether this patch should be accepted. When I
submitted my patch, I got the feelin
> > # Basic Intel(R) NIC testing
> > * PF(i40e, ixgbe): test scenarios including
> > rte_flow/TSO/Jumboframe/checksum offload/Tunnel, etc. Listed but not all.
> > - Known issues as below:
> > 1) https://bugs.dpdk.org/show_bug.cgi?id=731 – [dpdk-19.11.9]
> > telemetry: python3 /roo
l. I opted not to but it seems like
I should have. If it's a problem, please let me know and I'll repost
them with 'v8'.
Le jeu. 8 avr. 2021 à 10:20, Olivier Matz a écrit :
>
> Hi Luc,
>
> On Wed, Apr 07, 2021 at 04:16:06PM -0400, Luc Pelletier wrote:
> > The
o that the control thread exits
gracefully if the affinity cannot be set successfully and removes the
call to pthread_cancel.
Fixes: 6383d26 ("eal: set name when creating a control thread")
Cc: olivier.m...@6wind.com
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
Hi Olivi
: 3a0d465 ("eal: fix use-after-free on control thread creation")
Cc: jianfeng@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
Hi Olivier,
Hi Honnappa,
As discussed, I've split the changes into 2 patches. This first commit
fixes the race condition but leaves in the pthr
: 3a0d465d4c53 ("eal: fix use-after-free on control thread creation")
Cc: jianfeng@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
Hi Olivier,
Olivier, thanks for pointing out that pthread_barrier_wait acts as a
full memory barrier; I didn't know that was explicitly s
: 3a0d465d4c53 ("eal: fix use-after-free on control thread creation")
Cc: jianfeng@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
Hi Olivier,
I've made the changes as you requested. However, I'm using the atomic
built-ins for reading and writing start_rout
Not directly related to this patch, but can someone please explain why
Patchwork is creating a new series everytime I post a new version of
the patch to this thread? I must be doing something wrong but I don't
know what it is. I have been using --in-reply-to with git send-email
but that's apparentl
: 3a0d465d4c53 ("eal: fix use-after-free on control thread creation")
Cc: jianfeng@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
Same as v4 except that I fixed 2 minor style issues flagged by patchwork.
lib/librte_eal/common/eal_common_thread.c | 52 +++--
: 3a0d465d4c53 ("eal: fix use-after-free on control thread creation")
Cc: jianfeng@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
Hi Olivier,
Hi Honnappa,
Thanks for your comments Honnappa. You make a very good point about the
cancellation point requirements. I'
has been completely removed in favour
of a reference count on the control thread parameters struct.
Fixes: 3a0d465d4c53 ("eal: fix use-after-free on control thread creation")
Cc: jianfeng@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
Hi Olivier,
Hi Honnappa,
Thank
Hi Olivier,
Hi Honnappa,
Thanks for your input Honnappa. I've made the changes to
completely remove the barrier. However, I have not moved the
call to pthread_setaffinity_np to the control thread; I
think we still want to report the result of this function
to the caller of rte_ctrl_thread_create
s: 3a0d465d4c53 ("eal: fix use-after-free on control thread creation")
> Cc: jianfeng....@intel.com
> Cc: sta...@dpdk.org
>
> Reported-by: Luc Pelletier
> Signed-off-by: David Marchand
> Signed-off-by: Olivier Matz
> ---
>
> Hi Luc,
>
> Thank you for rep
: 3a0d465d4c53 ("eal: fix use-after-free on control thread creation")
Cc: jianfeng@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Luc Pelletier
---
lib/librte_eal/common/eal_common_thread.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/lib/librte_
47 matches
Mail list logo
