[PATCH] bus/fslmc: unlock spinlock in case of timeout
Commit 79711846f6 introduces timeouts to mc, but in case of
a timeout, the spinlock that was locked before isn't unlocked.
Fixes: 79711846f6 ("bus/fslmc: add timeout in MC send command API")
Signed-off-by: Alvaro Karsz
---
drivers/bus/fslmc/mc/mc_sys.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/fslmc/mc/mc_sys.c b/drivers/bus/fslmc/mc/mc_sys.c
index ab9a074835..a78e504bd2 100644
--- a/drivers/bus/fslmc/mc/mc_sys.c
+++ b/drivers/bus/fslmc/mc/mc_sys.c
@@ -77,8 +77,12 @@ int mc_send_command(struct fsl_mc_io *mc_io, struct
mc_command *cmd)
total_time = rte_get_timer_cycles() - start_time;
} while (status == MC_CMD_STATUS_READY && total_time <= time_to_wait);
- if (status == MC_CMD_STATUS_READY)
+ if (status == MC_CMD_STATUS_READY) {
+ /* --- Call unlock function here in case portal is shared --- */
+ rte_spinlock_unlock(&mc_portal_lock);
+
return mc_status_to_error(MC_CMD_STATUS_TIMEOUT);
+ }
/* Read the response back into the command buffer */
mc_read_response(mc_io->regs, cmd);
--
2.32.0
Re: [PATCH] bus/fslmc: unlock spinlock in case of timeout
Sorry guys, I got test-report errors. The commit id format is wrong and it seems that I have an indentation error. I will fix it and submit a new version.
[PATCH v1 0/2] fix unsupported flow rule transfer attribute
ice & i40e doesn't support transfer attribute of flow rule, ignore it when validating rule attributes. Steve Yang (2): net/i40e: fix unsupported flow rule transfer attribute net/ice: fix unsupported flow rule transfer attribute drivers/net/i40e/i40e_flow.c | 8 drivers/net/ice/ice_generic_flow.c | 8 2 files changed, 16 insertions(+) -- 2.25.1
[PATCH v1 1/2] net/i40e: fix unsupported flow rule transfer attribute
i40e doesn't support transfer attribute of flow rule,
ignore it when validating rule attributes.
Fixes: 86eb05d6350b ("net/i40e: add flow validate function")
Signed-off-by: Steve Yang
---
drivers/net/i40e/i40e_flow.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c
index 65a826d51c..67df77890a 100644
--- a/drivers/net/i40e/i40e_flow.c
+++ b/drivers/net/i40e/i40e_flow.c
@@ -1236,6 +1236,14 @@ i40e_flow_parse_attr(const struct rte_flow_attr *attr,
return -rte_errno;
}
+ /* Not supported */
+ if (attr->transfer) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ATTR_TRANSFER,
+ attr, "Not support transfer.");
+ return -rte_errno;
+ }
+
/* Not supported */
if (attr->priority) {
rte_flow_error_set(error, EINVAL,
--
2.25.1
[PATCH v1 2/2] net/ice: fix unsupported flow rule transfer attribute
ice doesn't support transfer attribute of flow rule,
ignore it when validating rule attributes.
Fixes: d76116a4678f ("net/ice: add generic flow API")
Signed-off-by: Steve Yang
---
drivers/net/ice/ice_generic_flow.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ice/ice_generic_flow.c
b/drivers/net/ice/ice_generic_flow.c
index d496c28dec..86a32f8cb1 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -2030,6 +2030,14 @@ ice_flow_valid_attr(struct ice_adapter *ad,
return -rte_errno;
}
+ /* Not supported */
+ if (attr->transfer) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ATTR_TRANSFER,
+ attr, "Not support transfer.");
+ return -rte_errno;
+ }
+
/* Check pipeline mode support to set classification stage */
if (ad->devargs.pipe_mode_support) {
if (attr->priority == 0)
--
2.25.1
RE: [PATCH v1 0/2] fix unsupported flow rule transfer attribute
Hi, > -Original Message- > From: Yang, SteveX > Sent: Monday, December 26, 2022 8:37 AM > To: dev@dpdk.org > Cc: Zhang, Yuying ; Xing, Beilei > ; Yang, Qiming ; Zhang, Qi Z > ; Yang, SteveX > Subject: [PATCH v1 0/2] fix unsupported flow rule transfer attribute > > ice & i40e doesn't support transfer attribute of flow rule, ignore it when > validating rule attributes. > > Steve Yang (2): > net/i40e: fix unsupported flow rule transfer attribute > net/ice: fix unsupported flow rule transfer attribute > > drivers/net/i40e/i40e_flow.c | 8 > drivers/net/ice/ice_generic_flow.c | 8 > 2 files changed, 16 insertions(+) > > -- > 2.25.1 Acked-by: Qiming Yang
RE: [PATCH] net/iavf:fix slow memory allocation
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, December 22, 2022 8:07 PM
> To: You, KaisenX ; dev@dpdk.org; Burakov, Anatoly
> ; David Marchand
>
> Cc: sta...@dpdk.org; Yang, Qiming ; Zhou, YidingX
> ; Wu, Jingjing ; Xing, Beilei
> ; Zhang, Qi Z ; Luca Boccassi
> ; Mcnamara, John ; Kevin
> Traynor
> Subject: Re: [PATCH] net/iavf:fix slow memory allocation
>
> On 12/22/2022 7:23 AM, You, KaisenX wrote:
> >
> >
> >> -Original Message-
> >> From: Ferruh Yigit
> >> Sent: 2022年12月21日 21:49
> >> To: You, KaisenX ; dev@dpdk.org; Burakov,
> >> Anatoly ; David Marchand
> >>
> >> Cc: sta...@dpdk.org; Yang, Qiming ; Zhou,
> >> YidingX ; Wu, Jingjing
> >> ; Xing, Beilei ; Zhang,
> >> Qi Z ; Luca Boccassi ;
> >> Mcnamara, John ; Kevin Traynor
> >>
> >> Subject: Re: [PATCH] net/iavf:fix slow memory allocation
> >>
> >> On 12/20/2022 6:52 AM, You, KaisenX wrote:
> >>>
> >>>
> -Original Message-
> From: Ferruh Yigit
> Sent: 2022年12月13日 21:28
> To: You, KaisenX ; dev@dpdk.org; Burakov,
> Anatoly ; David Marchand
>
> Cc: sta...@dpdk.org; Yang, Qiming ; Zhou,
> YidingX ; Wu, Jingjing
> ; Xing, Beilei ;
> Zhang, Qi Z ; Luca Boccassi
> ; Mcnamara, John ;
> Kevin
> Traynor
> Subject: Re: [PATCH] net/iavf:fix slow memory allocation
>
> On 12/13/2022 9:35 AM, Ferruh Yigit wrote:
> > On 12/13/2022 7:52 AM, You, KaisenX wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Ferruh Yigit
> >>> Sent: 2022年12月8日 23:04
> >>> To: You, KaisenX ; dev@dpdk.org; Burakov,
> >>> Anatoly ; David Marchand
> >>>
> >>> Cc: sta...@dpdk.org; Yang, Qiming ; Zhou,
> >>> YidingX ; Wu, Jingjing
> >>> ; Xing, Beilei ;
> >>> Zhang, Qi Z ; Luca Boccassi
> >>> ; Mcnamara, John
> ;
> Kevin
> >>> Traynor
> >>> Subject: Re: [PATCH] net/iavf:fix slow memory allocation
> >>>
> >>> On 11/17/2022 6:57 AM, Kaisen You wrote:
> In some cases, the DPDK does not allocate hugepage heap memory
> >> to
> >>> some
> sockets due to the user setting parameters (e.g. -l 40-79,
> SOCKET
> 0 has no memory).
> When the interrupt thread runs on the corresponding core of
> this socket, each allocation/release will execute a whole set
> of heap allocation/release operations,resulting in poor
> performance.
> Instead we call malloc() to get memory from the system's heap
> space to fix this problem.
>
> >>>
> >>> Hi Kaisen,
> >>>
> >>> Using libc malloc can improve performance for this case, but I
> >>> would like to understand root cause of the problem.
> >>>
> >>>
> >>> As far as I can see, interrupt callbacks are run by interrupt
> >>> thread
> >>> ("eal-intr- thread"), and interrupt thread created by
> 'rte_ctrl_thread_create()' API.
> >>>
> >>> 'rte_ctrl_thread_create()' comment mentions that "CPU affinity
> >>> retrieved at the time 'rte_eal_init()' was called,"
> >>>
> >>> And 'rte_eal_init()' is run on main lcore, which is the first
> >>> lcore in the core list (unless otherwise defined with --main-lcore).
> >>>
> >>> So, the interrupts should be running on a core that has
> >>> hugepages allocated for it, am I missing something here?
> >>>
> >>>
> >> Thank for your comments. Let me try to explain the root cause here:
> >> eal_intr_thread the CPU in the corresponding slot does not create
> memory pool.
> >> That results in frequent memory subsequently creating/destructing.
> >>
> >> When testpmd started, the parameter (e.g. -l 40-79) is set.
> >> Different OS has different topology. Some OS like SUSE only
> >> creates memory pool for one CPU slot, while other system creates for
> two.
> >> That is why the problem occurs when using memories in different OS.
> >
> >
> > It is testpmd application that decides from which socket to
> > allocate memory from, right. This is nothing specific to OS.
> >
> > As far as I remember, testpmd logic is too allocate from socket
> > that its cores are used (provided with -l parameter), and allocate
> > from socket that device is attached to.
> >
> > So, in a dual socket system, if all used cores are in socket 1 and
> > the NIC is in socket 1, no memory is allocated for socket 0. This
> > is to optimize memory consumption.
> >
> >
> > Can you please confirm that the problem you are observing is
> > because interrupt handler is running on a CPU, which doesn't have
> > memory allocated for its socket?
> >
> > In this case what I don't understand is why interrupts is not
> > running on main lcore, which should be first core in the list, for "-l
> > 40-
> 79"
> > sample it should be lcore 40.
> > For your case, is interrupt handler
RE: [PATCH v2] net/iavf: fix outer udp checksum offload
> -Original Message-
> From: Xu, Ke1
> Sent: Wednesday, December 14, 2022 9:51 AM
> To: Zeng, ZhichaoX ; dev@dpdk.org
> Cc: Zhou, YidingX ; Zhang, Qi Z
> ; Wu, Jingjing ; Xing, Beilei
> ; Nicolau, Radu
> Subject: RE: [PATCH v2] net/iavf: fix outer udp checksum offload
>
>
>
> > -Original Message-
> > From: Zeng, ZhichaoX
> > Sent: Tuesday, December 13, 2022 9:45 AM
> > To: dev@dpdk.org
> > Cc: Zhou, YidingX ; Xu, Ke1
> > ; Zhang, Qi Z ; Zeng, ZhichaoX
> > ; Wu, Jingjing ; Xing,
> > Beilei ; Nicolau, Radu
> > Subject: [PATCH v2] net/iavf: fix outer udp checksum offload
> >
> > Currently, when dealing with UDP tunnel pkts checksum offloading, the
> > outer-udp checksum will be offloaded by default. So the 'csum set
> > outer-udp hw/sw' command does not work.
> >
> > This patch fixes judgment of the EIPT flag and enables the 'csum set
> > outer- udp hw/sw' command by adding judgment for the outer-udp
> > checksum offload flag.
> >
> > Fixes: 0c550022fb82 ("net/iavf: fix Tx descriptors for IPsec")
> >
> > Signed-off-by: Zhichao Zeng
>
> Verified and passed.
>
> Verified applying only outer IP checksum without outer UDP checksum. Outer
> UDP checksum will be errors as this feature is to ignore this checksum error.
> Inner checksum is not influenced. Outer IP checksum is not influenced.
>
> Verified applying all checksum HW offload.
>
> > ---
> > drivers/net/iavf/iavf_rxtx.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
Applied to dpdk-next-net-intel.
Thanks
Qi
[PATCH v7] doc: add PMD known issue
Add a known issue: Rx path dynamic routing is not supported for PMD.
Fixes: de853a3bb151 ("net/ice: disable DDP package on Windows")
Cc: sta...@dpdk.org
Signed-off-by: Mingjin Ye
---
doc/guides/nics/ice.rst | 23 +++
1 file changed, 23 insertions(+)
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index ce075e067c..01fb96101f 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -395,3 +395,26 @@ file is used by both the kernel driver and the DPDK PMD.
Windows support: The DDP package is not supported on Windows so,
loading of the package is disabled on Windows.
+
+ice: Rx path is not supported after PF or DCF add vlan offload
+~~
+
+If pmd does not enable Vlan offload during initialization, it will
+automatically select Rx paths that do not support offload. Even if
+Vlan offload is subsequently enabled through the API, Vlan offload
+will not work because the selected Rx path does not support Vlan
+offload.
+
+cmd_vlan_offload_parsed() goes down to the follow ethdev API functions:
+- rte_eth_dev_set_vlan_strip_on_queue()
+- rte_eth_dev_set_vlan_offload()
+These functions add offload settings when the port is started, running
+and processing traffic. At this time, ``rte_eth_rx_queue_setup`` api is
+needed to reroute rxq to the RX path with offload function. But at this
+time, it is possible that the original Rx path is handling packages, so
+this is not thread-safe.
+
+When applying offload on the PF or DCF, starting the ``testpmd``
+application, use the ``--rx-offloads`` startup parameter to force the
+dpdk lib to choose the Rx path with the offload function by default.
+
--
2.34.1
Re: [PATCH v5 2/5] telemetry: fix repeated display when callback don't set dict
On 2022/12/19 17:33, Bruce Richardson wrote:
> On Mon, Dec 19, 2022 at 09:07:20AM +, Chengwen Feng wrote:
>> When telemetry callback didn't set dict and return a non-negative
>> number, the telemetry will repeat to display the last result.
>>
>> Fixes: 6dd571fd07c3 ("telemetry: introduce new functionality")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Chengwen Feng
>> ---
>
> Hi Chengwen,
>
> I'm a little curious about this bug. Can you describe some steps to
> reproduce it as I'm curious as to exactly what is happening. The fix seems
> a little strange to me so I'd like to investigate a little more to see if
> other approaches might work.
Hi Bruce,
Sorry for late reply.
The steps:
1. applay "[PATCH v5 1/5] dmadev: support stats reset telemetry command"
2. compile
3. start dpdk-dma: dpdk-dma -a DMA.BDF -a NIC.BDF -- -c hw
4. start telemetry, and execute /dmadev/stats,0, and then
/dmadev/stats_reset,0
the output of /dmadev/stats_reset,0 will be the same of previous cmd
"/dmadev/stats,0"
e.g. my environment:
--> /dmadev/stats,0
{
"/dmadev/stats": {
"submitted": 23,
"completed": 23,
"errors": 0
}
}
--> /dmadev/stats_reset,0
{
"/dmadev/stats_reset": {
"submitted": 23,
"completed": 23,
"errors": 0
}
}
The rootcause is that the /dmadev/stats_reset don't set the outer parameter
"struct rte_tel_data *info"
and return zero.
BTW: although the telemetry mainly used to query, but some reset counter maybe
usefull, and it already
exist like: "/eventdev/rxa_stats_reset" and this patchset.
>
> Thanks,
> /Bruce
> .
>
Re: [PATCH v5 0/5] support dmadev/ethdev stats reset
Sorry for the patchset version set wrong, it should be 'PATCH v1' not 'PATCH v5' Will fix in V2 On 2022/12/19 17:07, Chengwen Feng wrote: > This patchset contains dmadev/ethdev stats reset, and also support > hide zero for ethdev xstats. > > Chengwen Feng (5): > dmadev: support stats reset telemetry command > telemetry: fix repeated display when callback don't set dict > ethdev: support xstats reset telemetry command > ethdev: telemetry xstats support hide zero > ethdev: add newline to telemetry log string > > lib/dmadev/rte_dmadev.c | 40 +++ > lib/ethdev/rte_ethdev.c | 57 --- > lib/telemetry/telemetry.c | 4 ++- > 3 files changed, 91 insertions(+), 10 deletions(-) >
RE: [PATCH] net/i40e: reduce the ITR interval of multi-driver mode
> -Original Message-
> From: Qiming Yang
> Sent: Friday, December 16, 2022 11:12 AM
> To: dev@dpdk.org; Xing, Beilei
> Cc: Yang, Qiming
> Subject: [PATCH] net/i40e: reduce the ITR interval of multi-driver mode
>
> This patch change the interrupt interval from 8160us to 32us to improve the
> performance of multi-driver mode.
>
> Signed-off-by: Qiming Yang
Acked-by: Qi Zhang
Applied to dpdk-next-net-intel.
The patch also looks good for backporting, so added Cc stable tag.
Thanks
Qi
> ---
> drivers/net/i40e/i40e_ethdev.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
> index fe943a45ff..7c4cc44a27 100644
> --- a/drivers/net/i40e/i40e_ethdev.h
> +++ b/drivers/net/i40e/i40e_ethdev.h
> @@ -1497,7 +1497,7 @@ i40e_calc_itr_interval(bool is_pf, bool is_multi_drv)
> uint16_t interval = 0;
>
> if (is_multi_drv) {
> - interval = I40E_QUEUE_ITR_INTERVAL_MAX;
> + interval = I40E_QUEUE_ITR_INTERVAL_DEFAULT;
> } else {
> if (is_pf)
> interval = I40E_QUEUE_ITR_INTERVAL_DEFAULT;
> --
> 2.25.1
RE: [PATCH v2] net/iavf: add lock for vf commands
> -Original Message-
> From: Mike Pattrick
> Sent: Tuesday, December 20, 2022 11:54 PM
> To: dev@dpdk.org
> Cc: Zhang, Qi Z ; tho...@monjalon.net;
> david.march...@redhat.com; Zhou, YidingX ;
> ktray...@redhat.com; Mike Pattrick ; sta...@dpdk.org
> Subject: [PATCH v2] net/iavf: add lock for vf commands
>
> iavf admin queue commands aren't thread-safe. Bugs surrounding this issue
> can manifest in a variety of ways but frequently pend_cmd is over written.
> Simultaneously executing commands can result in a misconfigured device or
> DPDK sleeping in a thread for 2 second.
>
> Despite this limitation, vf commands may be executed from both
> iavf_dev_alarm_handler() in a control thread and the applications main
> thread. This is trivial to simulate in the testpmd application by creating a
> bond of vf's in active backup mode, and then turning the bond off and then
> on again repeatedly.
>
> Previously [1] was proposed as a potential solution, but this commit did not
> resolve all potential issues concerning the admin queue and has been
> reverted from the stable branch. I propose adding locks until a more
> complete solution is available.
>
> [1] commit cb5c1b91f76f ("net/iavf: add thread for event callbacks")
>
> Fixes: 48de41ca11f0 ("net/avf: enable link status update")
> Fixes: 84108425054a ("net/iavf: support asynchronous virtual channel
> message")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Mike Pattrick
>
> ---
>
> v2:
> - Added locks around some iavf_execute_vf_cmd calls which were missed in
> v1
> - Changed description to indicate that [1] was only reverted out of the
> stable
> branch.
> ---
> drivers/net/iavf/iavf.h | 1 +
> drivers/net/iavf/iavf_vchnl.c | 90 +++
> 2 files changed, 91 insertions(+)
>
> diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h index
> 1edebab8dc..aa18650ffa 100644
> --- a/drivers/net/iavf/iavf.h
> +++ b/drivers/net/iavf/iavf.h
> @@ -262,6 +262,7 @@ struct iavf_info {
> struct iavf_qv_map *qv_map; /* queue vector mapping */
> struct iavf_flow_list flow_list;
> rte_spinlock_t flow_ops_lock;
> + rte_spinlock_t aq_lock;
> struct iavf_parser_list rss_parser_list;
> struct iavf_parser_list dist_parser_list;
> struct iavf_parser_list ipsec_crypto_parser_list; diff --git
> a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c index
> f92daf97f2..edb74edcac 100644
> --- a/drivers/net/iavf/iavf_vchnl.c
> +++ b/drivers/net/iavf/iavf_vchnl.c
> @@ -554,7 +554,9 @@ iavf_enable_vlan_strip(struct iavf_adapter *adapter)
> args.in_args_size = 0;
> args.out_buffer = vf->aq_resp;
> args.out_size = IAVF_AQ_BUF_SZ;
> + rte_spinlock_lock(&vf->aq_lock);
> ret = iavf_execute_vf_cmd(adapter, &args, 0);
> + rte_spinlock_unlock(&vf->aq_lock);
> if (ret)
> PMD_DRV_LOG(ERR, "Failed to execute command of"
> " OP_ENABLE_VLAN_STRIPPING");
> @@ -575,7 +577,9 @@ iavf_disable_vlan_strip(struct iavf_adapter *adapter)
> args.in_args_size = 0;
> args.out_buffer = vf->aq_resp;
> args.out_size = IAVF_AQ_BUF_SZ;
> + rte_spinlock_lock(&vf->aq_lock);
> ret = iavf_execute_vf_cmd(adapter, &args, 0);
> + rte_spinlock_unlock(&vf->aq_lock);
> if (ret)
> PMD_DRV_LOG(ERR, "Failed to execute command of"
> " OP_DISABLE_VLAN_STRIPPING");
> @@ -604,7 +608,9 @@ iavf_check_api_version(struct iavf_adapter *adapter)
> args.out_buffer = vf->aq_resp;
> args.out_size = IAVF_AQ_BUF_SZ;
>
> + rte_spinlock_lock(&vf->aq_lock);
> err = iavf_execute_vf_cmd(adapter, &args, 0);
> + rte_spinlock_unlock(&vf->aq_lock);
Instead of wrapping lock and unlock every place, can we add a new wrap function
e.g.: iavf_execute_vf_cmd_safe?
RE: [PATCH v2] net/ice: add devargs for disabling mac filter
> -Original Message-
> From: Zhang, Ke1X
> Sent: Wednesday, December 21, 2022 11:58 AM
> To: Zhang, Qi Z ; Zhang, Yuying
> ; dev@dpdk.org
> Cc: Zhang, Ke1X
> Subject: [PATCH v2] net/ice: add devargs for disabling mac filter
>
> From: "ke1x.zhang"
>
> This patch adds support to disable mac filter which will be used by ice driver
> when setting dpdk_devargs config field in the TRex config file.
>
> Mac filter is not disabled in default.
>
> Signed-off-by: ke1x.zhang
> ---
> doc/guides/nics/ice.rst| 11 +++
> drivers/net/ice/ice_ethdev.c | 13 +
> drivers/net/ice/ice_ethdev.h | 1 +
> drivers/net/ice/ice_generic_flow.c | 15 +++
> 4 files changed, 40 insertions(+)
>
> diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst index
> ce075e067c..18b4d12048 100644
> --- a/doc/guides/nics/ice.rst
> +++ b/doc/guides/nics/ice.rst
> @@ -105,6 +105,17 @@ Runtime Config Options
>
> -a 80:00.0,pipeline-mode-support=1
>
> +- ``Disable Mac Filter Support`` (default ``0``)
I think better to name the feature as "No default Mac" , as we still support
add/del MAC filter.
> +
> + Add the feature that support to disable mac filter which will be used
> + by ice driver when setting dpdk_devargs config field in the TRex config
> file.
> +
No need to mention TRex here, just describe what's the expected behavior when
user set this flag.
> + Mac filter is not disabled in default, user can choose to disable the
> + mac filter by setting ``devargs`` parameter ``mac-filter-disable``,
> + for example::
> +
> +-a 80:00.0,mac-filter-disable=1
> +
> - ``Protocol extraction for per queue``
>
>Configure the RX queues to do protocol extraction into mbuf for protocol
> diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c index
> 0bc739daf0..0c9f66eb88 100644
> --- a/drivers/net/ice/ice_ethdev.c
> +++ b/drivers/net/ice/ice_ethdev.c
> @@ -28,6 +28,7 @@
> /* devargs */
> #define ICE_SAFE_MODE_SUPPORT_ARG "safe-mode-support"
> #define ICE_PIPELINE_MODE_SUPPORT_ARG "pipeline-mode-support"
> +#define ICE_MAC_FILTER_DISABLE "mac-filter-disable"
> #define ICE_PROTO_XTR_ARG "proto_xtr"
> #define ICE_FIELD_OFFS_ARG "field_offs"
> #define ICE_FIELD_NAME_ARG "field_name"
> @@ -49,6 +50,7 @@ static const char * const ice_valid_args[] = {
> ICE_HW_DEBUG_MASK_ARG,
> ICE_ONE_PPS_OUT_ARG,
> ICE_RX_LOW_LATENCY_ARG,
> + ICE_MAC_FILTER_DISABLE,
> NULL
> };
>
> @@ -962,8 +964,13 @@ ice_add_mac_filter(struct ice_vsi *vsi, struct
> rte_ether_addr *mac_addr)
> struct ice_mac_filter *f;
> struct LIST_HEAD_TYPE list_head;
> struct ice_hw *hw = ICE_VSI_TO_HW(vsi);
> + struct ice_adapter *ad = (struct ice_adapter *)hw->back;
> int ret = 0;
>
> + if (ad->devargs.mac_filter_disable == 1) {
> + PMD_DRV_LOG(ERR, "This MAC filter is disabled.");
> + return 0;
> + }
> /* If it's added and configured, return */
> f = ice_find_mac_filter(vsi, mac_addr);
> if (f) {
> @@ -2075,6 +2082,11 @@ static int ice_parse_devargs(struct rte_eth_dev
> *dev)
> if (ret)
> goto bail;
>
> + ret = rte_kvargs_process(kvlist, ICE_MAC_FILTER_DISABLE,
> + &parse_bool, &ad-
> >devargs.mac_filter_disable);
> + if (ret)
> + goto bail;
> +
> ret = rte_kvargs_process(kvlist, ICE_HW_DEBUG_MASK_ARG,
>&parse_u64, &ad->hw.debug_mask);
> if (ret)
> @@ -6050,6 +6062,7 @@ RTE_PMD_REGISTER_PARAM_STRING(net_ice,
> ICE_PROTO_XTR_ARG
> "=[queue:]"
> ICE_SAFE_MODE_SUPPORT_ARG "=<0|1>"
> ICE_PIPELINE_MODE_SUPPORT_ARG "=<0|1>"
> + ICE_MAC_FILTER_DISABLE "=<0|1>"
> ICE_RX_LOW_LATENCY_ARG "=<0|1>");
>
> RTE_LOG_REGISTER_SUFFIX(ice_logtype_init, init, NOTICE); diff --git
> a/drivers/net/ice/ice_ethdev.h b/drivers/net/ice/ice_ethdev.h index
> c8311be179..b4036d5fb0 100644
> --- a/drivers/net/ice/ice_ethdev.h
> +++ b/drivers/net/ice/ice_ethdev.h
> @@ -563,6 +563,7 @@ struct ice_devargs {
> int safe_mode_support;
> uint8_t proto_xtr_dflt;
> int pipe_mode_support;
> + uint8_t mac_filter_disable;
> uint8_t proto_xtr[ICE_MAX_QUEUE_NUM];
> uint8_t pin_idx;
> uint8_t pps_out_ena;
> diff --git a/drivers/net/ice/ice_generic_flow.c
> b/drivers/net/ice/ice_generic_flow.c
> index d496c28dec..bca38f5a52 100644
> --- a/drivers/net/ice/ice_generic_flow.c
> +++ b/drivers/net/ice/ice_generic_flow.c
> @@ -2464,6 +2464,8 @@ ice_flow_create(struct rte_eth_dev *dev,
> struct rte_flow_error *error)
> {
> struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data-
> >dev_private);
> + struct ice_adapter *ad =
> + ICE_DEV_PRIVATE_TO_ADAPTER(dev->
[PATCH] examples/vdpa: fix devices cleanup
Move rte_eal_cleanup to function vdpa_sample_quit which
handling all example app quit.
Otherwise rte_eal_cleanup won't be called on receiving signal
like SIGINT(control + c).
Fixes: 10aa3757 ("examples: add eal cleanup to examples")
Cc: sta...@dpdk.org
Signed-off-by: Yajun Wu
Acked-by: Matan Azrad
---
examples/vdpa/main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/examples/vdpa/main.c b/examples/vdpa/main.c
index 4c7e81d7b6..9149b66538 100644
--- a/examples/vdpa/main.c
+++ b/examples/vdpa/main.c
@@ -287,6 +287,8 @@ vdpa_sample_quit(void)
if (vports[i].ifname[0] != '\0')
close_vdpa(&vports[i]);
}
+ /* clean up the EAL */
+ rte_eal_cleanup();
}
static void
@@ -633,8 +635,5 @@ main(int argc, char *argv[])
vdpa_sample_quit();
}
- /* clean up the EAL */
- rte_eal_cleanup();
-
return 0;
}
--
2.27.0
[PATCH v2] bus/fslmc: unlock spinlock in case of timeout
Bug in function mc_send_command,
A spinlock is not unlocked in case of timeouts.
Fixes: 79711846f676 ("bus/fslmc: add timeout in MC send command")
Signed-off-by: Alvaro Karsz
--
v2:
- Fix code indentation.
- Fix "Fixes: " tag format.
---
drivers/bus/fslmc/mc/mc_sys.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/fslmc/mc/mc_sys.c b/drivers/bus/fslmc/mc/mc_sys.c
index ab9a074835..018bd9990e 100644
--- a/drivers/bus/fslmc/mc/mc_sys.c
+++ b/drivers/bus/fslmc/mc/mc_sys.c
@@ -77,8 +77,12 @@ int mc_send_command(struct fsl_mc_io *mc_io, struct
mc_command *cmd)
total_time = rte_get_timer_cycles() - start_time;
} while (status == MC_CMD_STATUS_READY && total_time <= time_to_wait);
- if (status == MC_CMD_STATUS_READY)
+ if (status == MC_CMD_STATUS_READY) {
+ /* --- Call unlock function here in case portal is shared --- */
+ rte_spinlock_unlock(&mc_portal_lock);
+
return mc_status_to_error(MC_CMD_STATUS_TIMEOUT);
+ }
/* Read the response back into the command buffer */
mc_read_response(mc_io->regs, cmd);
--
2.32.0
