We make a test on this patch, test result show that it works fine. Below is the detail:
HW: Kunpeng920 ARM Platform which is ARMv8 NIC: Kunpeng920 SOC NIC OS: Linux centos-C3 5.12.0-rc4+ DPDK: 21.02 DRV: hns3 Start three process: ./testpmd -w 0000:bd:00.0 -l 67-68 --proc-type=auto -- -i --num-procs=3 --proc-id=0 ./testpmd -w 0000:bd:00.0 -l 67-68 --proc-type=auto -- -i --num-procs=3 --proc-id=1 ./testpmd -w 0000:bd:00.0 -l 69-70 --proc-type=auto -- -i --num-procs=3 --proc-id=2 Every process execute following steps: 1. create one fdir rule, eg: flow create 0 ingress pattern eth / ipv4 src is 192.168.110.26 / end actions queue index 0 / end note: each process has different rules, so they will create success 2. create one rss rule note: all process create the same rules, so they may create fail 3. flush all rules 4. goto step 1, loop again note: there are +10ms delay after step 1/2/3 because we run VBS script to inject command on windows. The test lasted 12 hours, and there are no process crashes. On 2021/4/14 21:06, Ferruh Yigit wrote: > On 3/16/2021 11:48 PM, Suanming Mou wrote: >> Hi Stephen, >> >>> -----Original Message----- >>> From: Stephen Hemminger <step...@networkplumber.org> >>> Sent: Tuesday, March 16, 2021 3:27 AM >>> To: dev@dpdk.org >>> Cc: Stephen Hemminger <step...@networkplumber.org>; Suanming Mou >>> <suanmi...@nvidia.com> >>> Subject: [PATCH 1/2] ethdev: make flow API primary/secondary process safe >>> >>> Posix mutex are not by default safe for protecting for usage from multiple >>> processes. The flow ops mutex could be used by both primary and secondary >>> processes. >> >> Process safe is something more widely scope. I assume it should be another >> feature but not a bugfix for thread-safe? >> And the fag RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE we have added is just thread >> safe. >> > > Hi Suanming, > > I think 'RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE' flag and what this patch address > are different issues. > > 'RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE' is to add/remove synchronization support > for flow APIs, that is for thread safety as flag name suggests. > > This patch is to solve the problem for multi process, where commit log > describes as posix mutex is not safe for multiple process. > > > Stephen, > Are you aware of any downside setting 'PTHREAD_PROCESS_SHARED' attribute to > the mutex? Any possible performance implications? > > Ori, > Since mlx is heavily using the flow API, is it possible to test this patch? > If there is no negative impact, I think we can get this patch, what do you > think? > >>> >>> Bugzilla ID: 662 >>> Signed-off-by: Stephen Hemminger <step...@networkplumber.org> >>> Fixes: 80d1a9aff7f6 ("ethdev: make flow API thread safe") >>> Cc: suanmi...@nvidia.com >>> --- >>> lib/librte_ethdev/rte_ethdev.c | 6 +++++- >>> 1 file changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/lib/librte_ethdev/rte_ethdev.c >>> b/lib/librte_ethdev/rte_ethdev.c index >>> 6f514c388b4e..d1024df408a5 100644 >>> --- a/lib/librte_ethdev/rte_ethdev.c >>> +++ b/lib/librte_ethdev/rte_ethdev.c >>> @@ -470,6 +470,7 @@ rte_eth_dev_allocate(const char *name) { >>> uint16_t port_id; >>> struct rte_eth_dev *eth_dev = NULL; >>> + pthread_mutexattr_t attr; >>> size_t name_len; >>> >>> name_len = strnlen(name, RTE_ETH_NAME_MAX_LEN); @@ -506,7 >>> +507,10 @@ rte_eth_dev_allocate(const char *name) >>> strlcpy(eth_dev->data->name, name, sizeof(eth_dev->data->name)); >>> eth_dev->data->port_id = port_id; >>> eth_dev->data->mtu = RTE_ETHER_MTU; >>> - pthread_mutex_init(ð_dev->data->flow_ops_mutex, NULL); >>> + >>> + pthread_mutexattr_init(&attr); >>> + pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED); >>> >>> + pthread_mutex_init(ð_dev->data->flow_ops_mutex, &attr); >>> >>> unlock: >>> rte_spinlock_unlock(ð_dev_shared_data->ownership_lock); >>> -- >>> 2.30.2 >> > > > .