Re: [dpdk-dev] [EXT] [PATCH] trace: fix build with gcc 10

[Phil Yang]

From: Sunil Kumar Kori  
Sent: Tuesday, April 28, 2020 11:49 AM
To: Phil Yang ; jer...@marvell.com; dev@dpdk.org
Cc: David Marchand ; Ruifeng Wang 
; Lijian Zhang ; nd 
Subject: [EXT] [PATCH] trace: fix build with gcc 10

Sent from Workspace ONE Boxer
On 27-Apr-2020 10:18 PM, Phil Yang  wrote: 
>
> External Email 
>
> -- 
> GCC 10 compiling output: 
> eal_common_trace_utils.c: In function 'eal_trace_dir_args_save': 
> eal_common_trace_utils.c:290:24: error: '__builtin___sprintf_chk'   \ 
>     may write a terminating nul past the end of the destination \ 
>     [-Werror=format-overflow=] 
>   290 |  sprintf(dir_path, "%s/", optarg); 
>   |    ^ 
>
> Fixes: 8af866df8d8c ("trace: add trace directory configuration parameter") 
>
Hello, there is one more thread going on regarding this. Please have a look on 
below patch. 
http://patches.dpdk.org/patch/69382/

Hi Sunil,

Sorry, I didn’t notice that. Thanks for the link. 

I have two points:
1. Will this patch resolves both mentioned warnings/error in  patch 69382 ?
[Phil] Yes, this patch resolved the same issue mentioned by David in patch 
69382.

2. David has suggested another way of doing it. Please check that too.
[Phil]  I think both David’s and my patches are correct.
My patch can guarantee a correct ‘size’ information in snprinf(). It omits the 
memory allocation operation for the incorrect input arguments case.
David’s suggestion resolves the potential directory copy fail issue and it 
saves some memory space in the normal case. But it needs to allocate memory in 
the incorrect input case.

So, I think we can bind these two patches together?

Thanks,
Phil

> Signed-off-by: Phil Yang  
> Reviewed-by: Lijian Zhang  
> Tested-by: Lijian Zhang  
> --- 
>  lib/librte_eal/common/eal_common_trace_utils.c | 5 - 
>  1 file changed, 4 insertions(+), 1 deletion(-) 
>
> diff --git a/lib/librte_eal/common/eal_common_trace_utils.c 
> b/lib/librte_eal/common/eal_common_trace_utils.c 
> index fce8892..c079642 100644 
> --- a/lib/librte_eal/common/eal_common_trace_utils.c 
> +++ b/lib/librte_eal/common/eal_common_trace_utils.c 
> @@ -276,7 +276,10 @@ eal_trace_dir_args_save(char const *optarg) 
>  return -EINVAL; 
>  } 
>   
> -   if (strlen(optarg) >= size) { 
> +   /* the specified trace directory name cannot 
> +    * exceed PATH_MAX-1. 
> +    */ 
> +   if (strlen(optarg) >= (size - 1)) { 
>  trace_err("input string is too big"); 
>  return -ENAMETOOLONG; 
>  } 
> -- 
> 2.7.4 
>

Re: [dpdk-dev] [PATCH] trace: fix build with gcc 10

[Phil Yang]

> -Original Message-
> From: Stephen Hemminger 
> Sent: Tuesday, April 28, 2020 12:59 AM
> To: Phil Yang 
> Cc: jer...@marvell.com; sk...@marvell.com; dev@dpdk.org;
> david.march...@redhat.com; Lijian Zhang ;
> Ruifeng Wang ; nd 
> Subject: Re: [dpdk-dev] [PATCH] trace: fix build with gcc 10
> 
> On Tue, 28 Apr 2020 00:47:38 +0800
> Phil Yang  wrote:
> 
> > -   if (strlen(optarg) >= size) {
> > +   /* the specified trace directory name cannot
> > +* exceed PATH_MAX-1.
> > +*/
> > +   if (strlen(optarg) >= (size - 1)) {
> > trace_err("input string is too big");
> 
> strnlen() is useful for these kinds of cases.

Thanks, Stephen.
I think it checks the dir_name length here, not to trim the input 'optarg'.
So I think the strlen() can handle it correctly.

Thanks,
Phil 

Re: [dpdk-dev] [PATCH v2 3/3] net/i40e: remove teardown when flush FDIR filter

[Xing, Beilei]

Didn't address my comment in v1 patch.

> -Original Message-
> From: Zhao1, Wei 
> Sent: Tuesday, April 28, 2020 1:48 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Xing, Beilei ;
> maxime.le...@6wind.com; Zhao1, Wei 
> Subject: [PATCH v2 3/3] net/i40e: remove teardown when flush FDIR filter
> 
> When we flush FDIR filter, we can not call i40e_fdir_teardown() function as it
> will free vsi used for FDIR, then the vsi->base_queue will be freed from pf-
> >qp_pool, but vsi->base_queue can only get once when do dev init in
> i40e_pf_setup(). If we free it, it will never be alloc again.
> 
> Bugzilla ID: 404
> Fixes: 2e67a7fbf3ff ("net/i40e: config flow director automatically")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Wei Zhao 
> ---
>  drivers/net/i40e/i40e_flow.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c index
> 1533d5abb..65f877866 100644
> --- a/drivers/net/i40e/i40e_flow.c
> +++ b/drivers/net/i40e/i40e_flow.c
> @@ -5145,7 +5145,6 @@ i40e_flow_destroy(struct rte_eth_dev *dev,
> 
>   /* If the last flow is destroyed, disable fdir. */
>   if (!ret && TAILQ_EMPTY(&pf->fdir.fdir_list)) {
> - i40e_fdir_teardown(pf);
>   i40e_fdir_rx_proc_enable(dev, 0);
>   }
>   break;
> @@ -5343,8 +5342,6 @@ i40e_flow_flush_fdir_filter(struct i40e_pf *pf)
>   pf->fdir.inset_flag[pctype] = 0;
>   }
> 
> - i40e_fdir_teardown(pf);
> -
>   return ret;
>  }
> 
> --
> 2.19.1

Re: [dpdk-dev] [PATCH] net/ice/base: workaround for unexpected rule deletion

[Ye Xiaolong]

On 04/24, Zhao1, Wei wrote:
>It will be delete after fix in kernel to re-enable vf list feature.
>
>Reviewed-by: Wei Zhao 
>
>> -Original Message-
>> From: dev  On Behalf Of Qi Zhang
>> Sent: Thursday, April 23, 2020 12:22 PM
>> To: Yang, Qiming 
>> Cc: Ye, Xiaolong ; Xing, Beilei 
>> ;
>> Zhang, Xiao ; dev@dpdk.org; Zhang, Qi Z
>> 
>> Subject: [dpdk-dev] [PATCH] net/ice/base: workaround for unexpected rule
>> deletion
>>
>> Ideally a rule with "TO VSI LIST" action should not be deleted when one of 
>> the
>> VF reset happens. The correct action by kernel PF driver is to remove the 
>> VSI of
>> a reset VF from the VSI list, but this is not implemented in kernel PF yet, 
>> so
>> workaround is the DCF to prevent a rule with "To VSI List" action happens.
>>
>> Signed-off-by: Qi Zhang 
>> ---
>>  drivers/net/ice/base/ice_switch.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/ice/base/ice_switch.c
>> b/drivers/net/ice/base/ice_switch.c
>> index 08999d336..b9fa516b0 100644
>> --- a/drivers/net/ice/base/ice_switch.c
>> +++ b/drivers/net/ice/base/ice_switch.c
>> @@ -6438,6 +6438,13 @@ ice_adv_add_update_vsi_list(struct ice_hw *hw,
>>   cur_fltr->sw_act.fltr_act == ICE_FWD_TO_VSI_LIST))
>>  return ICE_ERR_NOT_IMPL;
>>
>> +/* Workaround fix for unexpected rule deletion by kernel PF
>> + * during VF reset.
>> + */
>> +if (new_fltr->sw_act.fltr_act == ICE_FWD_TO_VSI &&
>> +cur_fltr->sw_act.fltr_act == ICE_FWD_TO_VSI)
>> +return ICE_ERR_NOT_IMPL;
>> +
>>  if (m_entry->vsi_count < 2 && !m_entry->vsi_list_info) {
>>   /* Only one entry existed in the mapping and it was not already
>>* a part of a VSI list. So, create a VSI list with the old and
>> --
>> 2.13.6
>

Applied to dpdk-next-net-intel, Thanks.

Re: [dpdk-dev] [dpdk-announce] release candidate 20.05-rc1

[Thomas Monjalon]

27/04/2020 01:40, Thomas Monjalon:
> We have four small weeks to complete this release cycle.
> DPDK 20.05-rc2 is expected on April 8th.

I received some feedbacks that some of you don't have any time machine.
That's unfortunate.
We have to postpone -rc2 target date to May 8th to accomodate everyone.

Re: [dpdk-dev] [PATCH v2 1/3] net/i40e: fix FDIR issue for ARP packets

[Xing, Beilei]

> -Original Message-
> From: Zhao1, Wei 
> Sent: Tuesday, April 28, 2020 1:48 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Xing, Beilei ;
> maxime.le...@6wind.com; Zhao1, Wei 
> Subject: [PATCH v2 1/3] net/i40e: fix FDIR issue for ARP packets
> 
> This patch can enable FDIR awith ethertype as input set for ARP packet, it 
> will
> associate this rule, "flow create 0 ingress pattern eth type is 0x0806 / end
> actions mark id 0x86 / rss / end", with pctype
> I40E_FILTER_PCTYPE_L2_PAYLOAD for ARP packet rule.
> I have tried to enable ARP ethertype for FDIR filter, it work well for ARP for
> FDIR filter, so delete the check.

How about 
'Currently, flow "pattern eth type is 0x0806 / end actions mark id 0x86 / rss / 
end" can't be created successfully. FDIR parser shouldn't deny 
RTE_ETHER_TYPE_ARP since ARP packets will be parsed as PCTYPE_L2_PAYLOAD.
This patch fixes the issue.' ?

> 
> Bugzilla ID: 402
> Fixes: 42044b69c67d ("net/i40e: support input set selection for FDIR")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Wei Zhao 
> ---
>  drivers/net/i40e/i40e_flow.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c index
> 7e64ae53a..1533d5abb 100644
> --- a/drivers/net/i40e/i40e_flow.c
> +++ b/drivers/net/i40e/i40e_flow.c
> @@ -2666,7 +2666,6 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev
> *dev,
>   if (next_type ==
> RTE_FLOW_ITEM_TYPE_VLAN ||
>   ether_type == RTE_ETHER_TYPE_IPV4 ||
>   ether_type == RTE_ETHER_TYPE_IPV6 ||
> - ether_type == RTE_ETHER_TYPE_ARP ||
>   ether_type == outer_tpid) {
>   rte_flow_error_set(error, EINVAL,
> 
> RTE_FLOW_ERROR_TYPE_ITEM,
> @@ -2711,7 +2710,6 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev
> *dev,
> 
>   if (ether_type == RTE_ETHER_TYPE_IPV4 ||
>   ether_type == RTE_ETHER_TYPE_IPV6 ||
> - ether_type == RTE_ETHER_TYPE_ARP ||
>   ether_type == outer_tpid) {
>   rte_flow_error_set(error, EINVAL,
> 
> RTE_FLOW_ERROR_TYPE_ITEM,
> --
> 2.19.1

Re: [dpdk-dev] [PATCH] net/tap: fix crash from unitialized memory in rte_flow_destroy

[David Marchand]

On Mon, Apr 27, 2020 at 11:39 PM Stephen Hemminger
 wrote:
>
> The TAP driver does not initialize all the elements of the rte_flow
> structure. This can lead to crash in rte_flow_destroy.
>
> (gdb) where
> flow=0x100e99280, error=0x0)
> at drivers/net/tap/tap_flow.c:1514
>
> (gdb) p remote_flow
> $1 = (struct rte_flow *) 0x6b6b6b6b6b6b6b6b
>
> Which is here:
> static int
> tap_flow_destroy_pmd(struct pmd_internals *pmd,
>  struct rte_flow *flow,
>  struct rte_flow_error *error)
> {
> struct rte_flow *remote_flow = flow->remote_flow;
> ...
> if (remote_flow) {
> remote_flow->msg.nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
>
> Simplest fix is to use rte_zmalloc() so remote_flow and other fields
> are always set at zero.
>
> Fixes: 2bc06869cd94 ("net/tap: add remote netdevice traffic capture")
> Cc: pascal.ma...@6wind.com

Not sure why you copied Pascal (I'd say he stopped working on dpdk 2 years ago).
Please use the devtools/get-maintainer.sh script.
Thanks.


-- 
David Marchand

Re: [dpdk-dev] [PATCH v2 3/3] net/i40e: remove teardown when flush FDIR filter

[Zhao1, Wei]

> -Original Message-
> From: Xing, Beilei 
> Sent: Tuesday, April 28, 2020 3:16 PM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: sta...@dpdk.org; maxime.le...@6wind.com
> Subject: RE: [PATCH v2 3/3] net/i40e: remove teardown when flush FDIR filter
> 
> Didn't address my comment in v1 patch.

Hi, 
 it has exist in unit.

> 
> > -Original Message-
> > From: Zhao1, Wei 
> > Sent: Tuesday, April 28, 2020 1:48 PM
> > To: dev@dpdk.org
> > Cc: sta...@dpdk.org; Xing, Beilei ;
> > maxime.le...@6wind.com; Zhao1, Wei 
> > Subject: [PATCH v2 3/3] net/i40e: remove teardown when flush FDIR
> > filter
> >
> > When we flush FDIR filter, we can not call i40e_fdir_teardown()
> > function as it will free vsi used for FDIR, then the vsi->base_queue
> > will be freed from pf-
> > >qp_pool, but vsi->base_queue can only get once when do dev init in
> > i40e_pf_setup(). If we free it, it will never be alloc again.
> >
> > Bugzilla ID: 404
> > Fixes: 2e67a7fbf3ff ("net/i40e: config flow director automatically")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Zhao 
> > ---
> >  drivers/net/i40e/i40e_flow.c | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/net/i40e/i40e_flow.c
> > b/drivers/net/i40e/i40e_flow.c index
> > 1533d5abb..65f877866 100644
> > --- a/drivers/net/i40e/i40e_flow.c
> > +++ b/drivers/net/i40e/i40e_flow.c
> > @@ -5145,7 +5145,6 @@ i40e_flow_destroy(struct rte_eth_dev *dev,
> >
> > /* If the last flow is destroyed, disable fdir. */
> > if (!ret && TAILQ_EMPTY(&pf->fdir.fdir_list)) {
> > -   i40e_fdir_teardown(pf);
> > i40e_fdir_rx_proc_enable(dev, 0);
> > }
> > break;
> > @@ -5343,8 +5342,6 @@ i40e_flow_flush_fdir_filter(struct i40e_pf *pf)
> > pf->fdir.inset_flag[pctype] = 0;
> > }
> >
> > -   i40e_fdir_teardown(pf);
> > -
> > return ret;
> >  }
> >
> > --
> > 2.19.1

Re: [dpdk-dev] [PATCH v2 1/3] net/i40e: fix FDIR issue for ARP packets

[Zhao1, Wei]

> -Original Message-
> From: Xing, Beilei 
> Sent: Tuesday, April 28, 2020 3:38 PM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: sta...@dpdk.org; maxime.le...@6wind.com
> Subject: RE: [PATCH v2 1/3] net/i40e: fix FDIR issue for ARP packets
> 
> 
> 
> > -Original Message-
> > From: Zhao1, Wei 
> > Sent: Tuesday, April 28, 2020 1:48 PM
> > To: dev@dpdk.org
> > Cc: sta...@dpdk.org; Xing, Beilei ;
> > maxime.le...@6wind.com; Zhao1, Wei 
> > Subject: [PATCH v2 1/3] net/i40e: fix FDIR issue for ARP packets
> >
> > This patch can enable FDIR awith ethertype as input set for ARP
> > packet, it will associate this rule, "flow create 0 ingress pattern
> > eth type is 0x0806 / end actions mark id 0x86 / rss / end", with
> > pctype I40E_FILTER_PCTYPE_L2_PAYLOAD for ARP packet rule.
> > I have tried to enable ARP ethertype for FDIR filter, it work well for
> > ARP for FDIR filter, so delete the check.
> 
> How about
> 'Currently, flow "pattern eth type is 0x0806 / end actions mark id 0x86 / rss 
> /
> end" can't be created successfully. FDIR parser shouldn't deny
> RTE_ETHER_TYPE_ARP since ARP packets will be parsed as
> PCTYPE_L2_PAYLOAD.
> This patch fixes the issue.' ?

Ok 

> 
> >
> > Bugzilla ID: 402
> > Fixes: 42044b69c67d ("net/i40e: support input set selection for FDIR")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Zhao 
> > ---
> >  drivers/net/i40e/i40e_flow.c | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/net/i40e/i40e_flow.c
> > b/drivers/net/i40e/i40e_flow.c index 7e64ae53a..1533d5abb 100644
> > --- a/drivers/net/i40e/i40e_flow.c
> > +++ b/drivers/net/i40e/i40e_flow.c
> > @@ -2666,7 +2666,6 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev
> > *dev,
> > if (next_type ==
> > RTE_FLOW_ITEM_TYPE_VLAN ||
> > ether_type == RTE_ETHER_TYPE_IPV4 ||
> > ether_type == RTE_ETHER_TYPE_IPV6 ||
> > -   ether_type == RTE_ETHER_TYPE_ARP ||
> > ether_type == outer_tpid) {
> > rte_flow_error_set(error, EINVAL,
> >
> > RTE_FLOW_ERROR_TYPE_ITEM,
> > @@ -2711,7 +2710,6 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev
> > *dev,
> >
> > if (ether_type == RTE_ETHER_TYPE_IPV4 ||
> > ether_type == RTE_ETHER_TYPE_IPV6 ||
> > -   ether_type == RTE_ETHER_TYPE_ARP ||
> > ether_type == outer_tpid) {
> > rte_flow_error_set(error, EINVAL,
> >
> > RTE_FLOW_ERROR_TYPE_ITEM,
> > --
> > 2.19.1

Re: [dpdk-dev] [PATCH] net/iavf: fix link speed

[Xing, Beilei]

> -Original Message-
> From: Zhang, AlvinX 
> Sent: Tuesday, April 28, 2020 2:49 PM
> To: dev@dpdk.org
> Cc: Zhang, Qi Z ; Xing, Beilei ;
> Zhang, AlvinX ; Wu, Jingjing
> 
> Subject: [PATCH] net/iavf: fix link speed
> 
> From: Alvin Zhang 
> 
> If the PF driver does not support the new speed reporting capabilities then
> use link_event else use link_event_adv to get the speed.
> 
> Fixes: 48de41ca11f0 (net/iavf: enable link status update)
> Cc: jingjing...@intel.com

Cc stable.

> 
> Signed-off-by: Alvin Zhang 
> ---
>  drivers/net/iavf/iavf_vchnl.c | 47
> ++-
>  1 file changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c 
> index
> 2a0cdd9..104a769 100644
> --- a/drivers/net/iavf/iavf_vchnl.c
> +++ b/drivers/net/iavf/iavf_vchnl.c
> @@ -130,6 +130,44 @@
>   return err;
>  }
> 
> +static uint32_t
> +iavf_convert_link_speed(uint32_t virt_link_speed) {

Why use uint32_t but not enum virtchnl_link_speed for the parameter?

> + uint32_t speed;
> +
> + switch (virt_link_speed) {
> + case VIRTCHNL_LINK_SPEED_100MB:
> + speed = 100;
> + break;
> + case VIRTCHNL_LINK_SPEED_1GB:
> + speed = 1000;
> + break;
> + case VIRTCHNL_LINK_SPEED_10GB:
> + speed = 1;
> + break;
> + case VIRTCHNL_LINK_SPEED_40GB:
> + speed = 4;
> + break;
> + case VIRTCHNL_LINK_SPEED_20GB:
> + speed = 2;
> + break;
> + case VIRTCHNL_LINK_SPEED_25GB:
> + speed = 25000;
> + break;
> + case VIRTCHNL_LINK_SPEED_2_5GB:
> + speed = 2500;
> + break;
> + case VIRTCHNL_LINK_SPEED_5GB:
> + speed = 5000;
> + break;
> + default:
> + speed = 0;
> + break;
> + }
> +
> + return speed;
> +}
> +
>  static void
>  iavf_handle_pf_event_msg(struct rte_eth_dev *dev, uint8_t *msg,
>   uint16_t msglen)
> @@ -151,7 +189,14 @@
>   case VIRTCHNL_EVENT_LINK_CHANGE:
>   PMD_DRV_LOG(DEBUG, "VIRTCHNL_EVENT_LINK_CHANGE
> event");
>   vf->link_up = pf_msg->event_data.link_event.link_status;
> - vf->link_speed = pf_msg-
> >event_data.link_event_adv.link_speed;
> + if (vf->vf_res->vf_cap_flags &
> VIRTCHNL_VF_CAP_ADV_LINK_SPEED) {
> + vf->link_speed =
> + pf_msg-
> >event_data.link_event_adv.link_speed;
> + } else {
> + enum virtchnl_link_speed speed;
> + speed = pf_msg->event_data.link_event.link_speed;
> + vf->link_speed = iavf_convert_link_speed(speed);
> + }
>   iavf_dev_link_update(dev, 0);
>   _rte_eth_dev_callback_process(dev,
> RTE_ETH_EVENT_INTR_LSC,
> NULL);
> --
> 1.8.3.1

Re: [dpdk-dev] [PATCH] rte_trace: fix build on PPC64

[Jerin Jacob]

On Tue, Apr 28, 2020 at 3:29 AM Thinh Tran  wrote:
>
> The AltiVec header file breaks boolean type:
>
> In file included from ../lib/librte_mempool/rte_mempool_trace_fp.h:18:0,
>  from ../lib/librte_mempool/rte_mempool.h:54,
>  from ../lib/librte_mbuf/rte_mbuf.h:38,
>  from ../lib/librte_net/rte_ether.h:23,
>  from ../drivers/common/mlx5/mlx5_nl.h:10,
>  from ../drivers/common/mlx5/mlx5_nl.c:23:
> ../lib/librte_eal/include/rte_trace_point.h: In function
> ‘__rte_trace_point_fp_is_enabled’:
> ../lib/librte_eal/include/rte_trace_point.h:226:9: error: incompatible
> types when returning type ‘int’ but ‘__vector __bool int {aka
> __vector(4) __bool int}’ was expected
>   return false;
>
> This is the same as
>  https://git.dpdk.org/dpdk/commit/?id=725f5dd
>
> and yet, there is no better solution for it
>
> Signed-off-by: Thinh Tran 
> ---
>  lib/librte_eal/include/rte_trace_point.h | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/lib/librte_eal/include/rte_trace_point.h 
> b/lib/librte_eal/include/rte_trace_point.h
> index 4d956ec16..2ede9e3ba 100644
> --- a/lib/librte_eal/include/rte_trace_point.h
> +++ b/lib/librte_eal/include/rte_trace_point.h
> @@ -26,6 +26,12 @@ extern "C" {
>  #include 
>  #include 
>
> +#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__)
> +#undef bool
> +/* redefine as in stdbool.h */
> +#define bool _Bool
> +#endif

NACK.

Please move the fix to rte_common.h or similar as it not specific to trace.
if you do so, the following hack also not need.
https://git.dpdk.org/dpdk/commit/?id=725f5dd

> +
>  /** The tracepoint object. */
>  typedef uint64_t rte_trace_point_t;
>
> --
> 2.17.1
>

[dpdk-dev] [PATCH] eal/ppc: fix redefine bool type

[Ori Kam]

The AltiVec header file breaks boolean type. [1] [2]

Currently the workaround was located only in mlx5 device.
Adding the trace module caused this issue to appear again, due to
order of includes, it keeps overriding the local fix.

This patch solves this issue by resetting the bool type, immediately
after it is being changed.

[1] https://mails.dpdk.org/archives/dev/2018-August/110281.html

[2]
In file included from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:18:0,
 from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool.h:54,
 from
dpdk/drivers/common/mlx5/mlx5_common_mr.c:7:
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h: In
function '__rte_trace_point_fp_is_enabled':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:226:2:
error: incompatible types when returning type 'int' but '__vector __bool
int' was expected
  return false;
  ^
In file included from
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:281:0,
 from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:18,
 from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool.h:54,
 from
dpdk/drivers/common/mlx5/mlx5_common_mr.c:7:
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_dequeue_bulk':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
  if (!__rte_trace_point_fp_is_enabled()) \
  ^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:49:2:
note: in expansion of macro '__rte_trace_point_emit_header_fp'
  __rte_trace_point_emit_header_##_mode(&__##_tp); \
  ^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:99:2:
note: in expansion of macro '__RTE_TRACE_POINT'
  __RTE_TRACE_POINT(fp, tp, args, __VA_ARGS__)
  ^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:20:1:
note: in expansion of macro 'RTE_TRACE_POINT_FP'
 RTE_TRACE_POINT_FP(
 ^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_dequeue_contig_blocks':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
  if (!__rte_trace_point_fp_is_enabled()) \
  ^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:49:2:
note: in expansion of macro '__rte_trace_point_emit_header_fp'
  __rte_trace_point_emit_header_##_mode(&__##_tp); \
  ^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:99:2:
note: in expansion of macro '__RTE_TRACE_POINT'
  __RTE_TRACE_POINT(fp, tp, args, __VA_ARGS__)
  ^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:29:1:
note: in expansion of macro 'RTE_TRACE_POINT_FP'
 RTE_TRACE_POINT_FP(
 ^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_enqueue_bulk':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
  if (!__rte_trace_point_fp_is_enabled()) \

Fixes: 725f5dd0bfb5 ("net/mlx5: fix build on PPC64")

Signed-off-by: Ori Kam 
---
 drivers/common/mlx5/mlx5_common.h| 10 --
 drivers/net/mlx5/mlx5_utils.h| 10 --
 lib/librte_eal/ppc/include/meson.build   |  1 +
 lib/librte_eal/ppc/include/rte_altivec.h | 22 ++
 lib/librte_eal/ppc/include/rte_memcpy.h  |  3 +--
 5 files changed, 24 insertions(+), 22 deletions(-)
 create mode 100644 lib/librte_eal/ppc/include/rte_altivec.h

diff --git a/drivers/common/mlx5/mlx5_common.h 
b/drivers/common/mlx5/mlx5_common.h
index 16de1b3..c2d688a 100644
--- a/drivers/common/mlx5/mlx5_common.h
+++ b/drivers/common/mlx5/mlx5_common.h
@@ -17,16 +17,6 @@
 #include "mlx5_prm.h"
 
 
-/*
- * Compilation workaround for PPC64 when AltiVec is fully enabled, e.g. 
std=c11.
- * Otherwise there would be a type conflict between stdbool and altivec.
- */
-#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__)
-#undef bool
-/* redefine as in stdbool.h */
-#define bool _Bool
-#endif
-
 /* Bit-field manipulation. */
 #define BITFIELD_DECLARE(bf, type, size) \
type bf[(((size_t)(size) / (sizeof(type) * CHAR_BIT)) + \
diff --git a/drivers/net/mlx5/mlx5_utils.h b/drivers/net/mlx5/mlx5_utils.h
index d81ace3..0e016f8 100644
--- a/drivers/net/mlx5/mlx5_utils.h
+++ b/drivers/net/mlx5/mlx5_utils.h
@@ -21,16 +21,6 @@
 #include "mlx5_defs.h"
 
 
-/*
- * Compilation workaround for PPC64 when AltiVec is fully enabled, e.g. 
std=c11.
- * Otherwise there would be a type conflict between stdbool and altivec.
- */
-#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__)
-#undef bool
-/* redefine as in stdbool.h */
-#define bool _Bool
-#endif
-
 /* Convert a bit number to the corresponding 64-bit mask */
 #define MLX5_BITSHIFT(v) (UINT64_C(1) << (v))
 
diff --git a/lib/librte_eal/ppc/include/meson.build 
b/lib/librte_eal/ppc/include/meson.build
index 3a91c98..3ee38f6 100644
--- a/lib/librte_eal/ppc/include/meson.bui

[dpdk-dev] [PATCH v3 2/3] doc: input set requirement of each pctype for FDIR

[Wei Zhao]

Add input set requirement info to i40e doc.

Bugzilla ID: 403
Signed-off-by: Wei Zhao 
---
 doc/guides/nics/i40e.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 416b3904e..ad5f51c38 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -747,6 +747,13 @@ Use 16 Bytes RX Descriptor Size
 As i40e PMD supports both 16 and 32 bytes RX descriptor sizes, and 16 bytes 
size can provide helps to high performance of small packets.
 Configuration of ``CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC`` in config files can 
be changed to use 16 bytes size RX descriptors.
 
+input set requirement of each pctype for FDIR
+
+
+Each pctype packet can only have one specific input set for FDIR, for example 
if you download 2 rte_flow rules of different input set for one specific pctype,
+it is will fail and return the info "Conflict with the first rule's input 
set", that means the first type of input set conflict with the current one,
+this limitaition is required by hardware.
+
 Example of getting best performance with l3fwd example
 --
 
-- 
2.19.1

[dpdk-dev] [PATCH v3 0/3] fix i40e bug for flow filter

[Wei Zhao]

fix i40e bug for flow filter and add comment in doc. 

v2:
add more comment in git log.

v3:
update git log.

Wei Zhao (3):
  net/i40e: fix FDIR issue for ARP packets
  doc: input set requirement of each pctype for FDIR
  net/i40e: remove teardown when flush FDIR filter

 doc/guides/nics/i40e.rst | 7 +++
 drivers/net/i40e/i40e_flow.c | 5 -
 2 files changed, 7 insertions(+), 5 deletions(-)

-- 
2.19.1

[dpdk-dev] [PATCH v3 3/3] net/i40e: remove teardown when flush FDIR filter

[Wei Zhao]

When we flush FDIR filter, we can not call i40e_fdir_teardown()
function as it will free vsi used for FDIR, then the vsi->base_queue
will be freed from pf->qp_pool, but vsi->base_queue can only get
once when do dev init in i40e_pf_setup(). If we free it, it will
never be alloc again.

Bugzilla ID: 404
Fixes: 2e67a7fbf3ff ("net/i40e: config flow director automatically")
Cc: sta...@dpdk.org

Signed-off-by: Wei Zhao 
---
 drivers/net/i40e/i40e_flow.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c
index 1533d5abb..65f877866 100644
--- a/drivers/net/i40e/i40e_flow.c
+++ b/drivers/net/i40e/i40e_flow.c
@@ -5145,7 +5145,6 @@ i40e_flow_destroy(struct rte_eth_dev *dev,
 
/* If the last flow is destroyed, disable fdir. */
if (!ret && TAILQ_EMPTY(&pf->fdir.fdir_list)) {
-   i40e_fdir_teardown(pf);
i40e_fdir_rx_proc_enable(dev, 0);
}
break;
@@ -5343,8 +5342,6 @@ i40e_flow_flush_fdir_filter(struct i40e_pf *pf)
pf->fdir.inset_flag[pctype] = 0;
}
 
-   i40e_fdir_teardown(pf);
-
return ret;
 }
 
-- 
2.19.1

[dpdk-dev] [PATCH v3 1/3] net/i40e: fix FDIR issue for ARP packets

[Wei Zhao]

Currently, flow "pattern eth type is 0x0806 / end actions mark id
0x86 / rss / end" can't be created successfully. FDIR parser
shouldn't deny RTE_ETHER_TYPE_ARP since ARP packets will be
parsed as PCTYPE_L2_PAYLOAD. This patch fixes the issue.

Bugzilla ID: 402
Fixes: 42044b69c67d ("net/i40e: support input set selection for FDIR")
Cc: sta...@dpdk.org

Signed-off-by: Wei Zhao 
---
 drivers/net/i40e/i40e_flow.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c
index 7e64ae53a..1533d5abb 100644
--- a/drivers/net/i40e/i40e_flow.c
+++ b/drivers/net/i40e/i40e_flow.c
@@ -2666,7 +2666,6 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
if (next_type == RTE_FLOW_ITEM_TYPE_VLAN ||
ether_type == RTE_ETHER_TYPE_IPV4 ||
ether_type == RTE_ETHER_TYPE_IPV6 ||
-   ether_type == RTE_ETHER_TYPE_ARP ||
ether_type == outer_tpid) {
rte_flow_error_set(error, EINVAL,
 RTE_FLOW_ERROR_TYPE_ITEM,
@@ -2711,7 +2710,6 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
 
if (ether_type == RTE_ETHER_TYPE_IPV4 ||
ether_type == RTE_ETHER_TYPE_IPV6 ||
-   ether_type == RTE_ETHER_TYPE_ARP ||
ether_type == outer_tpid) {
rte_flow_error_set(error, EINVAL,
 RTE_FLOW_ERROR_TYPE_ITEM,
-- 
2.19.1

Re: [dpdk-dev] [PATCH] net/mlx5: save meter index instead of meter id

[Slava Ovsiienko]

> -Original Message-
> From: Suanming Mou 
> Sent: Sunday, April 26, 2020 5:51
> To: Matan Azrad ; Shahaf Shuler
> ; Slava Ovsiienko 
> Cc: dev@dpdk.org; Raslan Darawsheh 
> Subject: [PATCH] net/mlx5: save meter index instead of meter id
> 
> Currently, while creating the flow with meter, meter id is saved to the rte
> flow. While destroying the flow, the meter object will be found by the meter
> id, so the meter object will be released accordingly. But as the meter id is
> configured by user, while the meter id is set to 0, it doesn't make any sense
> to flow destroy since 0 means flow doesn't have meter. The meter object
> with id 0 will be leaked.
> 
> As meter object is allocated from indexed memory, and the index starts from
> 1, save the internal generated index instead of user defined meter id will
> never meet the issue as above.
> 
> This patch saves meter index instead of meter id in rte flow.
> 
> Signed-off-by: Suanming Mou 
Acked-by: Viacheslav Ovsiienko 

> ---
>  drivers/net/mlx5/mlx5_flow_dv.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 6263ecc..2fdd403 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -7867,11 +7867,12 @@ struct field_modify_info modify_tcp[] = {
>   NULL,
>   "meter not found "
>   "or invalid parameters");
> - flow->meter = fm->meter_id;
> + flow->meter = fm->idx;
>   }
>   /* Set the meter action. */
>   if (!fm) {
> - fm = mlx5_flow_meter_find(priv, flow-
> >meter);
> + fm = mlx5_ipool_get(priv->sh->ipool
> + [MLX5_IPOOL_MTR], flow-
> >meter);
>   if (!fm)
>   return rte_flow_error_set(error,
>   rte_errno,
> @@ -8591,7 +8592,8 @@ struct field_modify_info modify_tcp[] = {
>   if (flow->meter) {
>   struct mlx5_flow_meter *fm;
> 
> - fm  = mlx5_flow_meter_find(priv, flow->meter);
> + fm = mlx5_ipool_get(priv->sh->ipool[MLX5_IPOOL_MTR],
> + flow->meter);
>   if (fm)
>   mlx5_flow_meter_detach(fm);
>   flow->meter = 0;
> --
> 1.8.3.1

Re: [dpdk-dev] [PATCH 7/7] bus/pci: support Windows with bifurcated drivers

[Tal Shnaiderman]

> Subject: Re: [dpdk-dev] [PATCH 7/7] bus/pci: support Windows with
> bifurcated drivers
> 
> On Wed, Apr 22, 2020 at 10:27:47AM +0300, tal...@mellanox.com wrote:
> > From: Tal Shnaiderman 
> >
> > Uses SetupAPI.h functions to scan PCI tree.
> > Uses DEVPKEY_Device_Numa_Node to get the PCI Numa node.
> > scanning currently supports types RTE_KDRV_NONE.
> >
> > Signed-off-by: Tal Shnaiderman 
> > ---
> >  drivers/bus/pci/windows/pci.c| 342
> ++-
> >  lib/librte_eal/rte_eal_exports.def   |   1 +
> >  lib/librte_eal/windows/include/rte_windows.h |   1 +
> >  3 files changed, 342 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/bus/pci/windows/pci.c
> > b/drivers/bus/pci/windows/pci.c index 7eff39173..d5ee938fa 100644
> > --- a/drivers/bus/pci/windows/pci.c
> > +++ b/drivers/bus/pci/windows/pci.c
> > @@ -1,14 +1,24 @@
> >  /* SPDX-License-Identifier: BSD-3-Clause
> >   * Copyright 2020 Mellanox Technologies, Ltd
> >   */
> > +
> > +static
> > +int get_device_resource_info(HDEVINFO hDevInfo,
> > +   PSP_DEVINFO_DATA pDeviceInfoData , struct rte_pci_device *dev) {
> > +   int  ret = -1;
> > +   DEVPROPTYPE uPropertyType;
> > +   DWORD uNumaNode;
> > +   BOOL  bResult;
> > +
> > +   switch (dev->kdrv) {
> > +   case RTE_KDRV_NONE:
> > +   /* Get NUMA node using DEVPKEY_Device_Numa_Node */
> > +   bResult = SetupDiGetDevicePropertyW(hDevInfo,
> pDeviceInfoData,
> > +   &DEVPKEY_Device_Numa_Node, &uPropertyType,
> > +   (BYTE *)&uNumaNode, sizeof(uNumaNode), NULL,
> 0);
> > +   if (!bResult) {
> > +   ret = GetLastError();
> > +   break;
> 
> Here 'ret' is correctly set to an error code, but after breaking out of the
> switch, it is overwritten to ERROR_SUCCESS.
> Maybe 'goto end' instead of 'break'.
> 
> > +   }
> > +   dev->device.numa_node = uNumaNode;
> > +   /* mem_resource - Uneeded for RTE_KDRV_NONE */
> > +   dev->mem_resource[0].phys_addr = 0;
> > +   dev->mem_resource[0].len = 0;
> > +   dev->mem_resource[0].addr = NULL;
> > +   break;
> > +   default:
> > +   ret = -1;
> 
> Same thing here, ret is overwritten after breaking from the switch.

Agreed, I'll fix both in v2, thank you.

> 
> > +   break;
> > +   }
> > +
> > +   ret = ERROR_SUCCESS;
> > +end:
> > +   return ret;
> > +}
> > +
> > +
> > +/*

Re: [dpdk-dev] [PATCH 1/5] app/test-flow-perf: add flow performance skeleton

[Wisam Monther]

Thanks Jack,

Jerin,
Can you please review it according to our discussion in the RFC?

>-Original Message-
>From: Jack Min 
>Sent: Friday, April 17, 2020 5:06 AM
>To: Wisam Monther 
>Cc: dev@dpdk.org; jerinjac...@gmail.com; Thomas Monjalon
>
>Subject: Re: [dpdk-dev] [PATCH 1/5] app/test-flow-perf: add flow
>performance skeleton
>
>On Thu, 20-04-16, 23:12, Wisam Monther wrote:
>>
>>
>> >-Original Message-
>> >From: dev  On Behalf Of Wisam Jaddo
>> >Sent: Thursday, April 9, 2020 6:43 PM
>> >To: dev@dpdk.org; Jack Min ;
>> >jerinjac...@gmail.com
>> >Cc: Thomas Monjalon 
>> >Subject: [dpdk-dev] [PATCH 1/5] app/test-flow-perf: add flow
>> >performance skeleton
>> >
>> >Add flow performance application skeleton.
>> >
>> >Signed-off-by: Wisam Jaddo 
>Reviewed-by: Xiaoyu Min 

Re: [dpdk-dev] [PATCH 3/5] app/test-flow-perf: add deletion rate calculation

[Wisam Monther]

Thanks Jack,

Jerin,
Can you please review it according to our discussion in the RFC?

>-Original Message-
>From: Jack Min 
>Sent: Friday, April 17, 2020 5:08 AM
>To: Wisam Monther 
>Cc: dev@dpdk.org; jerinjac...@gmail.com; Thomas Monjalon
>
>Subject: Re: [PATCH 3/5] app/test-flow-perf: add deletion rate calculation
>
>On Thu, 20-04-09, 15:42, Wisam Jaddo wrote:
>> Add the ability to test deletion rate for flow performance
>> application.
>>
>> This feature is disabled by default, and can be enabled by add
>> "--deletion-rate" in the application command line options.
>>
>> Signed-off-by: Wisam Jaddo 
>Reviewed-by: Xiaoyu Min 

Re: [dpdk-dev] [PATCH 2/5] app/test-flow-perf: add insertion rate calculation

[Wisam Monther]

Thanks Jack,

Jerin,
Can you please review it according to our discussion in the RFC?

>-Original Message-
>From: Jack Min 
>Sent: Friday, April 17, 2020 5:07 AM
>To: Wisam Monther 
>Cc: dev@dpdk.org; jerinjac...@gmail.com; Thomas Monjalon
>
>Subject: Re: [PATCH 2/5] app/test-flow-perf: add insertion rate calculation
>
>On Thu, 20-04-09, 15:42, Wisam Jaddo wrote:
>> Add insertion rate calculation feature into flow performance
>> application.
>>
>> The application now provide the ability to test insertion rate of
>> specific rte_flow rule, by stressing it to the NIC, and calculate the
>> insertion rate.
>>
>> The application offers some options in the command line, to configure
>> which rule to apply.
>>
>> After that the application will start producing rules with same
>> pattern but increasing the outer IP source address by 1 each time,
>> thus it will give different flow each time, and all other items will
>> have open masks.
>>
>> The current design have single core insertion rate.
>> In the future we may have a multi core insertion rate measurement
>> support in the app.
>>
>> Signed-off-by: Wisam Jaddo 
>Reviewed-by: Xiaoyu Min 

Re: [dpdk-dev] [PATCH 4/5] app/test-flow-perf: add memory dump to app

[Wisam Monther]

Thanks Jack,

Jerin,
Can you please review it according to our discussion in the RFC?

>-Original Message-
>From: Jack Min 
>Sent: Friday, April 17, 2020 5:09 AM
>To: Wisam Monther 
>Cc: dev@dpdk.org; jerinjac...@gmail.com; Thomas Monjalon
>; Suanming Mou 
>Subject: Re: [PATCH 4/5] app/test-flow-perf: add memory dump to app
>
>On Thu, 20-04-09, 15:42, Wisam Jaddo wrote:
>> Introduce new feature to dump memory statistics of each socket and a
>> total for all before and after the creation.
>>
>> This will give two main advantage:
>> 1- Check the memory consumption for large number of flows "insertion
>> rate scenario alone"
>>
>> 2- Check that no memory leackage after doing insertion then deletion.
>>
>> Signed-off-by: Suanming Mou 
>> Signed-off-by: Wisam Jaddo 
>Reviewed-by: Xiaoyu Min 

Re: [dpdk-dev] [PATCH 5/5] app/test-flow-perf: add packet forwarding support

[Wisam Monther]

Thanks Jack,

Jerin,
Can you please review it according to our discussion in the RFC?

>-Original Message-
>From: Jack Min 
>Sent: Friday, April 17, 2020 5:09 AM
>To: Wisam Monther 
>Cc: dev@dpdk.org; jerinjac...@gmail.com; Thomas Monjalon
>
>Subject: Re: [PATCH 5/5] app/test-flow-perf: add packet forwarding support
>
>On Thu, 20-04-09, 15:42, Wisam Jaddo wrote:
>> Introduce packet forwarding support to the app to do some performance
>> measurements.
>>
>> The measurements are reported in term of packet per second unit. The
>> forwarding will start after the end of insertion/deletion operations.
>>
>> The support has single and multi performance measurements.
>>
>> Signed-off-by: Wisam Jaddo 
>Reviewed-by: Xiaoyu Min 

[dpdk-dev] [PATCH v11 0/9] add packed ring vectorized path

[Marvin Liu]

This patch set introduced vectorized path for packed ring.

The size of packed ring descriptor is 16Bytes. Four batched descriptors
are just placed into one cacheline. AVX512 instructions can well handle
this kind of data. Packed ring TX path can fully transformed into
vectorized path. Packed ring Rx path can be vectorized when requirements
met(LRO and mergeable disabled).

New option RTE_LIBRTE_VIRTIO_INC_VECTOR will be introduced in this
patch set. This option will unify split and packed ring vectorized
path default setting. Meanwhile user can specify whether enable
vectorized path at runtime by 'vectorized' parameter of virtio user
vdev.

v11:
* fix i686 build warnings
* fix typo in doc

v10:
* reuse packed ring xmit cleanup

v9:
* replace RTE_LIBRTE_VIRTIO_INC_VECTOR with vectorized devarg
* reorder patch sequence

v8:
* fix meson build error on ubuntu16.04 and suse15

v7:
* default vectorization is disabled
* compilation time check dependency on rte_mbuf structure
* offsets are calcuated when compiling
* remove useless barrier as descs are batched store&load
* vindex of scatter is directly set
* some comments updates
* enable vectorized path in meson build

v6:
* fix issue when size not power of 2

v5:
* remove cpuflags definition as required extensions always come with
  AVX512F on x86_64
* inorder actions should depend on feature bit
* check ring type in rx queue setup
* rewrite some commit logs
* fix some checkpatch warnings

v4:
* rename 'packed_vec' to 'vectorized', also used in split ring
* add RTE_LIBRTE_VIRTIO_INC_VECTOR config for virtio ethdev
* check required AVX512 extensions cpuflags
* combine split and packed ring datapath selection logic
* remove limitation that size must power of two
* clear 12Bytes virtio_net_hdr

v3:
* remove virtio_net_hdr array for better performance
* disable 'packed_vec' by default

v2:
* more function blocks replaced by vector instructions
* clean virtio_net_hdr by vector instruction
* allow header room size change
* add 'packed_vec' option in virtio_user vdev 
* fix build not check whether AVX512 enabled
* doc update

Tested-by: Wang, Yinan 

Marvin Liu (9):
  net/virtio: add Rx free threshold setting
  net/virtio: inorder should depend on feature bit
  net/virtio: add vectorized devarg
  net/virtio-user: add vectorized devarg
  net/virtio: reuse packed ring functions
  net/virtio: add vectorized packed ring Rx path
  net/virtio: add vectorized packed ring Tx path
  net/virtio: add election for vectorized path
  doc: add packed vectorized path

 doc/guides/nics/virtio.rst  |  52 +-
 drivers/net/virtio/Makefile |  35 ++
 drivers/net/virtio/meson.build  |  14 +
 drivers/net/virtio/virtio_ethdev.c  | 137 -
 drivers/net/virtio/virtio_ethdev.h  |   6 +
 drivers/net/virtio/virtio_pci.h |   3 +-
 drivers/net/virtio/virtio_rxtx.c| 349 ++-
 drivers/net/virtio/virtio_rxtx_packed_avx.c | 623 
 drivers/net/virtio/virtio_user_ethdev.c |  32 +-
 drivers/net/virtio/virtqueue.c  |   7 +-
 drivers/net/virtio/virtqueue.h  | 307 +-
 11 files changed, 1210 insertions(+), 355 deletions(-)
 create mode 100644 drivers/net/virtio/virtio_rxtx_packed_avx.c

-- 
2.17.1

[dpdk-dev] [PATCH v11 1/9] net/virtio: add Rx free threshold setting

[Marvin Liu]

Introduce free threshold setting in Rx queue, its default value is 32.
Limit the threshold size to multiple of four as only vectorized packed
Rx function will utilize it. Virtio driver will rearm Rx queue when
more than rx_free_thresh descs were dequeued.

Signed-off-by: Marvin Liu 
Reviewed-by: Maxime Coquelin 

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 060410577..94ba7a3ec 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -936,6 +936,7 @@ virtio_dev_rx_queue_setup(struct rte_eth_dev *dev,
struct virtio_hw *hw = dev->data->dev_private;
struct virtqueue *vq = hw->vqs[vtpci_queue_idx];
struct virtnet_rx *rxvq;
+   uint16_t rx_free_thresh;
 
PMD_INIT_FUNC_TRACE();
 
@@ -944,6 +945,28 @@ virtio_dev_rx_queue_setup(struct rte_eth_dev *dev,
return -EINVAL;
}
 
+   rx_free_thresh = rx_conf->rx_free_thresh;
+   if (rx_free_thresh == 0)
+   rx_free_thresh =
+   RTE_MIN(vq->vq_nentries / 4, DEFAULT_RX_FREE_THRESH);
+
+   if (rx_free_thresh & 0x3) {
+   RTE_LOG(ERR, PMD, "rx_free_thresh must be multiples of four."
+   " (rx_free_thresh=%u port=%u queue=%u)\n",
+   rx_free_thresh, dev->data->port_id, queue_idx);
+   return -EINVAL;
+   }
+
+   if (rx_free_thresh >= vq->vq_nentries) {
+   RTE_LOG(ERR, PMD, "rx_free_thresh must be less than the "
+   "number of RX entries (%u)."
+   " (rx_free_thresh=%u port=%u queue=%u)\n",
+   vq->vq_nentries,
+   rx_free_thresh, dev->data->port_id, queue_idx);
+   return -EINVAL;
+   }
+   vq->vq_free_thresh = rx_free_thresh;
+
if (nb_desc == 0 || nb_desc > vq->vq_nentries)
nb_desc = vq->vq_nentries;
vq->vq_free_cnt = RTE_MIN(vq->vq_free_cnt, nb_desc);
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 58ad7309a..6301c56b2 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -18,6 +18,8 @@
 
 struct rte_mbuf;
 
+#define DEFAULT_RX_FREE_THRESH 32
+
 /*
  * Per virtio_ring.h in Linux.
  * For virtio_pci on SMP, we don't need to order with respect to MMIO
-- 
2.17.1

[dpdk-dev] [PATCH v11 2/9] net/virtio: inorder should depend on feature bit

[Marvin Liu]

Ring initialization is different when inorder feature negotiated. This
action should dependent on negotiated feature bits.

Signed-off-by: Marvin Liu 
Reviewed-by: Maxime Coquelin 

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 94ba7a3ec..e450477e8 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -989,6 +989,7 @@ virtio_dev_rx_queue_setup_finish(struct rte_eth_dev *dev, 
uint16_t queue_idx)
struct rte_mbuf *m;
uint16_t desc_idx;
int error, nbufs, i;
+   bool in_order = vtpci_with_feature(hw, VIRTIO_F_IN_ORDER);
 
PMD_INIT_FUNC_TRACE();
 
@@ -1018,7 +1019,7 @@ virtio_dev_rx_queue_setup_finish(struct rte_eth_dev *dev, 
uint16_t queue_idx)
virtio_rxq_rearm_vec(rxvq);
nbufs += RTE_VIRTIO_VPMD_RX_REARM_THRESH;
}
-   } else if (hw->use_inorder_rx) {
+   } else if (!vtpci_packed_queue(vq->hw) && in_order) {
if ((!virtqueue_full(vq))) {
uint16_t free_cnt = vq->vq_free_cnt;
struct rte_mbuf *pkts[free_cnt];
@@ -1133,7 +1134,7 @@ virtio_dev_tx_queue_setup_finish(struct rte_eth_dev *dev,
PMD_INIT_FUNC_TRACE();
 
if (!vtpci_packed_queue(hw)) {
-   if (hw->use_inorder_tx)
+   if (vtpci_with_feature(hw, VIRTIO_F_IN_ORDER))
vq->vq_split.ring.desc[vq->vq_nentries - 1].next = 0;
}
 
@@ -2046,7 +2047,7 @@ virtio_xmit_pkts_packed(void *tx_queue, struct rte_mbuf 
**tx_pkts,
struct virtio_hw *hw = vq->hw;
uint16_t hdr_size = hw->vtnet_hdr_size;
uint16_t nb_tx = 0;
-   bool in_order = hw->use_inorder_tx;
+   bool in_order = vtpci_with_feature(hw, VIRTIO_F_IN_ORDER);
 
if (unlikely(hw->started == 0 && tx_pkts != hw->inject_pkts))
return nb_tx;
-- 
2.17.1

[dpdk-dev] [PATCH v11 4/9] net/virtio-user: add vectorized devarg

[Marvin Liu]

Add new devarg for virtio user device vectorized path selection. By
default vectorized path is disabled.

Signed-off-by: Marvin Liu 
Reviewed-by: Maxime Coquelin 

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index a67774e91..fdd0790e0 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -424,6 +424,12 @@ Below devargs are supported by the virtio-user vdev:
 rte_eth_link_get_nowait function.
 (Default: 1 (10G))
 
+#.  ``vectorized``:
+
+It is used to specify whether virtio device perfers to use vectorized path.
+Afterwards, dependencies of vectorized path will be checked in path
+election.
+(Default: 0 (disabled))
 
 Virtio paths Selection and Usage
 
diff --git a/drivers/net/virtio/virtio_user_ethdev.c 
b/drivers/net/virtio/virtio_user_ethdev.c
index 150a8d987..40ad786cc 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -452,6 +452,8 @@ static const char *valid_args[] = {
VIRTIO_USER_ARG_PACKED_VQ,
 #define VIRTIO_USER_ARG_SPEED  "speed"
VIRTIO_USER_ARG_SPEED,
+#define VIRTIO_USER_ARG_VECTORIZED "vectorized"
+   VIRTIO_USER_ARG_VECTORIZED,
NULL
 };
 
@@ -559,6 +561,7 @@ virtio_user_pmd_probe(struct rte_vdev_device *dev)
uint64_t mrg_rxbuf = 1;
uint64_t in_order = 1;
uint64_t packed_vq = 0;
+   uint64_t vectorized = 0;
char *path = NULL;
char *ifname = NULL;
char *mac_addr = NULL;
@@ -675,6 +678,15 @@ virtio_user_pmd_probe(struct rte_vdev_device *dev)
}
}
 
+   if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_VECTORIZED) == 1) {
+   if (rte_kvargs_process(kvlist, VIRTIO_USER_ARG_VECTORIZED,
+  &get_integer_arg, &vectorized) < 0) {
+   PMD_INIT_LOG(ERR, "error to parse %s",
+VIRTIO_USER_ARG_VECTORIZED);
+   goto end;
+   }
+   }
+
if (queues > 1 && cq == 0) {
PMD_INIT_LOG(ERR, "multi-q requires ctrl-q");
goto end;
@@ -727,6 +739,9 @@ virtio_user_pmd_probe(struct rte_vdev_device *dev)
goto end;
}
 
+   if (vectorized)
+   hw->use_vec_rx = 1;
+
rte_eth_dev_probing_finish(eth_dev);
ret = 0;
 
@@ -785,4 +800,5 @@ RTE_PMD_REGISTER_PARAM_STRING(net_virtio_user,
"mrg_rxbuf=<0|1> "
"in_order=<0|1> "
"packed_vq=<0|1> "
-   "speed=");
+   "speed= "
+   "vectorized=<0|1>");
-- 
2.17.1

[dpdk-dev] [PATCH v11 3/9] net/virtio: add vectorized devarg

[Marvin Liu]

Previously, virtio split ring vectorized path was enabled by default.
This is not suitable for everyone because that path dose not follow
virtio spec. Add new devarg for virtio vectorized path selection. By
default vectorized path is disabled.

Signed-off-by: Marvin Liu 
Reviewed-by: Maxime Coquelin 

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index 6286286db..a67774e91 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -363,6 +363,13 @@ Below devargs are supported by the PCI virtio driver:
 rte_eth_link_get_nowait function.
 (Default: 1 (10G))
 
+#.  ``vectorized``:
+
+It is used to specify whether virtio device perfers to use vectorized path.
+Afterwards, dependencies of vectorized path will be checked in path
+election.
+(Default: 0 (disabled))
+
 Below devargs are supported by the virtio-user vdev:
 
 #.  ``path``:
diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 37766cbb6..0a69a4db1 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -48,7 +48,8 @@ static int virtio_dev_allmulticast_disable(struct rte_eth_dev 
*dev);
 static uint32_t virtio_dev_speed_capa_get(uint32_t speed);
 static int virtio_dev_devargs_parse(struct rte_devargs *devargs,
int *vdpa,
-   uint32_t *speed);
+   uint32_t *speed,
+   int *vectorized);
 static int virtio_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
 static int virtio_dev_link_update(struct rte_eth_dev *dev,
@@ -1551,8 +1552,8 @@ set_rxtx_funcs(struct rte_eth_dev *eth_dev)
eth_dev->rx_pkt_burst = &virtio_recv_pkts_packed;
}
} else {
-   if (hw->use_simple_rx) {
-   PMD_INIT_LOG(INFO, "virtio: using simple Rx path on 
port %u",
+   if (hw->use_vec_rx) {
+   PMD_INIT_LOG(INFO, "virtio: using vectorized Rx path on 
port %u",
eth_dev->data->port_id);
eth_dev->rx_pkt_burst = virtio_recv_pkts_vec;
} else if (hw->use_inorder_rx) {
@@ -1886,6 +1887,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
 {
struct virtio_hw *hw = eth_dev->data->dev_private;
uint32_t speed = SPEED_UNKNOWN;
+   int vectorized = 0;
int ret;
 
if (sizeof(struct virtio_net_hdr_mrg_rxbuf) > RTE_PKTMBUF_HEADROOM) {
@@ -1912,7 +1914,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
return 0;
}
ret = virtio_dev_devargs_parse(eth_dev->device->devargs,
-NULL, &speed);
+NULL, &speed, &vectorized);
if (ret < 0)
return ret;
hw->speed = speed;
@@ -1949,6 +1951,11 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
if (ret < 0)
goto err_virtio_init;
 
+   if (vectorized) {
+   if (!vtpci_packed_queue(hw))
+   hw->use_vec_rx = 1;
+   }
+
hw->opened = true;
 
return 0;
@@ -2021,9 +2028,20 @@ virtio_dev_speed_capa_get(uint32_t speed)
}
 }
 
+static int vectorized_check_handler(__rte_unused const char *key,
+   const char *value, void *ret_val)
+{
+   if (strcmp(value, "1") == 0)
+   *(int *)ret_val = 1;
+   else
+   *(int *)ret_val = 0;
+
+   return 0;
+}
 
 #define VIRTIO_ARG_SPEED  "speed"
 #define VIRTIO_ARG_VDPA   "vdpa"
+#define VIRTIO_ARG_VECTORIZED "vectorized"
 
 
 static int
@@ -2045,7 +2063,7 @@ link_speed_handler(const char *key __rte_unused,
 
 static int
 virtio_dev_devargs_parse(struct rte_devargs *devargs, int *vdpa,
-   uint32_t *speed)
+   uint32_t *speed, int *vectorized)
 {
struct rte_kvargs *kvlist;
int ret = 0;
@@ -2081,6 +2099,18 @@ virtio_dev_devargs_parse(struct rte_devargs *devargs, 
int *vdpa,
}
}
 
+   if (vectorized &&
+   rte_kvargs_count(kvlist, VIRTIO_ARG_VECTORIZED) == 1) {
+   ret = rte_kvargs_process(kvlist,
+   VIRTIO_ARG_VECTORIZED,
+   vectorized_check_handler, vectorized);
+   if (ret < 0) {
+   PMD_INIT_LOG(ERR, "Failed to parse %s",
+   VIRTIO_ARG_VECTORIZED);
+   goto exit;
+   }
+   }
+
 exit:
rte_kvargs_free(kvlist);
return ret;
@@ -2092,7 +2122,8 @@ static int eth_virtio_pci_probe(struct rte_pci_driver 
*pci_drv __rte_unused,
int vdpa = 0;
int ret = 0;
 
-   ret = virtio_dev_devargs_parse(pci_dev->device.devargs, &vdpa, NULL);
+   ret = virtio_dev_devargs_parse(pci_dev->device.devargs, &vdpa, NULL,
+   NULL);
if (ret < 0) {
PMD_INIT_LOG(ERR, "devargs parsing is failed");
 

[dpdk-dev] [PATCH v11 6/9] net/virtio: add vectorized packed ring Rx path

[Marvin Liu]

Optimize packed ring Rx path with SIMD instructions. Solution of
optimization is pretty like vhost, is that split path into batch and
single functions. Batch function is further optimized by AVX512
instructions. Also pad desc extra structure to 16 bytes aligned, thus
four elements will be saved in one batch.

Signed-off-by: Marvin Liu 
Reviewed-by: Maxime Coquelin 

diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
index c9edb84ee..102b1deab 100644
--- a/drivers/net/virtio/Makefile
+++ b/drivers/net/virtio/Makefile
@@ -36,6 +36,41 @@ else ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) 
$(CONFIG_RTE_ARCH_ARM64)),)
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple_neon.c
 endif
 
+ifneq ($(FORCE_DISABLE_AVX512), y)
+   CC_AVX512_SUPPORT=\
+   $(shell $(CC) -march=native -dM -E - &1 | \
+   sed '/./{H;$$!d} ; x ; /AVX512F/!d; /AVX512BW/!d; /AVX512VL/!d' | \
+   grep -q AVX512 && echo 1)
+endif
+
+ifeq ($(CC_AVX512_SUPPORT), 1)
+CFLAGS += -DCC_AVX512_SUPPORT
+SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_packed_avx.c
+
+ifeq ($(RTE_TOOLCHAIN), gcc)
+ifeq ($(shell test $(GCC_VERSION) -ge 83 && echo 1), 1)
+CFLAGS += -DVIRTIO_GCC_UNROLL_PRAGMA
+endif
+endif
+
+ifeq ($(RTE_TOOLCHAIN), clang)
+ifeq ($(shell test $(CLANG_MAJOR_VERSION)$(CLANG_MINOR_VERSION) -ge 37 && echo 
1), 1)
+CFLAGS += -DVIRTIO_CLANG_UNROLL_PRAGMA
+endif
+endif
+
+ifeq ($(RTE_TOOLCHAIN), icc)
+ifeq ($(shell test $(ICC_MAJOR_VERSION) -ge 16 && echo 1), 1)
+CFLAGS += -DVIRTIO_ICC_UNROLL_PRAGMA
+endif
+endif
+
+CFLAGS_virtio_rxtx_packed_avx.o += -mavx512f -mavx512bw -mavx512vl
+ifeq ($(shell test $(GCC_VERSION) -ge 100 && echo 1), 1)
+CFLAGS_virtio_rxtx_packed_avx.o += -Wno-zero-length-bounds
+endif
+endif
+
 ifeq ($(CONFIG_RTE_VIRTIO_USER),y)
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/vhost_user.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/vhost_kernel.c
diff --git a/drivers/net/virtio/meson.build b/drivers/net/virtio/meson.build
index 15150eea1..8e68c3039 100644
--- a/drivers/net/virtio/meson.build
+++ b/drivers/net/virtio/meson.build
@@ -9,6 +9,20 @@ sources += files('virtio_ethdev.c',
 deps += ['kvargs', 'bus_pci']
 
 if arch_subdir == 'x86'
+   if '-mno-avx512f' not in machine_args
+   if cc.has_argument('-mavx512f') and 
cc.has_argument('-mavx512vl') and cc.has_argument('-mavx512bw')
+   cflags += ['-mavx512f', '-mavx512bw', '-mavx512vl']
+   cflags += ['-DCC_AVX512_SUPPORT']
+   if (toolchain == 'gcc' and 
cc.version().version_compare('>=8.3.0'))
+   cflags += '-DVHOST_GCC_UNROLL_PRAGMA'
+   elif (toolchain == 'clang' and 
cc.version().version_compare('>=3.7.0'))
+   cflags += '-DVHOST_CLANG_UNROLL_PRAGMA'
+   elif (toolchain == 'icc' and 
cc.version().version_compare('>=16.0.0'))
+   cflags += '-DVHOST_ICC_UNROLL_PRAGMA'
+   endif
+   sources += files('virtio_rxtx_packed_avx.c')
+   endif
+   endif
sources += files('virtio_rxtx_simple_sse.c')
 elif arch_subdir == 'ppc'
sources += files('virtio_rxtx_simple_altivec.c')
diff --git a/drivers/net/virtio/virtio_ethdev.h 
b/drivers/net/virtio/virtio_ethdev.h
index febaf17a8..5c112cac7 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -105,6 +105,9 @@ uint16_t virtio_xmit_pkts_inorder(void *tx_queue, struct 
rte_mbuf **tx_pkts,
 uint16_t virtio_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
 
+uint16_t virtio_recv_pkts_packed_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+   uint16_t nb_pkts);
+
 int eth_virtio_dev_init(struct rte_eth_dev *eth_dev);
 
 void virtio_interrupt_handler(void *param);
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index a549991aa..534562cca 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -2030,3 +2030,11 @@ virtio_xmit_pkts_inorder(void *tx_queue,
 
return nb_tx;
 }
+
+__rte_weak uint16_t
+virtio_recv_pkts_packed_vec(void *rx_queue __rte_unused,
+   struct rte_mbuf **rx_pkts __rte_unused,
+   uint16_t nb_pkts __rte_unused)
+{
+   return 0;
+}
diff --git a/drivers/net/virtio/virtio_rxtx_packed_avx.c 
b/drivers/net/virtio/virtio_rxtx_packed_avx.c
new file mode 100644
index 0..88831a786
--- /dev/null
+++ b/drivers/net/virtio/virtio_rxtx_packed_avx.c
@@ -0,0 +1,374 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2020 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "virtio_logs.h"
+#include "virtio_ethdev.h"
+#include "virtio_pci.h"
+#include "virtqueue.h"
+
+#define BYTE_SIZE 8
+/* flag bits offset in packed ring desc higher 64b

[dpdk-dev] [PATCH v11 8/9] net/virtio: add election for vectorized path

[Marvin Liu]

Rewrite vectorized path selection logic. Default setting comes from
vectorized devarg, then checks each criteria.

Packed ring vectorized path need:
AVX512F and required extensions are supported by compiler and host
VERSION_1 and IN_ORDER features are negotiated
mergeable feature is not negotiated
LRO offloading is disabled

Split ring vectorized rx path need:
mergeable and IN_ORDER features are not negotiated
LRO, chksum and vlan strip offloadings are disabled

Signed-off-by: Marvin Liu 
Reviewed-by: Maxime Coquelin 

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 0a69a4db1..088d0e45e 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1523,9 +1523,12 @@ set_rxtx_funcs(struct rte_eth_dev *eth_dev)
if (vtpci_packed_queue(hw)) {
PMD_INIT_LOG(INFO,
"virtio: using packed ring %s Tx path on port %u",
-   hw->use_inorder_tx ? "inorder" : "standard",
+   hw->use_vec_tx ? "vectorized" : "standard",
eth_dev->data->port_id);
-   eth_dev->tx_pkt_burst = virtio_xmit_pkts_packed;
+   if (hw->use_vec_tx)
+   eth_dev->tx_pkt_burst = virtio_xmit_pkts_packed_vec;
+   else
+   eth_dev->tx_pkt_burst = virtio_xmit_pkts_packed;
} else {
if (hw->use_inorder_tx) {
PMD_INIT_LOG(INFO, "virtio: using inorder Tx path on 
port %u",
@@ -1539,7 +1542,13 @@ set_rxtx_funcs(struct rte_eth_dev *eth_dev)
}
 
if (vtpci_packed_queue(hw)) {
-   if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
+   if (hw->use_vec_rx) {
+   PMD_INIT_LOG(INFO,
+   "virtio: using packed ring vectorized Rx path 
on port %u",
+   eth_dev->data->port_id);
+   eth_dev->rx_pkt_burst =
+   &virtio_recv_pkts_packed_vec;
+   } else if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
PMD_INIT_LOG(INFO,
"virtio: using packed ring mergeable buffer Rx 
path on port %u",
eth_dev->data->port_id);
@@ -1952,8 +1961,17 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
goto err_virtio_init;
 
if (vectorized) {
-   if (!vtpci_packed_queue(hw))
+   if (!vtpci_packed_queue(hw)) {
+   hw->use_vec_rx = 1;
+   } else {
+#if !defined(CC_AVX512_SUPPORT)
+   PMD_DRV_LOG(INFO,
+   "building environment do not support packed 
ring vectorized");
+#else
hw->use_vec_rx = 1;
+   hw->use_vec_tx = 1;
+#endif
+   }
}
 
hw->opened = true;
@@ -2288,31 +2306,61 @@ virtio_dev_configure(struct rte_eth_dev *dev)
return -EBUSY;
}
 
-   if (vtpci_with_feature(hw, VIRTIO_F_IN_ORDER)) {
-   hw->use_inorder_tx = 1;
-   hw->use_inorder_rx = 1;
-   hw->use_vec_rx = 0;
-   }
-
if (vtpci_packed_queue(hw)) {
-   hw->use_vec_rx = 0;
-   hw->use_inorder_rx = 0;
-   }
+   if ((hw->use_vec_rx || hw->use_vec_tx) &&
+   (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F) ||
+!vtpci_with_feature(hw, VIRTIO_F_IN_ORDER) ||
+!vtpci_with_feature(hw, VIRTIO_F_VERSION_1))) {
+   PMD_DRV_LOG(INFO,
+   "disabled packed ring vectorized path for 
requirements not met");
+   hw->use_vec_rx = 0;
+   hw->use_vec_tx = 0;
+   }
 
+   if (hw->use_vec_rx) {
+   if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
+   PMD_DRV_LOG(INFO,
+   "disabled packed ring vectorized rx for 
mrg_rxbuf enabled");
+   hw->use_vec_rx = 0;
+   }
+
+   if (rx_offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+   PMD_DRV_LOG(INFO,
+   "disabled packed ring vectorized rx for 
TCP_LRO enabled");
+   hw->use_vec_rx = 0;
+   }
+   }
+   } else {
+   if (vtpci_with_feature(hw, VIRTIO_F_IN_ORDER)) {
+   hw->use_inorder_tx = 1;
+   hw->use_inorder_rx = 1;
+   hw->use_vec_rx = 0;
+   }
+
+   if (hw->use_vec_rx) {
 #if defined RTE_ARCH_ARM64 || defined RTE_ARCH_ARM
-   if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_

[dpdk-dev] [PATCH v11 5/9] net/virtio: reuse packed ring functions

[Marvin Liu]

Move offload, xmit cleanup and packed xmit enqueue function to header
file. These functions will be reused by packed ring vectorized path.

Signed-off-by: Marvin Liu 
Reviewed-by: Maxime Coquelin 

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 84f4cf946..a549991aa 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -89,23 +89,6 @@ vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
dp->next = VQ_RING_DESC_CHAIN_END;
 }
 
-static void
-vq_ring_free_id_packed(struct virtqueue *vq, uint16_t id)
-{
-   struct vq_desc_extra *dxp;
-
-   dxp = &vq->vq_descx[id];
-   vq->vq_free_cnt += dxp->ndescs;
-
-   if (vq->vq_desc_tail_idx == VQ_RING_DESC_CHAIN_END)
-   vq->vq_desc_head_idx = id;
-   else
-   vq->vq_descx[vq->vq_desc_tail_idx].next = id;
-
-   vq->vq_desc_tail_idx = id;
-   dxp->next = VQ_RING_DESC_CHAIN_END;
-}
-
 void
 virtio_update_packet_stats(struct virtnet_stats *stats, struct rte_mbuf *mbuf)
 {
@@ -264,130 +247,6 @@ virtqueue_dequeue_rx_inorder(struct virtqueue *vq,
return i;
 }
 
-#ifndef DEFAULT_TX_FREE_THRESH
-#define DEFAULT_TX_FREE_THRESH 32
-#endif
-
-static void
-virtio_xmit_cleanup_inorder_packed(struct virtqueue *vq, int num)
-{
-   uint16_t used_idx, id, curr_id, free_cnt = 0;
-   uint16_t size = vq->vq_nentries;
-   struct vring_packed_desc *desc = vq->vq_packed.ring.desc;
-   struct vq_desc_extra *dxp;
-
-   used_idx = vq->vq_used_cons_idx;
-   /* desc_is_used has a load-acquire or rte_cio_rmb inside
-* and wait for used desc in virtqueue.
-*/
-   while (num > 0 && desc_is_used(&desc[used_idx], vq)) {
-   id = desc[used_idx].id;
-   do {
-   curr_id = used_idx;
-   dxp = &vq->vq_descx[used_idx];
-   used_idx += dxp->ndescs;
-   free_cnt += dxp->ndescs;
-   num -= dxp->ndescs;
-   if (used_idx >= size) {
-   used_idx -= size;
-   vq->vq_packed.used_wrap_counter ^= 1;
-   }
-   if (dxp->cookie != NULL) {
-   rte_pktmbuf_free(dxp->cookie);
-   dxp->cookie = NULL;
-   }
-   } while (curr_id != id);
-   }
-   vq->vq_used_cons_idx = used_idx;
-   vq->vq_free_cnt += free_cnt;
-}
-
-static void
-virtio_xmit_cleanup_normal_packed(struct virtqueue *vq, int num)
-{
-   uint16_t used_idx, id;
-   uint16_t size = vq->vq_nentries;
-   struct vring_packed_desc *desc = vq->vq_packed.ring.desc;
-   struct vq_desc_extra *dxp;
-
-   used_idx = vq->vq_used_cons_idx;
-   /* desc_is_used has a load-acquire or rte_cio_rmb inside
-* and wait for used desc in virtqueue.
-*/
-   while (num-- && desc_is_used(&desc[used_idx], vq)) {
-   id = desc[used_idx].id;
-   dxp = &vq->vq_descx[id];
-   vq->vq_used_cons_idx += dxp->ndescs;
-   if (vq->vq_used_cons_idx >= size) {
-   vq->vq_used_cons_idx -= size;
-   vq->vq_packed.used_wrap_counter ^= 1;
-   }
-   vq_ring_free_id_packed(vq, id);
-   if (dxp->cookie != NULL) {
-   rte_pktmbuf_free(dxp->cookie);
-   dxp->cookie = NULL;
-   }
-   used_idx = vq->vq_used_cons_idx;
-   }
-}
-
-/* Cleanup from completed transmits. */
-static inline void
-virtio_xmit_cleanup_packed(struct virtqueue *vq, int num, int in_order)
-{
-   if (in_order)
-   virtio_xmit_cleanup_inorder_packed(vq, num);
-   else
-   virtio_xmit_cleanup_normal_packed(vq, num);
-}
-
-static void
-virtio_xmit_cleanup(struct virtqueue *vq, uint16_t num)
-{
-   uint16_t i, used_idx, desc_idx;
-   for (i = 0; i < num; i++) {
-   struct vring_used_elem *uep;
-   struct vq_desc_extra *dxp;
-
-   used_idx = (uint16_t)(vq->vq_used_cons_idx & (vq->vq_nentries - 
1));
-   uep = &vq->vq_split.ring.used->ring[used_idx];
-
-   desc_idx = (uint16_t) uep->id;
-   dxp = &vq->vq_descx[desc_idx];
-   vq->vq_used_cons_idx++;
-   vq_ring_free_chain(vq, desc_idx);
-
-   if (dxp->cookie != NULL) {
-   rte_pktmbuf_free(dxp->cookie);
-   dxp->cookie = NULL;
-   }
-   }
-}
-
-/* Cleanup from completed inorder transmits. */
-static __rte_always_inline void
-virtio_xmit_cleanup_inorder(struct virtqueue *vq, uint16_t num)
-{
-   uint16_t i, idx = vq->vq_used_cons_idx;
-   int16_t free_cnt = 0;
-   struct vq_desc_extra *dxp = NULL;
-
-   if (unlikely(num == 0))
-  

[dpdk-dev] [PATCH v11 7/9] net/virtio: add vectorized packed ring Tx path

[Marvin Liu]

Optimize packed ring Tx path like Rx path. Split Tx path into batch and
single Tx functions. Batch function is further optimized by AVX512
instructions.

Signed-off-by: Marvin Liu 
Reviewed-by: Maxime Coquelin 

diff --git a/drivers/net/virtio/virtio_ethdev.h 
b/drivers/net/virtio/virtio_ethdev.h
index 5c112cac7..b7d52d497 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -108,6 +108,9 @@ uint16_t virtio_recv_pkts_vec(void *rx_queue, struct 
rte_mbuf **rx_pkts,
 uint16_t virtio_recv_pkts_packed_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
 
+uint16_t virtio_xmit_pkts_packed_vec(void *tx_queue, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts);
+
 int eth_virtio_dev_init(struct rte_eth_dev *eth_dev);
 
 void virtio_interrupt_handler(void *param);
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 534562cca..460e9d4a2 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -2038,3 +2038,11 @@ virtio_recv_pkts_packed_vec(void *rx_queue __rte_unused,
 {
return 0;
 }
+
+__rte_weak uint16_t
+virtio_xmit_pkts_packed_vec(void *tx_queue __rte_unused,
+   struct rte_mbuf **tx_pkts __rte_unused,
+   uint16_t nb_pkts __rte_unused)
+{
+   return 0;
+}
diff --git a/drivers/net/virtio/virtio_rxtx_packed_avx.c 
b/drivers/net/virtio/virtio_rxtx_packed_avx.c
index 88831a786..a7358c768 100644
--- a/drivers/net/virtio/virtio_rxtx_packed_avx.c
+++ b/drivers/net/virtio/virtio_rxtx_packed_avx.c
@@ -23,6 +23,24 @@
 #define PACKED_FLAGS_MASK ((0ULL | VRING_PACKED_DESC_F_AVAIL_USED) << \
FLAGS_BITS_OFFSET)
 
+/* reference count offset in mbuf rearm data */
+#define REFCNT_BITS_OFFSET ((offsetof(struct rte_mbuf, refcnt) - \
+   offsetof(struct rte_mbuf, rearm_data)) * BYTE_SIZE)
+/* segment number offset in mbuf rearm data */
+#define SEG_NUM_BITS_OFFSET ((offsetof(struct rte_mbuf, nb_segs) - \
+   offsetof(struct rte_mbuf, rearm_data)) * BYTE_SIZE)
+
+/* default rearm data */
+#define DEFAULT_REARM_DATA (1ULL << SEG_NUM_BITS_OFFSET | \
+   1ULL << REFCNT_BITS_OFFSET)
+
+/* id bits offset in packed ring desc higher 64bits */
+#define ID_BITS_OFFSET ((offsetof(struct vring_packed_desc, id) - \
+   offsetof(struct vring_packed_desc, len)) * BYTE_SIZE)
+
+/* net hdr short size mask */
+#define NET_HDR_MASK 0x3F
+
 #define PACKED_BATCH_SIZE (RTE_CACHE_LINE_SIZE / \
sizeof(struct vring_packed_desc))
 #define PACKED_BATCH_MASK (PACKED_BATCH_SIZE - 1)
@@ -60,6 +78,237 @@ virtio_update_batch_stats(struct virtnet_stats *stats,
stats->bytes += pkt_len4;
 }
 
+static inline int
+virtqueue_enqueue_batch_packed_vec(struct virtnet_tx *txvq,
+  struct rte_mbuf **tx_pkts)
+{
+   struct virtqueue *vq = txvq->vq;
+   uint16_t head_size = vq->hw->vtnet_hdr_size;
+   uint16_t idx = vq->vq_avail_idx;
+   struct virtio_net_hdr *hdr;
+   uint16_t i, cmp;
+
+   if (vq->vq_avail_idx & PACKED_BATCH_MASK)
+   return -1;
+
+   if (unlikely((idx + PACKED_BATCH_SIZE) > vq->vq_nentries))
+   return -1;
+
+   /* Load four mbufs rearm data */
+   RTE_BUILD_BUG_ON(REFCNT_BITS_OFFSET >= 64);
+   RTE_BUILD_BUG_ON(SEG_NUM_BITS_OFFSET >= 64);
+   __m256i mbufs = _mm256_set_epi64x(*tx_pkts[3]->rearm_data,
+ *tx_pkts[2]->rearm_data,
+ *tx_pkts[1]->rearm_data,
+ *tx_pkts[0]->rearm_data);
+
+   /* refcnt=1 and nb_segs=1 */
+   __m256i mbuf_ref = _mm256_set1_epi64x(DEFAULT_REARM_DATA);
+   __m256i head_rooms = _mm256_set1_epi16(head_size);
+
+   /* Check refcnt and nb_segs */
+   const __mmask16 mask = 0x6 | 0x6 << 4 | 0x6 << 8 | 0x6 << 12;
+   cmp = _mm256_mask_cmpneq_epu16_mask(mask, mbufs, mbuf_ref);
+   if (unlikely(cmp))
+   return -1;
+
+   /* Check headroom is enough */
+   const __mmask16 data_mask = 0x1 | 0x1 << 4 | 0x1 << 8 | 0x1 << 12;
+   RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, data_off) !=
+   offsetof(struct rte_mbuf, rearm_data));
+   cmp = _mm256_mask_cmplt_epu16_mask(data_mask, mbufs, head_rooms);
+   if (unlikely(cmp))
+   return -1;
+
+   __m512i v_descx = _mm512_set_epi64(0x1, (uintptr_t)tx_pkts[3],
+  0x1, (uintptr_t)tx_pkts[2],
+  0x1, (uintptr_t)tx_pkts[1],
+  0x1, (uintptr_t)tx_pkts[0]);
+
+   _mm512_storeu_si512((void *)&vq->vq_descx[idx], v_descx);
+
+   virtio_for_each_try_unroll(i, 0, PACKED_BATCH_SIZE) {
+   tx_pkts[i]->data_off -= head_size;
+   tx_pkts[i]->data_len += head_size;
+   }
+
+#ifdef RTE_VIRTIO_USER
+   __m512i descs_b

[dpdk-dev] [PATCH v11 9/9] doc: add packed vectorized path

[Marvin Liu]

Document packed virtqueue vectorized path selection logic in virtio net
PMD.

Signed-off-by: Marvin Liu 
Reviewed-by: Maxime Coquelin 

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index fdd0790e0..226f4308d 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -482,6 +482,13 @@ according to below configuration:
both negotiated, this path will be selected.
 #. Packed virtqueue in-order non-mergeable path: If in-order feature is 
negotiated and
Rx mergeable is not negotiated, this path will be selected.
+#. Packed virtqueue vectorized Rx path: If building and running environment 
support
+   AVX512 && in-order feature is negotiated && Rx mergeable is not negotiated 
&&
+   TCP_LRO Rx offloading is disabled && vectorized option enabled,
+   this path will be selected.
+#. Packed virtqueue vectorized Tx path: If building and running environment 
support
+   AVX512 && in-order feature is negotiated && vectorized option enabled,
+   this path will be selected.
 
 Rx/Tx callbacks of each Virtio path
 ~~~
@@ -504,6 +511,8 @@ are shown in below table:
Packed virtqueue non-meregable path  virtio_recv_pkts_packed
   virtio_xmit_pkts_packed
Packed virtqueue in-order mergeable path 
virtio_recv_mergeable_pkts_packed virtio_xmit_pkts_packed
Packed virtqueue in-order non-mergeable path virtio_recv_pkts_packed
   virtio_xmit_pkts_packed
+   Packed virtqueue vectorized Rx path  virtio_recv_pkts_packed_vec
   virtio_xmit_pkts_packed
+   Packed virtqueue vectorized Tx path  virtio_recv_pkts_packed
   virtio_xmit_pkts_packed_vec
 
= 
 
 Virtio paths Support Status from Release to Release
@@ -521,20 +530,22 @@ All virtio paths support status are shown in below table:
 
 .. table:: Virtio Paths and Releases
 
-    = = 
=
-  Virtio paths  16.11 ~ 18.05 18.08 ~ 18.11 
19.02 ~ 19.11
-    = = 
=
-   Split virtqueue mergeable path Y Y  
   Y
-   Split virtqueue non-mergeable path Y Y  
   Y
-   Split virtqueue vectorized Rx path Y Y  
   Y
-   Split virtqueue simple Tx path Y N  
   N
-   Split virtqueue in-order mergeable path  Y  
   Y
-   Split virtqueue in-order non-mergeable path  Y  
   Y
-   Packed virtqueue mergeable path 
   Y
-   Packed virtqueue non-mergeable path 
   Y
-   Packed virtqueue in-order mergeable path
   Y
-   Packed virtqueue in-order non-mergeable path
   Y
-    = = 
=
+    = = 
= ===
+  Virtio paths  16.11 ~ 18.05 18.08 ~ 18.11 
19.02 ~ 19.11 20.05 ~
+    = = 
= ===
+   Split virtqueue mergeable path Y Y  
   Y  Y
+   Split virtqueue non-mergeable path Y Y  
   Y  Y
+   Split virtqueue vectorized Rx path Y Y  
   Y  Y
+   Split virtqueue simple Tx path Y N  
   N  N
+   Split virtqueue in-order mergeable path  Y  
   Y  Y
+   Split virtqueue in-order non-mergeable path  Y  
   Y  Y
+   Packed virtqueue mergeable path 
   Y  Y
+   Packed virtqueue non-mergeable path 
   Y  Y
+   Packed virtqueue in-order mergeable path
   Y  Y
+   Packed virtqueue in-order non-mergeable path
   Y  Y
+   Packed virtqueue vectorized Rx path 
  Y
+   Packed virtqueue vectorized Tx path 
  Y
+    = = 
= ===
 
 QEMU Support Status
 ~~~
-- 
2.17.1

Re: [dpdk-dev] [PATCH] app/testpmd: fix Rx/Tx stats after clear stats command

[Wei Hu (Xavier)]

Hi, Ferrh Yigit

On 2020/4/27 22:00, Ferruh Yigit wrote:

On 4/26/2020 10:22 AM, Wei Hu (Xavier) wrote:

Hi, Ferruh Yigit

On 2020/4/25 0:12, Ferruh Yigit wrote:

On 4/24/2020 12:07 PM, Wei Hu (Xavier) wrote:

From: Chengwen Feng 

Currently, when running start/clear stats&xstats/stop command many times
based on testpmd application, there are incorrect RX/TX-packets stats as
below:
-- Forward statistics for port 0  --
RX-packets: 18446744073709544808 RX-dropped: 0 ...ignore
TX-packets: 18446744073709536616 TX-dropped: 0 ...ignore


The root cause as below:
1. The struct rte_port of testpmd.h has a member variable
 "struct rte_eth_stats stats" to store the last port statistics.
2. When runnig start command, it execute cmd_start_parsed ->
 start_packet_forwarding -> fwd_stats_reset, which call rte_eth_stats_get
 API function to save current port statistics.
3. When running stop command, it execute fwd_stats_display, which call
 rte_eth_stats_get to get current port statistics, and then minus last
 port statistics.
4. If we run clear stats or xstats after start command, then run stop,
 it may display above incorrect stats because the current Rx/Tx-packets
 is lower than the last saved RX/TX-packets(uint64_t overflow).


Looks like valid issue.

Can you please update the title to mention this fixes the forward stats (to
prevent the misunderstanding that issue is in the port stats).

Also can you please update the documentation
(doc/guides/testpmd_app_ug/testpmd_funcs.rst), "clear port" command to say this
will also affect the forward stats output (show fwd)?



This patch fixes it by clearing last port statistics when executing
"clear stats/xstats" command.

Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org

Signed-off-by: Chengwen Feng 
Signed-off-by: Wei Hu (Xavier) 
---
   app/test-pmd/config.c | 11 +++
   1 file changed, 11 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 72f25d152..0d2375607 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -234,10 +234,16 @@ nic_stats_display(portid_t port_id)
   void
   nic_stats_clear(portid_t port_id)
   {
+   struct rte_port *port;
+
if (port_id_is_invalid(port_id, ENABLED_WARN)) {
print_valid_ports();
return;
}
+
+   port = &ports[port_id];
+   /* clear last port statistics because eth stats reset */
+   memset(&port->stats, 0, sizeof(port->stats));


"clear fwd stats" command does same thing in "fwd_stats_reset()" as:
rte_eth_stats_get(pt_id, &ports[pt_id].stats);

I suggest doing same here for consistency, but it should be after
'rte_eth_stats_reset()' in that case.



I will modify it as follows, is it consistent with your comment?
Thanks.

void
fwd_stats_reset(void)
{
streamid_t sm_id;
portid_t pt_id;
int i;

for (i = 0; i < cur_fwd_config.nb_fwd_ports; i++) {
pt_id = fwd_ports_ids[i];
-   rte_eth_stats_get(pt_id, &ports[pt_id].stats);
+   rte_eth_stats_reset(port_id);
+   meset(&ports[pt_id].stats, 0, sizeof(ports[pt_id].stats));


No, original code is better. It resets the baseline for forward stats, if you do
your suggested change it zeros the port stats too which may have
unexpected/unwanted side affect.

For consistency I mean the new code you are adding to follow the similar
approach as existing one (not other-way around :), like:

nic_xstats_clear(portid_t port_id)
 ret = rte_eth_xstats_reset(port_id);
 rte_eth_stats_get(port_id, &ports[port_id].stats);

but if you prefer to go with 'memset' I guess that is OK too, eventually they
both give same result although I prefer above one.


Ok, got it.
Thanks.

   Regards
Xavier

Re: [dpdk-dev] [PATCH] net/iavf: fix link speed

[Zhang, AlvinX]

Thanks Beilei.

> -Original Message-
> From: Xing, Beilei
> Sent: Tuesday, April 28, 2020 3:50 PM
> To: Zhang, AlvinX ; dev@dpdk.org
> Cc: Zhang, Qi Z ; Wu, Jingjing 
> Subject: RE: [PATCH] net/iavf: fix link speed
> 
> 
> 
> > -Original Message-
> > From: Zhang, AlvinX 
> > Sent: Tuesday, April 28, 2020 2:49 PM
> > To: dev@dpdk.org
> > Cc: Zhang, Qi Z ; Xing, Beilei
> > ; Zhang, AlvinX ; Wu,
> > Jingjing 
> > Subject: [PATCH] net/iavf: fix link speed
> >
> > From: Alvin Zhang 
> >
> > If the PF driver does not support the new speed reporting capabilities
> > then use link_event else use link_event_adv to get the speed.
> >
> > Fixes: 48de41ca11f0 (net/iavf: enable link status update)
> > Cc: jingjing...@intel.com
> 
> Cc stable.
> 
> >
> > Signed-off-by: Alvin Zhang 
> > ---
> >  drivers/net/iavf/iavf_vchnl.c | 47
> > ++-
> >  1 file changed, 46 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/iavf/iavf_vchnl.c
> > b/drivers/net/iavf/iavf_vchnl.c index
> > 2a0cdd9..104a769 100644
> > --- a/drivers/net/iavf/iavf_vchnl.c
> > +++ b/drivers/net/iavf/iavf_vchnl.c
> > @@ -130,6 +130,44 @@
> >  return err;
> >  }
> >
> > +static uint32_t
> > +iavf_convert_link_speed(uint32_t virt_link_speed) {
> 
> Why use uint32_t but not enum virtchnl_link_speed for the parameter?
> 
> > +uint32_t speed;
> > +
> > +switch (virt_link_speed) {
> > +case VIRTCHNL_LINK_SPEED_100MB:
> > +speed = 100;
> > +break;
> > +case VIRTCHNL_LINK_SPEED_1GB:
> > +speed = 1000;
> > +break;
> > +case VIRTCHNL_LINK_SPEED_10GB:
> > +speed = 1;
> > +break;
> > +case VIRTCHNL_LINK_SPEED_40GB:
> > +speed = 4;
> > +break;
> > +case VIRTCHNL_LINK_SPEED_20GB:
> > +speed = 2;
> > +break;
> > +case VIRTCHNL_LINK_SPEED_25GB:
> > +speed = 25000;
> > +break;
> > +case VIRTCHNL_LINK_SPEED_2_5GB:
> > +speed = 2500;
> > +break;
> > +case VIRTCHNL_LINK_SPEED_5GB:
> > +speed = 5000;
> > +break;
> > +default:
> > +speed = 0;
> > +break;
> > +}
> > +
> > +return speed;
> > +}
> > +
> >  static void
> >  iavf_handle_pf_event_msg(struct rte_eth_dev *dev, uint8_t *msg,
> > uint16_t msglen) @@ -151,7 +189,14 @@  case
> > VIRTCHNL_EVENT_LINK_CHANGE:
> >  PMD_DRV_LOG(DEBUG, "VIRTCHNL_EVENT_LINK_CHANGE event");  vf-
> >link_up
> > = pf_msg->event_data.link_event.link_status;
> > -vf->link_speed = pf_msg-
> > >event_data.link_event_adv.link_speed;
> > +if (vf->vf_res->vf_cap_flags &
> > VIRTCHNL_VF_CAP_ADV_LINK_SPEED) {
> > +vf->link_speed =
> > +pf_msg-
> > >event_data.link_event_adv.link_speed;
> > +} else {
> > +enum virtchnl_link_speed speed;
> > +speed = pf_msg->event_data.link_event.link_speed;
> > +vf->link_speed = iavf_convert_link_speed(speed);
> > +}
> >  iavf_dev_link_update(dev, 0);
> >  _rte_eth_dev_callback_process(dev,
> > RTE_ETH_EVENT_INTR_LSC,
> >NULL);
> > --
> > 1.8.3.1
> 

Re: [dpdk-dev] [PATCH v10 6/9] net/virtio: add vectorized packed ring Rx path

[Maxime Coquelin]

On 4/28/20 3:14 AM, Liu, Yong wrote:
> 
> 
>> -Original Message-
>> From: Maxime Coquelin 
>> Sent: Monday, April 27, 2020 7:21 PM
>> To: Liu, Yong ; Ye, Xiaolong ;
>> Wang, Zhihong 
>> Cc: dev@dpdk.org
>> Subject: Re: [PATCH v10 6/9] net/virtio: add vectorized packed ring Rx path
>>
>>
>>
>> On 4/26/20 4:19 AM, Marvin Liu wrote:
>>> Optimize packed ring Rx path with SIMD instructions. Solution of
>>> optimization is pretty like vhost, is that split path into batch and
>>> single functions. Batch function is further optimized by AVX512
>>> instructions. Also pad desc extra structure to 16 bytes aligned, thus
>>> four elements will be saved in one batch.
>>>
>>> Signed-off-by: Marvin Liu 
>>>
>>> diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
>>> index c9edb84ee..102b1deab 100644
>>> --- a/drivers/net/virtio/Makefile
>>> +++ b/drivers/net/virtio/Makefile
>>> @@ -36,6 +36,41 @@ else ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM)
>> $(CONFIG_RTE_ARCH_ARM64)),)
>>>  SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple_neon.c
>>>  endif
>>>
>>> +ifneq ($(FORCE_DISABLE_AVX512), y)
>>> +   CC_AVX512_SUPPORT=\
>>> +   $(shell $(CC) -march=native -dM -E - &1 | \
>>> +   sed '/./{H;$$!d} ; x ; /AVX512F/!d; /AVX512BW/!d; /AVX512VL/!d' | \
>>> +   grep -q AVX512 && echo 1)
>>> +endif
>>> +
>>> +ifeq ($(CC_AVX512_SUPPORT), 1)
>>> +CFLAGS += -DCC_AVX512_SUPPORT
>>> +SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_packed_avx.c
>>> +
>>> +ifeq ($(RTE_TOOLCHAIN), gcc)
>>> +ifeq ($(shell test $(GCC_VERSION) -ge 83 && echo 1), 1)
>>> +CFLAGS += -DVIRTIO_GCC_UNROLL_PRAGMA
>>> +endif
>>> +endif
>>> +
>>> +ifeq ($(RTE_TOOLCHAIN), clang)
>>> +ifeq ($(shell test $(CLANG_MAJOR_VERSION)$(CLANG_MINOR_VERSION) -
>> ge 37 && echo 1), 1)
>>> +CFLAGS += -DVIRTIO_CLANG_UNROLL_PRAGMA
>>> +endif
>>> +endif
>>> +
>>> +ifeq ($(RTE_TOOLCHAIN), icc)
>>> +ifeq ($(shell test $(ICC_MAJOR_VERSION) -ge 16 && echo 1), 1)
>>> +CFLAGS += -DVIRTIO_ICC_UNROLL_PRAGMA
>>> +endif
>>> +endif
>>> +
>>> +CFLAGS_virtio_rxtx_packed_avx.o += -mavx512f -mavx512bw -mavx512vl
>>> +ifeq ($(shell test $(GCC_VERSION) -ge 100 && echo 1), 1)
>>> +CFLAGS_virtio_rxtx_packed_avx.o += -Wno-zero-length-bounds
>>> +endif
>>> +endif
>>> +
>>>  ifeq ($(CONFIG_RTE_VIRTIO_USER),y)
>>>  SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/vhost_user.c
>>>  SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/vhost_kernel.c
>>> diff --git a/drivers/net/virtio/meson.build b/drivers/net/virtio/meson.build
>>> index 15150eea1..8e68c3039 100644
>>> --- a/drivers/net/virtio/meson.build
>>> +++ b/drivers/net/virtio/meson.build
>>> @@ -9,6 +9,20 @@ sources += files('virtio_ethdev.c',
>>>  deps += ['kvargs', 'bus_pci']
>>>
>>>  if arch_subdir == 'x86'
>>> +   if '-mno-avx512f' not in machine_args
>>> +   if cc.has_argument('-mavx512f') and cc.has_argument('-
>> mavx512vl') and cc.has_argument('-mavx512bw')
>>> +   cflags += ['-mavx512f', '-mavx512bw', '-mavx512vl']
>>> +   cflags += ['-DCC_AVX512_SUPPORT']
>>> +   if (toolchain == 'gcc' and
>> cc.version().version_compare('>=8.3.0'))
>>> +   cflags += '-DVHOST_GCC_UNROLL_PRAGMA'
>>> +   elif (toolchain == 'clang' and
>> cc.version().version_compare('>=3.7.0'))
>>> +   cflags += '-
>> DVHOST_CLANG_UNROLL_PRAGMA'
>>> +   elif (toolchain == 'icc' and
>> cc.version().version_compare('>=16.0.0'))
>>> +   cflags += '-DVHOST_ICC_UNROLL_PRAGMA'
>>> +   endif
>>> +   sources += files('virtio_rxtx_packed_avx.c')
>>> +   endif
>>> +   endif
>>> sources += files('virtio_rxtx_simple_sse.c')
>>>  elif arch_subdir == 'ppc'
>>> sources += files('virtio_rxtx_simple_altivec.c')
>>> diff --git a/drivers/net/virtio/virtio_ethdev.h
>> b/drivers/net/virtio/virtio_ethdev.h
>>> index febaf17a8..5c112cac7 100644
>>> --- a/drivers/net/virtio/virtio_ethdev.h
>>> +++ b/drivers/net/virtio/virtio_ethdev.h
>>> @@ -105,6 +105,9 @@ uint16_t virtio_xmit_pkts_inorder(void *tx_queue,
>> struct rte_mbuf **tx_pkts,
>>>  uint16_t virtio_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
>>> uint16_t nb_pkts);
>>>
>>> +uint16_t virtio_recv_pkts_packed_vec(void *rx_queue, struct rte_mbuf
>> **rx_pkts,
>>> +   uint16_t nb_pkts);
>>> +
>>>  int eth_virtio_dev_init(struct rte_eth_dev *eth_dev);
>>>
>>>  void virtio_interrupt_handler(void *param);
>>> diff --git a/drivers/net/virtio/virtio_rxtx.c 
>>> b/drivers/net/virtio/virtio_rxtx.c
>>> index a549991aa..534562cca 100644
>>> --- a/drivers/net/virtio/virtio_rxtx.c
>>> +++ b/drivers/net/virtio/virtio_rxtx.c
>>> @@ -2030,3 +2030,11 @@ virtio_xmit_pkts_inorder(void *tx_queue,
>>>
>>> return nb_tx;
>>>  }
>>> +
>>> +__rte_weak uint16_t
>>> +virtio_recv_pkts_packed_vec(void *rx_queue __rte_unused,
>>> +   struct rte_mbuf **rx_pkts __rte_unused,
>>>

Re: [dpdk-dev] [PATCH] bus/pci: optimize pci device probe

[David Marchand]

On Sun, Apr 26, 2020 at 10:06 PM Thomas Monjalon  wrote:
>
> 26/04/2020 20:41, Jerin Jacob:
> > On Sun, Apr 26, 2020 at 11:38 PM Thomas Monjalon  
> > wrote:
> > >
> > > 26/04/2020 19:38, jer...@marvell.com:
> > > > From: Jerin Jacob 
> > > >
> > > > If the PCI device is not attached to any driver then there is no
> > > > point in probing it. As an optimization, skip the PCI device probe if
> > > > the PCI device driver of type RTE_KDRV_NONE.
> > > >
> > > > Signed-off-by: Jerin Jacob 
> > > > ---
> > > > Notes:
> > > > --
> > > > - virtio drivers does special treatment based on RTE_KDRV_UNKNOWN, That 
> > > > is
> > > > the reason allowing RTE_KDRV_UNKNOWN in this patch.
> > > > - virio devices uses RTE_KDRV_UNKNOWN for some special meaning, IMO, if 
> > > > it would
> > > >   be better, if
> > > > a) Introduce the KDRV for virio
> > > > b) If the PCIe device of driver type NONE or UNKNOWN then not even add 
> > > > in pci
> > > > list
> > > > in the scan, It will improve the boot time by avoiding operation on
> > > > unwanted device like sorting the PCI devices, scanning it, probe it, 
> > > > managing
> > > > it etc.
> > >
> > > mlx4/mlx4 uses RTE_KDRV_UNKNOWN.
> >
> > OK.
> >
> > > > - Initial problem reported at http://patches.dpdk.org/patch/64999/ as
> > > > boot time printf clutter on octeontx2 devices with a lot PCI devices 
> > > > which are
> > > > of type RTE_KDRV_NONE.
> > >
> > > Add a logtype for PCI driver and adjust log level accordingly
> > > to your preferences.
> > >
> > > > @@ -271,6 +271,8 @@ pci_probe_all_drivers(struct rte_pci_device *dev)
> > > >   FOREACH_DRIVER_ON_PCIBUS(dr) {
> > > > + if (dev->kdrv == RTE_KDRV_NONE)
> > > > + continue;
> > > >   rc = rte_pci_probe_one_driver(dr, dev);
> > >
> > > Nack
> >
> > I understand mlx4/mlx5 is using RTE_KDRV_UNKNOWN, Here we are skipping
> > the RTE_KDRV_NONE,
> > What is the use case for probing the devices with RTE_KDRV_NONE?
>
> Maybe you are right. I don't remember the use case.
> I think I remember these virtio and vmxnet3 PMD were not using UIO:
> http://git.dpdk.org/old/virtio-net-pmd/tree/virtio_user.c
> http://git.dpdk.org/old/vmxnet3-usermap/tree/pmd/vmxnet3.c
>
> We need to know which case is using following code:
>
> case RTE_KDRV_NONE:
> #if defined(RTE_ARCH_X86)
> ret = pci_ioport_map(dev, bar, p);
> #endif
> break;
>
> David, please could you refresh our memory?

The in-tree virtio-net driver directly calls rte_pci_map_device /
rte_pci_ioport_map depending on virtio legacy/modern modes.
This is why the virtio pci driver does not ask for
RTE_PCI_DRV_NEED_MAPPING to the pci bus.


In ioport mode, there were two options for historical reasons because
of the virtio driver you mention.
This driver did not rely on uio, and this behavior was later merged to
the current in-tree driver.
It ended up (not clean) in the pci bus driver because virtio was the
only user of this code.


Removing this special case could break x86 applications running with
legacy virtio.


On the plus side, we have been announcing for some time in virtio:
RTE_PMD_REGISTER_KMOD_DEP(net_virtio, "* igb_uio | uio_pci_generic | vfio-pci");


-- 
David Marchand

Re: [dpdk-dev] [PATCH] rte_trace: fix build on PPC64

[David Marchand]

On Tue, Apr 28, 2020 at 9:58 AM Jerin Jacob  wrote:
>
> On Tue, Apr 28, 2020 at 3:29 AM Thinh Tran  wrote:
> >
> > The AltiVec header file breaks boolean type:
> >
> > In file included from ../lib/librte_mempool/rte_mempool_trace_fp.h:18:0,
> >  from ../lib/librte_mempool/rte_mempool.h:54,
> >  from ../lib/librte_mbuf/rte_mbuf.h:38,
> >  from ../lib/librte_net/rte_ether.h:23,
> >  from ../drivers/common/mlx5/mlx5_nl.h:10,
> >  from ../drivers/common/mlx5/mlx5_nl.c:23:
> > ../lib/librte_eal/include/rte_trace_point.h: In function
> > ‘__rte_trace_point_fp_is_enabled’:
> > ../lib/librte_eal/include/rte_trace_point.h:226:9: error: incompatible
> > types when returning type ‘int’ but ‘__vector __bool int {aka
> > __vector(4) __bool int}’ was expected
> >   return false;
> >
> > This is the same as
> >  https://git.dpdk.org/dpdk/commit/?id=725f5dd
> >
> > and yet, there is no better solution for it
> >
> > Signed-off-by: Thinh Tran 
> > ---
> >  lib/librte_eal/include/rte_trace_point.h | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/lib/librte_eal/include/rte_trace_point.h 
> > b/lib/librte_eal/include/rte_trace_point.h
> > index 4d956ec16..2ede9e3ba 100644
> > --- a/lib/librte_eal/include/rte_trace_point.h
> > +++ b/lib/librte_eal/include/rte_trace_point.h
> > @@ -26,6 +26,12 @@ extern "C" {
> >  #include 
> >  #include 
> >
> > +#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__)
> > +#undef bool
> > +/* redefine as in stdbool.h */
> > +#define bool _Bool
> > +#endif
>
> NACK.
>
> Please move the fix to rte_common.h or similar as it not specific to trace.
> if you do so, the following hack also not need.
> https://git.dpdk.org/dpdk/commit/?id=725f5dd

+1

-- 
David Marchand

[dpdk-dev] [PATCH v2] net/iavf: fix link speed

[alvinx . zhang]

From: Alvin Zhang 

If the PF driver does not support the new speed reporting capabilities then
use link_event else use link_event_adv to get the speed.

Fixes: 48de41ca11f0 (net/iavf: enable link status update)
Cc: jingjing...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Alvin Zhang 
---
 drivers/net/iavf/iavf_vchnl.c | 47 ++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index 2a0cdd9..5b8d32e 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -130,6 +130,44 @@
return err;
 }
 
+static uint32_t
+iavf_convert_link_speed(enum virtchnl_link_speed virt_link_speed)
+{
+   uint32_t speed;
+
+   switch (virt_link_speed) {
+   case VIRTCHNL_LINK_SPEED_100MB:
+   speed = 100;
+   break;
+   case VIRTCHNL_LINK_SPEED_1GB:
+   speed = 1000;
+   break;
+   case VIRTCHNL_LINK_SPEED_10GB:
+   speed = 1;
+   break;
+   case VIRTCHNL_LINK_SPEED_40GB:
+   speed = 4;
+   break;
+   case VIRTCHNL_LINK_SPEED_20GB:
+   speed = 2;
+   break;
+   case VIRTCHNL_LINK_SPEED_25GB:
+   speed = 25000;
+   break;
+   case VIRTCHNL_LINK_SPEED_2_5GB:
+   speed = 2500;
+   break;
+   case VIRTCHNL_LINK_SPEED_5GB:
+   speed = 5000;
+   break;
+   default:
+   speed = 0;
+   break;
+   }
+
+   return speed;
+}
+
 static void
 iavf_handle_pf_event_msg(struct rte_eth_dev *dev, uint8_t *msg,
uint16_t msglen)
@@ -151,7 +189,14 @@
case VIRTCHNL_EVENT_LINK_CHANGE:
PMD_DRV_LOG(DEBUG, "VIRTCHNL_EVENT_LINK_CHANGE event");
vf->link_up = pf_msg->event_data.link_event.link_status;
-   vf->link_speed = pf_msg->event_data.link_event_adv.link_speed;
+   if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_CAP_ADV_LINK_SPEED) {
+   vf->link_speed =
+   pf_msg->event_data.link_event_adv.link_speed;
+   } else {
+   enum virtchnl_link_speed speed;
+   speed = pf_msg->event_data.link_event.link_speed;
+   vf->link_speed = iavf_convert_link_speed(speed);
+   }
iavf_dev_link_update(dev, 0);
_rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_LSC,
  NULL);
-- 
1.8.3.1

[dpdk-dev] [PATCH v2] net/iavf: fix link speed

[alvinx . zhang]

From: Alvin Zhang 

If the PF driver does not support the new speed reporting capabilities then
use link_event else use link_event_adv to get the speed.

Fixes: 48de41ca11f0 (net/iavf: enable link status update)
Cc: jingjing...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Alvin Zhang 

V2: Modify codes according to comments.
---
 drivers/net/iavf/iavf_vchnl.c | 47 ++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index 2a0cdd9..5b8d32e 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -130,6 +130,44 @@
return err;
 }
 
+static uint32_t
+iavf_convert_link_speed(enum virtchnl_link_speed virt_link_speed)
+{
+   uint32_t speed;
+
+   switch (virt_link_speed) {
+   case VIRTCHNL_LINK_SPEED_100MB:
+   speed = 100;
+   break;
+   case VIRTCHNL_LINK_SPEED_1GB:
+   speed = 1000;
+   break;
+   case VIRTCHNL_LINK_SPEED_10GB:
+   speed = 1;
+   break;
+   case VIRTCHNL_LINK_SPEED_40GB:
+   speed = 4;
+   break;
+   case VIRTCHNL_LINK_SPEED_20GB:
+   speed = 2;
+   break;
+   case VIRTCHNL_LINK_SPEED_25GB:
+   speed = 25000;
+   break;
+   case VIRTCHNL_LINK_SPEED_2_5GB:
+   speed = 2500;
+   break;
+   case VIRTCHNL_LINK_SPEED_5GB:
+   speed = 5000;
+   break;
+   default:
+   speed = 0;
+   break;
+   }
+
+   return speed;
+}
+
 static void
 iavf_handle_pf_event_msg(struct rte_eth_dev *dev, uint8_t *msg,
uint16_t msglen)
@@ -151,7 +189,14 @@
case VIRTCHNL_EVENT_LINK_CHANGE:
PMD_DRV_LOG(DEBUG, "VIRTCHNL_EVENT_LINK_CHANGE event");
vf->link_up = pf_msg->event_data.link_event.link_status;
-   vf->link_speed = pf_msg->event_data.link_event_adv.link_speed;
+   if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_CAP_ADV_LINK_SPEED) {
+   vf->link_speed =
+   pf_msg->event_data.link_event_adv.link_speed;
+   } else {
+   enum virtchnl_link_speed speed;
+   speed = pf_msg->event_data.link_event.link_speed;
+   vf->link_speed = iavf_convert_link_speed(speed);
+   }
iavf_dev_link_update(dev, 0);
_rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_LSC,
  NULL);
-- 
1.8.3.1

[dpdk-dev] [PATCH] net/mlx5: fix indexed pool bitmap initialization

[Suanming Mou]

Currently, the indexed memory pool bitmap start address is not aligned
to cacheline size explicitly. The bitmap initialization requires the
address should be cacheline aligned. In that case, the initialization
maybe failed if the address is not cacheline aligned.

Add RTE_CACHE_LINE_ROUNDUP() to the trunk size calculation to make sure
the bitmap offset address will start with cacheline aligned.

Fixes: a3cf59f56c47 ("net/mlx5: add indexed memory pool")

Signed-off-by: Suanming Mou 
Tested-by: Lijian Zhang 
Acked-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/mlx5_utils.c | 10 +++---
 drivers/net/mlx5/mlx5_utils.h |  2 +-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_utils.c b/drivers/net/mlx5/mlx5_utils.c
index 2146ffd..d29fbcb 100644
--- a/drivers/net/mlx5/mlx5_utils.c
+++ b/drivers/net/mlx5/mlx5_utils.c
@@ -265,7 +265,9 @@ struct mlx5_indexed_pool *
trunk_size += sizeof(*trunk);
data_size = mlx5_trunk_size_get(pool, idx);
bmp_size = rte_bitmap_get_memory_footprint(data_size);
-   trunk_size += data_size * pool->cfg.size + bmp_size;
+   /* rte_bitmap requires memory cacheline aligned. */
+   trunk_size += RTE_CACHE_LINE_ROUNDUP(data_size * pool->cfg.size);
+   trunk_size += bmp_size;
trunk = pool->cfg.malloc(pool->cfg.type, trunk_size,
 RTE_CACHE_LINE_SIZE, rte_socket_id());
if (!trunk)
@@ -278,8 +280,10 @@ struct mlx5_indexed_pool *
MLX5_ASSERT(pool->free_list == TRUNK_INVALID);
pool->free_list = idx;
/* Mark all entries as available. */
-   trunk->bmp = rte_bitmap_init_with_all_set(data_size,
-&trunk->data[data_size * pool->cfg.size], bmp_size);
+   trunk->bmp = rte_bitmap_init_with_all_set(data_size, &trunk->data
+[RTE_CACHE_LINE_ROUNDUP(data_size * pool->cfg.size)],
+bmp_size);
+   MLX5_ASSERT(trunk->bmp);
pool->n_trunk_valid++;
 #ifdef POOL_DEBUG
pool->trunk_new++;
diff --git a/drivers/net/mlx5/mlx5_utils.h b/drivers/net/mlx5/mlx5_utils.h
index d81ace3..1248caa 100644
--- a/drivers/net/mlx5/mlx5_utils.h
+++ b/drivers/net/mlx5/mlx5_utils.h
@@ -115,7 +115,7 @@ struct mlx5_indexed_trunk {
uint32_t next; /* Next free trunk in free list. */
uint32_t free; /* Free entries available */
struct rte_bitmap *bmp;
-   uint8_t data[] __rte_cache_min_aligned; /* Entry data start. */
+   uint8_t data[] __rte_cache_aligned; /* Entry data start. */
 };
 
 struct mlx5_indexed_pool {
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 1/2] vhost: utilize dpdk dynamic memory allocator

[Marvin Liu]

Replace dynamic memory allocator with dpdk memory allocator.

Signed-off-by: Marvin Liu 

diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index bd1be0104..79fcb9d19 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -191,7 +191,7 @@ vhost_backend_cleanup(struct virtio_net *dev)
dev->mem = NULL;
}
 
-   free(dev->guest_pages);
+   rte_free(dev->guest_pages);
dev->guest_pages = NULL;
 
if (dev->log_addr) {
@@ -903,11 +903,12 @@ add_one_guest_page(struct virtio_net *dev, uint64_t 
guest_phys_addr,
if (dev->nr_guest_pages == dev->max_guest_pages) {
dev->max_guest_pages *= 2;
old_pages = dev->guest_pages;
-   dev->guest_pages = realloc(dev->guest_pages,
-   dev->max_guest_pages * sizeof(*page));
-   if (!dev->guest_pages) {
+   dev->guest_pages = rte_realloc(dev->guest_pages,
+   dev->max_guest_pages * sizeof(*page),
+   RTE_CACHE_LINE_SIZE);
+   if (dev->guest_pages == NULL) {
VHOST_LOG_CONFIG(ERR, "cannot realloc guest_pages\n");
-   free(old_pages);
+   rte_free(old_pages);
return -1;
}
}
@@ -1062,10 +1063,12 @@ vhost_user_set_mem_table(struct virtio_net **pdev, 
struct VhostUserMsg *msg,
vhost_user_iotlb_flush_all(dev->virtqueue[i]);
 
dev->nr_guest_pages = 0;
-   if (!dev->guest_pages) {
+   if (dev->guest_pages == NULL) {
dev->max_guest_pages = 8;
-   dev->guest_pages = malloc(dev->max_guest_pages *
-   sizeof(struct guest_page));
+   dev->guest_pages = rte_zmalloc(NULL,
+   dev->max_guest_pages *
+   sizeof(struct guest_page),
+   RTE_CACHE_LINE_SIZE);
if (dev->guest_pages == NULL) {
VHOST_LOG_CONFIG(ERR,
"(%d) failed to allocate memory "
-- 
2.17.1

[dpdk-dev] [PATCH v2 1/7] eal: move OS common functions to single file

[talshn]

From: Tal Shnaiderman 

Move common functions between Unix and Windows to eal_common_config.c.

Those simple functions are getter functions for IOVA,
configuration, Multi-process.

Move rte_config and runtime_dir to be defined in a common file.

Signed-off-by: Tal Shnaiderman 
---
 lib/librte_eal/common/eal_common_config.c | 34 +
 lib/librte_eal/common/eal_private.h   | 11 ++
 lib/librte_eal/common/meson.build |  2 ++
 lib/librte_eal/freebsd/eal.c  | 34 -
 lib/librte_eal/linux/eal.c| 33 
 lib/librte_eal/windows/eal.c  | 36 ---
 6 files changed, 47 insertions(+), 103 deletions(-)
 create mode 100644 lib/librte_eal/common/eal_common_config.c

diff --git a/lib/librte_eal/common/eal_common_config.c 
b/lib/librte_eal/common/eal_common_config.c
new file mode 100644
index 0..3a40df358
--- /dev/null
+++ b/lib/librte_eal/common/eal_common_config.c
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Mellanox Technologies, Ltd
+ */
+#include 
+
+#include 
+
+/* platform-specific runtime dir */
+static char runtime_dir[PATH_MAX];
+
+const char *
+rte_eal_get_runtime_dir(void)
+{
+   return runtime_dir;
+}
+
+/* Return a pointer to the configuration structure */
+struct rte_config *
+rte_eal_get_configuration(void)
+{
+   return &rte_config;
+}
+
+enum rte_iova_mode
+rte_eal_iova_mode(void)
+{
+   return rte_eal_get_configuration()->iova_mode;
+}
+
+enum rte_proc_type_t
+rte_eal_process_type(void)
+{
+   return rte_config.process_type;
+}
diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 735813d0c..dab9cac1d 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include 
+
 /**
  * Structure storing internal configuration (per-lcore)
  */
@@ -60,6 +62,15 @@ struct rte_config {
struct rte_mem_config *mem_config;
 } __rte_packed;
 
+
+/* early configuration structure, when memory config is not mmapped */
+static struct rte_mem_config early_mem_config;
+
+/* Address of global and public configuration */
+static struct rte_config rte_config = {
+   .mem_config = &early_mem_config,
+};
+
 /**
  * Get the global configuration structure.
  *
diff --git a/lib/librte_eal/common/meson.build 
b/lib/librte_eal/common/meson.build
index 6dcdcc890..0d8c7462b 100644
--- a/lib/librte_eal/common/meson.build
+++ b/lib/librte_eal/common/meson.build
@@ -20,6 +20,7 @@ if is_windows
'eal_common_options.c',
'eal_common_tailqs.c',
'eal_common_thread.c',
+   'eal_common_config.c',
'malloc_elem.c',
'malloc_heap.c',
'rte_malloc.c',
@@ -52,6 +53,7 @@ sources += files(
'eal_common_thread.c',
'eal_common_timer.c',
'eal_common_uuid.c',
+   'eal_common_config.c',
'hotplug_mp.c',
'malloc_elem.c',
'malloc_heap.c',
diff --git a/lib/librte_eal/freebsd/eal.c b/lib/librte_eal/freebsd/eal.c
index 80dc9aa78..a0416a48b 100644
--- a/lib/librte_eal/freebsd/eal.c
+++ b/lib/librte_eal/freebsd/eal.c
@@ -71,11 +71,6 @@ static struct flock wr_lock = {
.l_len = sizeof(early_mem_config.memsegs),
 };
 
-/* Address of global and public configuration */
-static struct rte_config rte_config = {
-   .mem_config = &early_mem_config,
-};
-
 /* internal configuration (per-core) */
 struct lcore_config lcore_config[RTE_MAX_LCORE];
 
@@ -85,9 +80,6 @@ struct internal_config internal_config;
 /* used by rte_rdtsc() */
 int rte_cycles_vmware_tsc_map;
 
-/* platform-specific runtime dir */
-static char runtime_dir[PATH_MAX];
-
 static const char *default_runtime_dir = "/var/run";
 
 int
@@ -150,13 +142,6 @@ eal_clean_runtime_dir(void)
return 0;
 }
 
-
-const char *
-rte_eal_get_runtime_dir(void)
-{
-   return runtime_dir;
-}
-
 /* Return user provided mbuf pool ops name */
 const char *
 rte_eal_mbuf_user_pool_ops(void)
@@ -164,19 +149,6 @@ rte_eal_mbuf_user_pool_ops(void)
return internal_config.user_mbuf_pool_ops_name;
 }
 
-/* Return a pointer to the configuration structure */
-struct rte_config *
-rte_eal_get_configuration(void)
-{
-   return &rte_config;
-}
-
-enum rte_iova_mode
-rte_eal_iova_mode(void)
-{
-   return rte_eal_get_configuration()->iova_mode;
-}
-
 /* parse a sysfs (or other) file containing one integer value */
 int
 eal_parse_sysfs_value(const char *filename, unsigned long *val)
@@ -970,12 +942,6 @@ rte_eal_cleanup(void)
return 0;
 }
 
-enum rte_proc_type_t
-rte_eal_process_type(void)
-{
-   return rte_config.process_type;
-}
-
 int rte_eal_has_pci(void)
 {
return !internal_config.no_pci;
diff --git a/lib/librte_eal/linux/eal.c b/lib/librte_eal/linux/eal.c
index d1e532

[dpdk-dev] [PATCH v3 2/2] vhost: binary search address mapping table

[Marvin Liu]

If Tx zero copy enabled, gpa to hpa mapping table is updated one by
one. This will harm performance when guest memory backend using 2M
hugepages. Now utilize binary search to find the entry in mapping
table, meanwhile set threshold to 256 entries for linear search.

Signed-off-by: Marvin Liu 

diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile
index e592795f2..8769afaad 100644
--- a/lib/librte_vhost/Makefile
+++ b/lib/librte_vhost/Makefile
@@ -10,7 +10,7 @@ EXPORT_MAP := rte_vhost_version.map
 
 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
 CFLAGS += -I vhost_user
-CFLAGS += -fno-strict-aliasing
+CFLAGS += -fno-strict-aliasing -Wno-maybe-uninitialized
 LDLIBS += -lpthread
 
 ifeq ($(RTE_TOOLCHAIN), gcc)
diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
index 507dbf214..a0fee39d5 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -546,20 +546,46 @@ extern int vhost_data_log_level;
 #define MAX_VHOST_DEVICE   1024
 extern struct virtio_net *vhost_devices[MAX_VHOST_DEVICE];
 
+#define VHOST_BINARY_SEARCH_THRESH 256
+static int guest_page_addrcmp(const void *p1, const void *p2)
+{
+   const struct guest_page *page1 = (const struct guest_page *)p1;
+   const struct guest_page *page2 = (const struct guest_page *)p2;
+
+   if (page1->guest_phys_addr > page2->guest_phys_addr)
+   return 1;
+   if (page1->guest_phys_addr < page2->guest_phys_addr)
+   return -1;
+
+   return 0;
+}
+
 /* Convert guest physical address to host physical address */
 static __rte_always_inline rte_iova_t
 gpa_to_hpa(struct virtio_net *dev, uint64_t gpa, uint64_t size)
 {
uint32_t i;
struct guest_page *page;
-
-   for (i = 0; i < dev->nr_guest_pages; i++) {
-   page = &dev->guest_pages[i];
-
-   if (gpa >= page->guest_phys_addr &&
-   gpa + size < page->guest_phys_addr + page->size) {
-   return gpa - page->guest_phys_addr +
-  page->host_phys_addr;
+   struct guest_page key;
+
+   if (dev->nr_guest_pages >= VHOST_BINARY_SEARCH_THRESH) {
+   key.guest_phys_addr = gpa;
+   page = bsearch(&key, dev->guest_pages, dev->nr_guest_pages,
+  sizeof(struct guest_page), guest_page_addrcmp);
+   if (page) {
+   if (gpa + size < page->guest_phys_addr + page->size)
+   return gpa - page->guest_phys_addr +
+   page->host_phys_addr;
+   }
+   } else {
+   for (i = 0; i < dev->nr_guest_pages; i++) {
+   page = &dev->guest_pages[i];
+
+   if (gpa >= page->guest_phys_addr &&
+   gpa + size < page->guest_phys_addr +
+   page->size)
+   return gpa - page->guest_phys_addr +
+  page->host_phys_addr;
}
}
 
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 79fcb9d19..15e50d27d 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -965,6 +965,12 @@ add_guest_pages(struct virtio_net *dev, struct 
rte_vhost_mem_region *reg,
reg_size -= size;
}
 
+   /* sort guest page array if over binary search threshold */
+   if (dev->nr_guest_pages >= VHOST_BINARY_SEARCH_THRESH) {
+   qsort((void *)dev->guest_pages, dev->nr_guest_pages,
+   sizeof(struct guest_page), guest_page_addrcmp);
+   }
+
return 0;
 }
 
-- 
2.17.1

[dpdk-dev] [PATCH v2 5/7] drivers: fix incorrect meson import folder for Windows

[talshn]

From: Tal Shnaiderman 

import library (/IMPLIB) in meson.build should use
the 'drivers' and not 'libs' folder.

The error is: fatal error LNK1149: output filename matches input filename.
The fix uses the correct folder.

Fixes: 5ed3766981 ("drivers: process shared link dependencies as for libs")

Signed-off-by: Tal Shnaiderman 
---
 drivers/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/meson.build b/drivers/meson.build
index a540117b6..d07360d27 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -162,7 +162,7 @@ foreach class:dpdk_driver_classes
lk_deps = [version_map, def_file]
if is_windows
lk_args = ['-Wl,/def:' + def_file.full_path(),
-   '-Wl,/implib:lib\\' + implib]
+   '-Wl,/implib:drivers\\' + implib]
else
lk_args = ['-Wl,--version-script=' + 
version_map]
# on unix systems check the output of the
-- 
2.16.1.windows.4

[dpdk-dev] [PATCH v2 3/7] eal: add function finding integer in a string

[talshn]

From: Tal Shnaiderman 

Addition of a function to skip leading chars which are not part of
the numeric base and return the number in the needed base.

This is needed to call strtoul correctly and will be used
by bus/PCI to get the BDF from a PCI output.

Signed-off-by: Tal Shnaiderman 
---
 lib/librte_eal/common/eal_common_string_fns.c | 29 +++
 lib/librte_eal/include/rte_string_fns.h   | 17 
 2 files changed, 46 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_string_fns.c 
b/lib/librte_eal/common/eal_common_string_fns.c
index 60c5dd66f..29d1539da 100644
--- a/lib/librte_eal/common/eal_common_string_fns.c
+++ b/lib/librte_eal/common/eal_common_string_fns.c
@@ -8,6 +8,7 @@
 #include 
 
 #include 
+#include 
 
 /* split string into tokens */
 int
@@ -64,3 +65,31 @@ rte_strscpy(char *dst, const char *src, size_t dsize)
dst[res - 1] = '\0';
return -E2BIG;
 }
+
+/* Skip leading chars to return the number in the needed base
+ *
+ * Return 0 and rte_errno if no number found,
+ * Otherwise return the number in the needed base
+ */
+unsigned long
+rte_find_numerical_value(char *str, int base)
+{
+   unsigned int num = 0;
+   uint8_t i = 0;
+
+   if (str == NULL)
+   goto einval_error;
+
+   while (str[i]) {
+   if ((base == 10 && isdigit(str[i])) ||
+   (base == 16 && isxdigit(str[i]))) {
+   num = strtoul(&str[i], NULL, base);
+   goto end;
+   }
+   i++;
+   }
+einval_error:
+   rte_errno = EINVAL;
+end:
+   return num;
+}
diff --git a/lib/librte_eal/include/rte_string_fns.h 
b/lib/librte_eal/include/rte_string_fns.h
index 8bac8243c..df6e07dd3 100644
--- a/lib/librte_eal/include/rte_string_fns.h
+++ b/lib/librte_eal/include/rte_string_fns.h
@@ -50,6 +50,23 @@ int
 rte_strsplit(char *string, int stringlen,
  char **tokens, int maxtokens, char delim);
 
+/**
+ * Skips leading characters to return a number in the needed base
+ *
+ * @param str
+ *   The input string to search upon
+ *
+ * @param base
+ *   The base of the needed number.
+ *   (currently supports bases 10 and 16)
+ *
+ * @return
+ *   - the number in the correct base if found
+ *   - zero and rte_errno = EINVAL if no number was found
+ */
+unsigned long
+rte_find_numerical_value(char *str, int base);
+
 /**
  * @internal
  * DPDK-specific version of strlcpy for systems without
-- 
2.16.1.windows.4

[dpdk-dev] [PATCH v2 6/7] bus/pci: introduce Windows support with stubs

[talshn]

From: Tal Shnaiderman 

Addition of stub eal and bus/pci functions to compile
bus/pci for Windows.

Signed-off-by: Tal Shnaiderman 
---
 drivers/baseband/meson.build   |   4 +
 drivers/bus/ifpga/meson.build  |   6 ++
 drivers/bus/pci/meson.build|  14 ++-
 drivers/bus/pci/pci_common.c   |   2 -
 drivers/bus/pci/windows/pci.c  | 178 +
 drivers/bus/vdev/meson.build   |   6 ++
 drivers/bus/vmbus/meson.build  |   7 ++
 drivers/common/meson.build |   4 +
 drivers/compress/meson.build   |   4 +
 drivers/crypto/meson.build |   4 +
 drivers/event/meson.build  |   4 +
 drivers/mempool/meson.build|   4 +
 drivers/meson.build|   4 -
 drivers/net/meson.build|   4 +
 drivers/raw/meson.build|   4 +
 drivers/vdpa/meson.build   |   4 +
 lib/librte_eal/common/meson.build  |   2 +
 lib/librte_eal/rte_eal_exports.def |   8 ++
 lib/librte_eal/windows/eal.c   |  27 +-
 lib/librte_eal/windows/eal_mp.c|  14 +++
 20 files changed, 293 insertions(+), 11 deletions(-)
 create mode 100644 drivers/bus/pci/windows/pci.c

diff --git a/drivers/baseband/meson.build b/drivers/baseband/meson.build
index 4d909f9a6..b299c3a06 100644
--- a/drivers/baseband/meson.build
+++ b/drivers/baseband/meson.build
@@ -1,6 +1,10 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2018 Luca Boccassi 
 
+if host_machine.system() == 'windows'
+   subdir_done()
+endif
+
 drivers = ['null', 'turbo_sw', 'fpga_lte_fec', 'fpga_5gnr_fec']
 
 config_flag_fmt = 'RTE_LIBRTE_PMD_BBDEV_@0@'
diff --git a/drivers/bus/ifpga/meson.build b/drivers/bus/ifpga/meson.build
index 4ea31f174..15339e065 100644
--- a/drivers/bus/ifpga/meson.build
+++ b/drivers/bus/ifpga/meson.build
@@ -1,6 +1,12 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2010-2018 Intel Corporation
 
+if host_machine.system() == 'windows'
+   build = false
+   reason = 'not supported on Windows'
+   subdir_done()
+endif
+
 deps += ['pci', 'kvargs', 'rawdev']
 install_headers('rte_bus_ifpga.h')
 sources = files('ifpga_common.c', 'ifpga_bus.c')
diff --git a/drivers/bus/pci/meson.build b/drivers/bus/pci/meson.build
index b520bdfc1..31c492021 100644
--- a/drivers/bus/pci/meson.build
+++ b/drivers/bus/pci/meson.build
@@ -4,16 +4,22 @@
 deps += ['pci']
 install_headers('rte_bus_pci.h')
 sources = files('pci_common.c',
-   'pci_common_uio.c',
'pci_params.c')
 if is_linux
-   sources += files('linux/pci.c',
+   sources += files('pci_common_uio.c',
+   'linux/pci.c',
'linux/pci_uio.c',
'linux/pci_vfio.c')
includes += include_directories('linux')
-else
-   sources += files('bsd/pci.c')
+endif
+if host_machine.system() == 'bsd'
+   sources += files('pci_common_uio.c',
+   'bsd/pci.c')
includes += include_directories('bsd')
 endif
+if host_machine.system() == 'windows'
+   sources += files('windows/pci.c')
+   includes += include_directories('windows')
+endif
 
 deps += ['kvargs']
diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
index 3f5542076..1cc8d6c0f 100644
--- a/drivers/bus/pci/pci_common.c
+++ b/drivers/bus/pci/pci_common.c
@@ -10,8 +10,6 @@
 #include 
 #include 
 #include 
-#include 
-
 #include 
 #include 
 #include 
diff --git a/drivers/bus/pci/windows/pci.c b/drivers/bus/pci/windows/pci.c
new file mode 100644
index 0..d02bfce36
--- /dev/null
+++ b/drivers/bus/pci/windows/pci.c
@@ -0,0 +1,178 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+#include 
+#include 
+
+#include 
+#include 
+
+#include "private.h"
+
+/* The functions below are not implemented on Windows,
+ * but need to be defined for compilation purposes
+ */
+
+/* unbind kernel driver for this device */
+int
+pci_unbind_kernel_driver(struct rte_pci_device *dev __rte_unused)
+{
+   RTE_LOG(ERR, EAL, "RTE_PCI_DRV_FORCE_UNBIND flag"
+   " is not implemented presently in Windows\n");
+   return -ENOTSUP;
+}
+
+/* Map pci device */
+int
+rte_pci_map_device(struct rte_pci_device *dev __rte_unused)
+{
+   /* This function is not implemented on Windows.
+* We really should short-circuit the call to these functions by
+* clearing the RTE_PCI_DRV_NEED_MAPPING flag
+* in the rte_pci_driver flags.
+*/
+   return 0;
+}
+
+/* Unmap pci device */
+void
+rte_pci_unmap_device(struct rte_pci_device *dev __rte_unused)
+{
+   /* This function is not implemented on Windows.
+* We really should short-circuit the call to these functions by
+* clearing the RTE_PCI_DRV_NEED_MAPPING flag
+* in the rte_pci_driver flags.
+*/
+}
+
+int
+pci_update_device(const struct rte_pci_addr *addr __rte_unused)
+{
+   /* This function is not implemented on Windows.
+* We rea

[dpdk-dev] [PATCH v2 0/7] Windows bus/pci support

[talshn]

From: Tal Shnaiderman 

This patchset implements the EAL and PCI functions needed for probing PMDs 
using RTE_KDRV_NONE on Windows.

Depends-on: series-9374 ("Windows basic memory management")

v2:
* fix style issues.
* fix error handing flow in pci.c
* change eal_config.c to eal_common_config.c 

Tal Shnaiderman (7):
  eal: move OS common functions to single file
  pci: build on Windows
  eal: add function finding integer in a string
  drivers: ignore pmdinfogen generation for Windows
  drivers: fix incorrect meson import folder for Windows
  bus/pci: introduce Windows support with stubs
  bus/pci: support Windows with bifurcated drivers

 drivers/baseband/meson.build  |   4 +
 drivers/bus/ifpga/meson.build |   6 +
 drivers/bus/pci/meson.build   |  14 +-
 drivers/bus/pci/pci_common.c  |   2 -
 drivers/bus/pci/windows/pci.c | 516 ++
 drivers/bus/vdev/meson.build  |   6 +
 drivers/bus/vmbus/meson.build |   7 +
 drivers/common/meson.build|   4 +
 drivers/compress/meson.build  |   4 +
 drivers/crypto/meson.build|   4 +
 drivers/event/meson.build |   4 +
 drivers/mempool/meson.build   |   4 +
 drivers/meson.build   |   9 +-
 drivers/net/meson.build   |   4 +
 drivers/raw/meson.build   |   4 +
 drivers/vdpa/meson.build  |   4 +
 lib/librte_eal/common/eal_common_config.c |  34 ++
 lib/librte_eal/common/eal_common_string_fns.c |  29 ++
 lib/librte_eal/common/eal_private.h   |  11 +
 lib/librte_eal/common/meson.build |   4 +
 lib/librte_eal/freebsd/eal.c  |  34 --
 lib/librte_eal/include/rte_string_fns.h   |  17 +
 lib/librte_eal/linux/eal.c|  33 --
 lib/librte_eal/rte_eal_exports.def|   9 +
 lib/librte_eal/windows/eal.c  |  63 ++--
 lib/librte_eal/windows/eal_mp.c   |  14 +
 lib/librte_eal/windows/include/rte_os.h   |   1 +
 lib/librte_eal/windows/include/rte_windows.h  |   1 +
 lib/librte_pci/rte_pci.c  |  10 +-
 lib/meson.build   |   5 +-
 30 files changed, 739 insertions(+), 122 deletions(-)
 create mode 100644 drivers/bus/pci/windows/pci.c
 create mode 100644 lib/librte_eal/common/eal_common_config.c

-- 
2.16.1.windows.4

[dpdk-dev] [PATCH v2 2/7] pci: build on Windows

[talshn]

From: Tal Shnaiderman 

Changing all of PCIs Unix memory mapping to the
new memory allocation API wrapper.

Added off_t in Windows header file as a supported
type since it is needed by PCI.

Signed-off-by: Tal Shnaiderman 
---
 lib/librte_eal/windows/include/rte_os.h |  1 +
 lib/librte_pci/rte_pci.c| 10 +-
 lib/meson.build |  5 -
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/lib/librte_eal/windows/include/rte_os.h 
b/lib/librte_eal/windows/include/rte_os.h
index 62805a307..1c433b976 100644
--- a/lib/librte_eal/windows/include/rte_os.h
+++ b/lib/librte_eal/windows/include/rte_os.h
@@ -48,6 +48,7 @@ extern "C" {
 
 /* as in  */
 typedef long long ssize_t;
+typedef long off_t;
 
 #ifndef RTE_TOOLCHAIN_GCC
 static inline int
diff --git a/lib/librte_pci/rte_pci.c b/lib/librte_pci/rte_pci.c
index d1ab6b414..5dc8b5a6f 100644
--- a/lib/librte_pci/rte_pci.c
+++ b/lib/librte_pci/rte_pci.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -138,9 +137,10 @@ pci_map_resource(void *requested_addr, int fd, off_t 
offset, size_t size,
void *mapaddr;
 
/* Map the PCI memory resource of device */
-   mapaddr = mmap(requested_addr, size, PROT_READ | PROT_WRITE,
-   MAP_SHARED | additional_flags, fd, offset);
-   if (mapaddr == MAP_FAILED) {
+   mapaddr = rte_mem_map(requested_addr, size,
+   RTE_PROT_READ | RTE_PROT_WRITE,
+   RTE_MAP_SHARED | additional_flags, fd, offset);
+   if (mapaddr == NULL) {
RTE_LOG(ERR, EAL,
"%s(): cannot mmap(%d, %p, 0x%zx, 0x%llx): %s (%p)\n",
__func__, fd, requested_addr, size,
@@ -160,7 +160,7 @@ pci_unmap_resource(void *requested_addr, size_t size)
return;
 
/* Unmap the PCI memory resource of device */
-   if (munmap(requested_addr, size)) {
+   if (rte_mem_unmap(requested_addr, size)) {
RTE_LOG(ERR, EAL, "%s(): cannot munmap(%p, %#zx): %s\n",
__func__, requested_addr, size,
strerror(errno));
diff --git a/lib/meson.build b/lib/meson.build
index 63c17ee75..a01bcf04d 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -33,7 +33,10 @@ libraries = [
'flow_classify', 'bpf', 'telemetry']
 
 if is_windows
-   libraries = ['kvargs','eal'] # only supported libraries for windows
+   libraries = [
+   'kvargs','eal',
+   'pci',
+   ] # only supported libraries for windows
 endif
 
 default_cflags = machine_args + ['-DALLOW_EXPERIMENTAL_API']
-- 
2.16.1.windows.4

[dpdk-dev] [PATCH v2 4/7] drivers: ignore pmdinfogen generation for Windows

[talshn]

From: Tal Shnaiderman 

pmdinfogen generation is currently unsupported for Windows.
The relevant part in meson.build is skipped.

Signed-off-by: Tal Shnaiderman 
---
 drivers/meson.build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/meson.build b/drivers/meson.build
index 4d8f842ab..a540117b6 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -107,6 +107,7 @@ foreach class:dpdk_driver_classes
 
dpdk_extra_ldflags += pkgconfig_extra_libs
 
+   if host_machine.system() != 'windows'
# generate pmdinfo sources by building a temporary
# lib and then running pmdinfogen on the contents of
# that lib. The final lib reuses the object files and
@@ -123,7 +124,7 @@ foreach class:dpdk_driver_classes
'@OUTPUT@', pmdinfogen],
output: out_filename,
depends: [pmdinfogen, tmp_lib])
-
+   endif
version_map = '@0@/@1@/@2@_version.map'.format(
meson.current_source_dir(),
drv_path, lib_name)
-- 
2.16.1.windows.4

[dpdk-dev] [PATCH v2 7/7] bus/pci: support Windows with bifurcated drivers

[talshn]

From: Tal Shnaiderman 

Uses SetupAPI.h functions to scan PCI tree.
Uses DEVPKEY_Device_Numa_Node to get the PCI Numa node.
scanning currently supports types RTE_KDRV_NONE.

Signed-off-by: Tal Shnaiderman 
---
 drivers/bus/pci/windows/pci.c| 342 ++-
 lib/librte_eal/rte_eal_exports.def   |   1 +
 lib/librte_eal/windows/include/rte_windows.h |   1 +
 3 files changed, 342 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/pci/windows/pci.c b/drivers/bus/pci/windows/pci.c
index d02bfce36..238312637 100644
--- a/drivers/bus/pci/windows/pci.c
+++ b/drivers/bus/pci/windows/pci.c
@@ -1,14 +1,24 @@
 /* SPDX-License-Identifier: BSD-3-Clause
  * Copyright 2020 Mellanox Technologies, Ltd
  */
+#include 
 #include 
 #include 
-
 #include 
 #include 
 
 #include "private.h"
 
+#include 
+
+#define  MAX_STR_TOKENS8
+#define  DEC   10
+#define  HEX   16
+/*
+ * This code is used to simulate a PCI probe by parsing information in
+ * the registry hive for PCI devices.
+ */
+
 /* The functions below are not implemented on Windows,
  * but need to be defined for compilation purposes
  */
@@ -167,6 +177,300 @@ pci_uio_remap_resource(struct rte_pci_device *dev 
__rte_unused)
 */
return -1;
 }
+
+static
+int get_device_resource_info(HDEVINFO hDevInfo,
+   PSP_DEVINFO_DATA pDeviceInfoData, struct rte_pci_device *dev)
+{
+   int  ret = -1;
+   DEVPROPTYPE uPropertyType;
+   DWORD uNumaNode;
+   BOOL  bResult;
+
+   switch (dev->kdrv) {
+   case RTE_KDRV_NONE:
+   /* Get NUMA node using DEVPKEY_Device_Numa_Node */
+   bResult = SetupDiGetDevicePropertyW(hDevInfo, pDeviceInfoData,
+   &DEVPKEY_Device_Numa_Node, &uPropertyType,
+   (BYTE *)&uNumaNode, sizeof(uNumaNode), NULL, 0);
+   if (!bResult) {
+   ret = GetLastError();
+   goto end;
+   }
+   dev->device.numa_node = uNumaNode;
+   /* mem_resource - Unneeded for RTE_KDRV_NONE */
+   dev->mem_resource[0].phys_addr = 0;
+   dev->mem_resource[0].len = 0;
+   dev->mem_resource[0].addr = NULL;
+   break;
+   default:
+   ret = ERROR_NOT_SUPPORTED;
+   goto end;
+   }
+
+   ret = ERROR_SUCCESS;
+end:
+   return ret;
+}
+
+
+/*
+ * split up a pci address into its constituent parts.
+ */
+static int
+parse_pci_addr_format(const char *buf, int bufsize, struct rte_pci_addr *addr)
+{
+   int ret = -1;
+
+   char *str[MAX_STR_TOKENS] = { 0 };
+
+   char *buf_copy = _strdup(buf);
+   if (buf_copy == NULL)
+   goto end;
+
+   /* PCI Addr format string is delimited by ',' */
+   /* eg: "PCI bus 5, device 35, function 0" */
+   if (rte_strsplit(buf_copy, bufsize, str, MAX_STR_TOKENS, ',')
+> MAX_STR_TOKENS - 1) {
+   goto end;
+   }
+
+   /* Bus, device and function values tokens in the str[] */
+   /* Convert to numerical values */
+   addr->domain = 0;
+   addr->bus = (uint8_t)rte_find_numerical_value(str[0], DEC);
+   addr->devid = (uint8_t)rte_find_numerical_value(str[1], DEC);
+   addr->function = (uint8_t)rte_find_numerical_value(str[2], DEC);
+
+   if (rte_errno != 0)
+   goto end;
+
+   ret = 0;
+end:
+   /* free the copy made (if any) with _tcsdup */
+   if (buf_copy)
+   free(buf_copy);
+   return ret;
+}
+
+static int
+parse_hardware_ids(char *str, unsigned int strlength, uint16_t *val1,
+   uint16_t *val2)
+{
+   int ret = -1;
+   char *strID[MAX_STR_TOKENS] = { 0 };
+
+   if (rte_strsplit(str, strlength, strID, MAX_STR_TOKENS, '_')
+> MAX_STR_TOKENS - 1) {
+   goto end;
+   }
+
+   /* check if string combined ID value (eg: subdeviceID+subvendorID) */
+   if (strlen(strID[1]) == 8) {
+   char strval1[8];
+   char strval2[8];
+   memset(strval1, 0, sizeof(strval1));
+   memset(strval2, 0, sizeof(strval2));
+
+   memcpy_s(strval1, sizeof(strval1), strID[1], 4);
+   memcpy_s(strval2, sizeof(strval2), strID[1]+4, 4);
+
+   if (val1)
+   *val1 = (uint16_t)rte_find_numerical_value(
+   strval1, HEX);
+   if (val2)
+   *val2 = (uint16_t)rte_find_numerical_value(
+   strval2, HEX);
+   } else {
+   if (val1)
+   *val1 = (uint16_t)rte_find_numerical_value(
+   strID[1], HEX);
+   }
+
+   if (rte_errno != 0)
+   goto end;
+
+   ret = 0;
+end:
+   return ret;
+}
+
+/*
+ * split up hardware ID into its cons

[dpdk-dev] [Bug 465] app/test compile failed with gcc and clang

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=465

Bug ID: 465
   Summary: app/test compile failed with gcc and clang
   Product: DPDK
   Version: 20.05
  Hardware: x86
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: testpmd
  Assignee: dev@dpdk.org
  Reporter: qimaix.x...@intel.com
  Target Milestone: ---

-Description---
build ./app/test failed on dpdk 20.05
-reproduce steps---
Steps:

 1. cd /root/dpdk
 2. export RTE_TARGET=x86_64-native-linuxapp-gcc;export RTE_SDK=`pwd`;make
install T=x86_64-native-linuxapp-gcc -j70
 3. sed -i -e 's/#define MAX_TRAFFIC_BURST  2048/#define
MAX_TRAFFIC_BURST  32/' app/test/test_pmd_perf.c
 4. sed -i -e 's/lpbk_mode = 1/lpbk_mode = 0/' app/test/test_pmd_perf.c
 5. rm -rf ./app/test/test_resource_c.res.o
 6. rm -rf ./app/test/test_resource_tar.res.o
 7. rm -rf ./app/test/test_pci_sysfs.res.o
 8. make -j 70 -C app/test

Output:

...
test_mbuf.c:2670:2: error: ‘rte_mbuf_dyn_dump’ is deprecated: Symbol is not yet
part of stable ABI [-Werror=deprecated-declarations]
rte_mbuf_dyn_dump(stdout);
^
In file included from test_mbuf.c:35:0:
/root/dpdk/x86_64-native-linuxapp-gcc/include/rte_mbuf_dyn.h:235:6: note:
declared here
void rte_mbuf_dyn_dump(FILE *out);
^
test_flow_classify.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’
[-Werror]
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
'test_flow_classify.o' failed
make: *** [test_flow_classify.o] Error 1
test_stack_perf.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’
[-Werror]
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
'test_stack_perf.o' failed
make: *** [test_stack_perf.o] Error 1
test_timer_secondary.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’
[-Werror]
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
'test_timer_secondary.o' failed
make: *** [test_timer_secondary.o] Error 1
test_stack.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’
[-Werror]
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target 'test_stack.o'
failed
make: *** [test_stack.o] Error 1
test_mbuf.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’
[-Werror]
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target 'test_mbuf.o'
failed
make: *** [test_mbuf.o] Error 1
test_ring_perf.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’
[-Werror]
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
'test_ring_perf.o' failed
make: *** [test_ring_perf.o] Error 1
test_ring.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’
[-Werror]
cc1: all warnings being treated as errors
/root/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target 'test_ring.o'
failed
make: *** [test_ring.o] Error 1

Comments: clang has the same issue with gcc

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [dpdk-dev] [PATCH 09/14] eal: close mem config on cleanup

[Burakov, Anatoly]

On 27-Apr-20 6:00 PM, Stephen Hemminger wrote:

On Mon, 27 Apr 2020 13:12:32 +0100
"Burakov, Anatoly"  wrote:


On 04-Jan-20 1:33 AM, Stephen Hemminger wrote:

Resolves file descriptor left open after rte_eal_cleanup.

Signed-off-by: Stephen Hemminger 
---
   lib/librte_eal/linux/eal/eal.c | 6 ++
   1 file changed, 6 insertions(+)

diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index 9ad81378f23c..e5c2a24322e9 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1346,6 +1346,12 @@ rte_eal_cleanup(void)
rte_mp_channel_cleanup();
eal_cleanup_config(&internal_config);
rte_eal_log_cleanup();
+
+   if (mem_cfg_fd != -1) {
+   close(mem_cfg_fd);
+   mem_cfg_fd = -1;
+   }
+
return 0;
   }
   
   


For the patch,

Acked-by: Anatoly Burakov 

However i think it's incomplete, as there are also memory-backing
fbarrays that are still mapped. Also, secondary processes have their own
shadow copies of the master page table located in the mem config, so
those should be destroyed on cleanup too.



This patch set was targeting things in stages. It is not complete, some of the
cleanups would be hard to do. Just getting the obvious things first.



Fair enough. You still got my ack :)

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH 3/3] ethdev: fix build warning on 64-bit value

[Thomas Monjalon]

27/04/2020 16:00, David Marchand:
> On Mon, Apr 27, 2020 at 3:47 PM Ananyev, Konstantin wrote:
> > From: dev  On Behalf Of David Marchand
> > > On Mon, Apr 27, 2020 at 3:34 PM Bruce Richardson
> > >  wrote:
> > > > On Mon, Apr 27, 2020 at 03:23:41PM +0200, David Marchand wrote:
> > > > > Building OVS with dpdk, sparse complains about 64-bit constant being
> > > > > passed as a normal integer that can't fit it:
> > > > > error: constant 0x is so big it is unsigned long
> > > > >
> > > > > Fixes: ecbc8570131d ("ethdev: add PFCP header to flow API")
> > > > >
> > > > > Signed-off-by: David Marchand 
> > > > > ---
> > > > > --- a/lib/librte_ethdev/rte_flow.h
> > > > > +++ b/lib/librte_ethdev/rte_flow.h
> > > > >  static const struct rte_flow_item_pfcp rte_flow_item_pfcp_mask = {
> > > > >   .s_field = 0x01,
> > > > > - .seid = RTE_BE64(0x),
> > > > > + .seid = RTE_BE64(UINT64_C(0x)),
> > > >
> > > > Rather than cast, why not put "ULL" at the end. If we are going to cast,
> > > > why not just put "-1" in to save some digits.
> > >
> > > I preferred this form in the hope future developers who want
> > > 0x0fff will copy/paste this.
> > >
> >
> > As I remember there should be UINT64_MAX in stdint.h.
> 
> Yes, we could go with:
> + .seid = RTE_BE64(UINT64_MAX),
> 
> And then next time, for any value like 0x0fff    (had to
> group the digits of what I had written), pretty sure we will miss this
> and I will catch it only when building ovs.

I agree with David (in general and especially here).

RTE_BE64 is required for static analyzers and is an explicit info.

UINT64_C is better than ULL suffix because it
- is generic
- gives size explicitly

UINT64_C(0x) is better than UINT64_MAX because
- rte_flow.h has a lot of bitmasks
- it is copy/paste safe

Acked-by: Thomas Monjalon 

Re: [dpdk-dev] [PATCH] common/mlx5: reduce size of netlink buffer

[Slava Ovsiienko]

> -Original Message-
> From: dev  On Behalf Of Stephen Hemminger
> Sent: Thursday, April 23, 2020 1:30
> To: dev@dpdk.org
> Cc: Stephen Hemminger ; Nélio Laranjeiro
> 
> Subject: [dpdk-dev] [PATCH] common/mlx5: reduce size of netlink buffer
> 
> Since the driver is just using netlink to receive acknowledgements for
> command requests, having a large (32K) buffer is unnecessary.

Not for acknowledgements only, it is also used to get the dumps for the MAC
addresses and Infiniband device ports, as we know dump operations might
merge replies into one large message, smaller buffer might prevent the
dump receiving. What do you think about the buffer allocation  on the device
initialization and storing that somewhere in the device structure?

With best regards,
Slava

> Allocating large buffers on stack will break in application is using smaller 
> per-
> thread stacks.
> 
> It looks like original code intended to use a smaller buffer for the read than
> the socket, so keep that set of defines.
> 
> Fixes: ccdcba53a3f4 ("net/mlx5: use Netlink to add/remove MAC addresses")
> Cc: nelio.laranje...@6wind.com
> Signed-off-by: Stephen Hemminger 
> ---
>  drivers/common/mlx5/mlx5_nl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/common/mlx5/mlx5_nl.c
> b/drivers/common/mlx5/mlx5_nl.c index d9f0d4129e35..847e78dbcea6
> 100644
> --- a/drivers/common/mlx5/mlx5_nl.c
> +++ b/drivers/common/mlx5/mlx5_nl.c
> @@ -28,7 +28,7 @@
> 
> 
>  /* Size of the buffer to receive kernel messages */ -#define
> MLX5_NL_BUF_SIZE (32 * 1024)
> +#define MLX5_NL_BUF_SIZE 4096
>  /* Send buffer size for the Netlink socket */  #define MLX5_SEND_BUF_SIZE
> 32768
>  /* Receive buffer size for the Netlink socket */ @@ -330,7 +330,7 @@
> mlx5_nl_recv(int nlsk_fd, uint32_t sn, int (*cb)(struct nlmsghdr *, void 
> *arg),
>void *arg)
>  {
>   struct sockaddr_nl sa;
> - char buf[MLX5_RECV_BUF_SIZE];
> + char buf[MLX5_NL_BUF_SIZE];
>   struct iovec iov = {
>   .iov_base = buf,
>   .iov_len = sizeof(buf),
> --
> 2.20.1

Re: [dpdk-dev] [PATCH] bus/pci: optimize pci device probe

[Jerin Jacob]

On Tue, Apr 28, 2020 at 2:21 PM David Marchand
 wrote:
>
> On Sun, Apr 26, 2020 at 10:06 PM Thomas Monjalon  wrote:
> >
> > 26/04/2020 20:41, Jerin Jacob:
> > > On Sun, Apr 26, 2020 at 11:38 PM Thomas Monjalon  
> > > wrote:
> > > >
> > > > 26/04/2020 19:38, jer...@marvell.com:
> > > > > From: Jerin Jacob 
> > > > >
> > > > > If the PCI device is not attached to any driver then there is no
> > > > > point in probing it. As an optimization, skip the PCI device probe if
> > > > > the PCI device driver of type RTE_KDRV_NONE.
> > > > >
> > > > > Signed-off-by: Jerin Jacob 
> > > > > ---
> > > > > Notes:
> > > > > --
> > > > > - virtio drivers does special treatment based on RTE_KDRV_UNKNOWN, 
> > > > > That is
> > > > > the reason allowing RTE_KDRV_UNKNOWN in this patch.
> > > > > - virio devices uses RTE_KDRV_UNKNOWN for some special meaning, IMO, 
> > > > > if it would
> > > > >   be better, if
> > > > > a) Introduce the KDRV for virio
> > > > > b) If the PCIe device of driver type NONE or UNKNOWN then not even 
> > > > > add in pci
> > > > > list
> > > > > in the scan, It will improve the boot time by avoiding operation on
> > > > > unwanted device like sorting the PCI devices, scanning it, probe it, 
> > > > > managing
> > > > > it etc.
> > > >
> > > > mlx4/mlx4 uses RTE_KDRV_UNKNOWN.
> > >
> > > OK.
> > >
> > > > > - Initial problem reported at http://patches.dpdk.org/patch/64999/ as
> > > > > boot time printf clutter on octeontx2 devices with a lot PCI devices 
> > > > > which are
> > > > > of type RTE_KDRV_NONE.
> > > >
> > > > Add a logtype for PCI driver and adjust log level accordingly
> > > > to your preferences.
> > > >
> > > > > @@ -271,6 +271,8 @@ pci_probe_all_drivers(struct rte_pci_device *dev)
> > > > >   FOREACH_DRIVER_ON_PCIBUS(dr) {
> > > > > + if (dev->kdrv == RTE_KDRV_NONE)
> > > > > + continue;
> > > > >   rc = rte_pci_probe_one_driver(dr, dev);
> > > >
> > > > Nack
> > >
> > > I understand mlx4/mlx5 is using RTE_KDRV_UNKNOWN, Here we are skipping
> > > the RTE_KDRV_NONE,
> > > What is the use case for probing the devices with RTE_KDRV_NONE?
> >
> > Maybe you are right. I don't remember the use case.
> > I think I remember these virtio and vmxnet3 PMD were not using UIO:
> > http://git.dpdk.org/old/virtio-net-pmd/tree/virtio_user.c
> > http://git.dpdk.org/old/vmxnet3-usermap/tree/pmd/vmxnet3.c
> >
> > We need to know which case is using following code:
> >
> > case RTE_KDRV_NONE:
> > #if defined(RTE_ARCH_X86)
> > ret = pci_ioport_map(dev, bar, p);
> > #endif
> > break;
> >
> > David, please could you refresh our memory?
>
> The in-tree virtio-net driver directly calls rte_pci_map_device /
> rte_pci_ioport_map depending on virtio legacy/modern modes.
> This is why the virtio pci driver does not ask for
> RTE_PCI_DRV_NEED_MAPPING to the pci bus.
>
>
> In ioport mode, there were two options for historical reasons because
> of the virtio driver you mention.
> This driver did not rely on uio, and this behavior was later merged to
> the current in-tree driver.
> It ended up (not clean) in the pci bus driver because virtio was the
> only user of this code.
>
>
> Removing this special case could break x86 applications running with
> legacy virtio.
>
>
> On the plus side, we have been announcing for some time in virtio:
> RTE_PMD_REGISTER_KMOD_DEP(net_virtio, "* igb_uio | uio_pci_generic | 
> vfio-pci");

What is to conclude?
# The In-tree virtio driver uses ""* igb_uio | uio_pci_generic |
vfio-pci"" driver as backend and it does not need RTE_KDRV_NONE?
OR
# The in-tree, legacy virtio(const struct virtio_pci_ops legacy_op)
can work without any kernel driver in the backend. So RTE_KDRV_NONE
need?




>
>
> --
> David Marchand
>

Re: [dpdk-dev] [PATCH v2] common/mlx5: fix uninitialized variable warning

[Slava Ovsiienko]

> -Original Message-
> From: dev  On Behalf Of Stephen Hemminger
> Sent: Thursday, April 23, 2020 1:32
> To: dev@dpdk.org
> Cc: Stephen Hemminger ; Matan Azrad
> 
> Subject: [dpdk-dev] [PATCH v2] common/mlx5: fix uninitialized variable
> warning
> 
> Gcc 8.3.0 (Debian 10) complains about unitilized variable.
> 
> [474/2122] Compiling C object
> 'drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_nl.
> c.o'.
> In file included from ../drivers/common/mlx5/mlx5_nl.h:12,
>  from ../drivers/common/mlx5/mlx5_nl.c:23:
> ../drivers/common/mlx5/mlx5_nl.c: In function ‘mlx5_nl_enable_roce_get’:
> ../drivers/common/mlx5/mlx5_common.h:68:2: warning: ‘cur_en’ may be
> used uninitialized in this function [-Wmaybe-uninitialized]
>   rte_log(RTE_LOG_ ## level, \
>   ^~~
> ../drivers/common/mlx5/mlx5_nl.c:1560:6: note: ‘cur_en’ was declared here
>   int cur_en;
>   ^~
> 
> The compiler is correct, this variable would only be set if kernel netlink
> response message contains the DEVLINK parameter that flags if ROCE is
> enabled.
> 
> Fixes: fa69eaef5f49 ("common/mlx5: support ROCE disable through Netlink")
> Cc: ma...@mellanox.com
> Signed-off-by: Stephen Hemminger 
Acked-by: Viacheslav Ovsiienko 

> ---
> v2 - add DCO
> 
>  drivers/common/mlx5/mlx5_nl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/common/mlx5/mlx5_nl.c
> b/drivers/common/mlx5/mlx5_nl.c index 847e78dbcea6..c6014c3ee0b3
> 100644
> --- a/drivers/common/mlx5/mlx5_nl.c
> +++ b/drivers/common/mlx5/mlx5_nl.c
> @@ -1557,7 +1557,7 @@ mlx5_nl_enable_roce_get(int nlsk_fd, int
> family_id, const char *pci_addr,
>   struct genlmsghdr *genl;
>   uint32_t sn = MLX5_NL_SN_GENERATE;
>   int ret;
> - int cur_en;
> + int cur_en = 0;
>   uint8_t buf[NLMSG_ALIGN(sizeof(struct nlmsghdr)) +
>   NLMSG_ALIGN(sizeof(struct genlmsghdr)) +
>   NLMSG_ALIGN(sizeof(struct nlattr)) * 4 +
> --
> 2.20.1

[dpdk-dev] [PATCH v1] vhost: fix mbuf allocation failures

[Sivaprasad Tummala]

vhost buffer allocation is successful for packets that fit
into a linear buffer. If it fails, vhost library is expected
to drop the current buffer descriptor and skip to the next.

The patch fixes the error scenario by skipping to next descriptor.
Note: Drop counters are not currently supported.

Signed-off-by: Sivaprasad Tummala 
---
 lib/librte_vhost/virtio_net.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index 37c47c7dc..b0d3a85c2 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -1688,6 +1688,7 @@ virtio_dev_tx_split(struct virtio_net *dev, struct 
vhost_virtqueue *vq,
 {
uint16_t i;
uint16_t free_entries;
+   uint16_t dropped = 0;
 
if (unlikely(dev->dequeue_zero_copy)) {
struct zcopy_mbuf *zmbuf, *next;
@@ -1751,8 +1752,19 @@ virtio_dev_tx_split(struct virtio_net *dev, struct 
vhost_virtqueue *vq,
update_shadow_used_ring_split(vq, head_idx, 0);
 
pkts[i] = virtio_dev_pktmbuf_alloc(dev, mbuf_pool, buf_len);
-   if (unlikely(pkts[i] == NULL))
+   if (unlikely(pkts[i] == NULL)) {
+   /*
+* mbuf allocation fails for jumbo packets with
+* linear buffer flag set. Drop this packet and
+* proceed with the next available descriptor to
+* avoid HOL blocking
+*/
+   VHOST_LOG_DATA(WARNING,
+   "Failed to allocate memory for mbuf. Packet 
dropped!\n");
+   dropped += 1;
+   i++;
break;
+   }
 
err = copy_desc_to_mbuf(dev, vq, buf_vec, nr_vec, pkts[i],
mbuf_pool);
@@ -1796,7 +1808,7 @@ virtio_dev_tx_split(struct virtio_net *dev, struct 
vhost_virtqueue *vq,
}
}
 
-   return i;
+   return (i - dropped);
 }
 
 static __rte_always_inline int
-- 
2.17.1

Re: [dpdk-dev] [PATCH 0/3] 20.05-rc1 fixes for OVS

[David Marchand]

On Mon, Apr 27, 2020 at 3:24 PM David Marchand
 wrote:
>
> Couple of fixes caught while checking OVS integration.
>
> David Marchand (3):
>   ring: fix build with -Wswitch-enum
>   eal: fix typo in endian conversion macros
>   ethdev: fix build warning on 64-bit value
>
>  lib/librte_eal/include/generic/rte_byteorder.h | 6 +++---
>  lib/librte_ethdev/rte_flow.h   | 2 +-
>  lib/librte_ring/rte_ring_peek.h| 8 
>  3 files changed, 12 insertions(+), 4 deletions(-)
>

Series applied.


-- 
David Marchand

Re: [dpdk-dev] [PATCH] net/ixgbe: fix status synchronization on BSD

[Huang, ZhiminX]

Tested-by: Huang, ZhiminX 

Regards,
HuangZhiMin



-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of zhihongx.p...@intel.com
Sent: Friday, April 17, 2020 11:52 AM
To: Ye, Xiaolong ; Lu, Wenzhuo ; 
Ananyev, Konstantin 
Cc: dev@dpdk.org; Peng, ZhihongX ; Wang, Liang-min 

Subject: [dpdk-dev] [PATCH] net/ixgbe: fix status synchronization on BSD

From: Peng Zhihong 

DPDK does not implement interrupt mechanism on BSD, so force NIC status 
synchronization.

Fixes: dc66e5fd01b9 (net/ixgbe: improve link state check on VF)
Cc: liang-min.w...@intel.com

Signed-off-by: Peng Zhihong 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 2c5797635..efd8aced4 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -4262,6 +4262,11 @@ ixgbe_dev_link_update_share(struct rte_eth_dev *dev,
if (wait_to_complete == 0 || dev->data->dev_conf.intr_conf.lsc != 0)
wait = 0;
 
+/* BSD has no interrupt mechanism, so force NIC status synchronization. 
+*/ #ifdef RTE_EXEC_ENV_FREEBSD
+   wait = 1;
+#endif
+
if (vf)
diag = ixgbevf_check_link(hw, &link_speed, &link_up, wait);
else
--
2.17.1

Re: [dpdk-dev] [PATCH v3 4/4] cfgfile: check flags value

[Bruce Richardson]

On Mon, Apr 27, 2020 at 04:16:25PM -0700, Stephen Hemminger wrote:
> All API's should check that they support the flag values
> passed. If an application passes an invalid flag it could
> cause problems in later ABI.
> 
> Signed-off-by: Stephen Hemminger 
> ---
Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v3 0/4] Enforce checking on flag values in API's

[Bruce Richardson]

On Mon, Apr 27, 2020 at 04:16:21PM -0700, Stephen Hemminger wrote:
> The DPDK API's are lax about checking for undefined flag values.
> This makes it impossible to add new bits to existing API's
> without causing ABI breakage. This means we end up doing unnecessary
> symbol versioning just to work around applications that might
> pass in naughty bits.
> 
> This is the DPDK analog of the Linux kernel openat() problem.
> Openat api was added but since kernel did not check flags it
> ended up that another syscall openat2() was necessary before
> the flags could be used.
> 
> v3 - define mask based on existing defines for ring and hash
> 
> Stephen Hemminger (4):
>   ring: future proof flag settings
>   hash: check flags on creation
>   stack: check flags on creation
>   cfgfile: check flags value
> 
>  lib/librte_cfgfile/rte_cfgfile.c  |  4 
>  lib/librte_hash/rte_cuckoo_hash.c | 14 ++
>  lib/librte_ring/rte_ring.c| 12 
>  lib/librte_stack/rte_stack.c  |  5 +
>  4 files changed, 35 insertions(+)
> 
I think this is a good idea to do in DPDK

Series-acked-by: Bruce Richardson 

Re: [dpdk-dev] [EXT] [PATCH] trace: fix build with gcc 10

[Sunil Kumar Kori]

>-Original Message-
>From: Phil Yang 
>Sent: Tuesday, April 28, 2020 12:30 PM
>To: Sunil Kumar Kori ; Jerin Jacob Kollanukkaran
>; dev@dpdk.org
>Cc: David Marchand ; Ruifeng Wang
>; Lijian Zhang ; nd
>; nd 
>Subject: RE: [EXT] [PATCH] trace: fix build with gcc 10
>
>From: Sunil Kumar Kori 
>Sent: Tuesday, April 28, 2020 11:49 AM
>To: Phil Yang ; jer...@marvell.com; dev@dpdk.org
>Cc: David Marchand ; Ruifeng Wang
>; Lijian Zhang ; nd
>
>Subject: [EXT] [PATCH] trace: fix build with gcc 10
>
>Sent from Workspace ONE Boxer
>On 27-Apr-2020 10:18 PM, Phil Yang  wrote:
>>
>> External Email
>>
>> --
>> GCC 10 compiling output:
>> eal_common_trace_utils.c: In function 'eal_trace_dir_args_save':
>> eal_common_trace_utils.c:290:24: error: '__builtin___sprintf_chk'   \
>>     may write a terminating nul past the end of the destination \
>>     [-Werror=format-overflow=]
>>   290 |  sprintf(dir_path, "%s/", optarg);
>>   |    ^
>>
>> Fixes: 8af866df8d8c ("trace: add trace directory configuration parameter")
>>
>Hello, there is one more thread going on regarding this. Please have a look on
>below patch.
>https://urldefense.proofpoint.com/v2/url?u=http-
>3A__patches.dpdk.org_patch_69382_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7x
>tfQ&r=dXeXaAMkP5COgn1zxHMyaF1_d9IIuq6vHQO6NrIPjaE&m=WFCcD0EavY
>uGMZUUoJWIQunwTAwgxAju2rK4s3Nr-t4&s=iMF8PSGMB8S-
>rDR0kJGOZ1el3MzeOKfxZQxX-Oyg54g&e=
>
>Hi Sunil,
>
>Sorry, I didn’t notice that. Thanks for the link.
>
>I have two points:
>1. Will this patch resolves both mentioned warnings/error in  patch 69382 ?
>[Phil] Yes, this patch resolved the same issue mentioned by David in patch
>69382.
>
>2. David has suggested another way of doing it. Please check that too.
>[Phil]  I think both David’s and my patches are correct.
>My patch can guarantee a correct ‘size’ information in snprinf(). It omits the
>memory allocation operation for the incorrect input arguments case.
>David’s suggestion resolves the potential directory copy fail issue and it 
>saves
>some memory space in the normal case. But it needs to allocate memory in
>the incorrect input case.
>
>So, I think we can bind these two patches together?
Make sense.
So can you please combine both the patches and share ?

>
>Thanks,
>Phil
>
>> Signed-off-by: Phil Yang 
>> Reviewed-by: Lijian Zhang 
>> Tested-by: Lijian Zhang 
>> ---
>>  lib/librte_eal/common/eal_common_trace_utils.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/librte_eal/common/eal_common_trace_utils.c
>b/lib/librte_eal/common/eal_common_trace_utils.c
>> index fce8892..c079642 100644
>> --- a/lib/librte_eal/common/eal_common_trace_utils.c
>> +++ b/lib/librte_eal/common/eal_common_trace_utils.c
>> @@ -276,7 +276,10 @@ eal_trace_dir_args_save(char const *optarg)
>>  return -EINVAL;
>>  }
>>
>> -   if (strlen(optarg) >= size) {
>> +   /* the specified trace directory name cannot
>> +    * exceed PATH_MAX-1.
>> +    */
>> +   if (strlen(optarg) >= (size - 1)) {
>>  trace_err("input string is too big");
>>  return -ENAMETOOLONG;
>>  }
>> --
>> 2.7.4
>>

Re: [dpdk-dev] [PATCH v3 0/4] Enforce checking on flag values in API's

[Ananyev, Konstantin]

> The DPDK API's are lax about checking for undefined flag values.
> This makes it impossible to add new bits to existing API's
> without causing ABI breakage. This means we end up doing unnecessary
> symbol versioning just to work around applications that might
> pass in naughty bits.
> 
> This is the DPDK analog of the Linux kernel openat() problem.
> Openat api was added but since kernel did not check flags it
> ended up that another syscall openat2() was necessary before
> the flags could be used.
> 
> v3 - define mask based on existing defines for ring and hash
> 
> Stephen Hemminger (4):
>   ring: future proof flag settings
>   hash: check flags on creation
>   stack: check flags on creation
>   cfgfile: check flags value
> 
>  lib/librte_cfgfile/rte_cfgfile.c  |  4 
>  lib/librte_hash/rte_cuckoo_hash.c | 14 ++
>  lib/librte_ring/rte_ring.c| 12 
>  lib/librte_stack/rte_stack.c  |  5 +
>  4 files changed, 35 insertions(+)
> 
> --

Series Acked-by: Konstantin Ananyev 

> 2.20.1

Re: [dpdk-dev] [PATCH v2 2/2] l3fwd-power: implement proper shutdown handling

[Xie, WeiX]

Tested-by:  Xie,WeiX < weix@intel.com>

Regards,
Xie Wei


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Anatoly Burakov
Sent: Tuesday, April 21, 2020 1:57 AM
To: dev@dpdk.org
Cc: Hunt, David ; Pattan, Reshma 
Subject: [dpdk-dev] [PATCH v2 2/2] l3fwd-power: implement proper shutdown 
handling

Currently, shutdown for l3fwd-power application is all over the place and may 
or may not happen either in the signal handler or in the main() function. Fix 
this so that the signal handler will only set the exit variable, thereby 
allowing all of the loops to end properly and proceed to deinitialize 
everything.

Signed-off-by: Anatoly Burakov 
Acked-by: David Hunt 
Reviewed-by: Reshma Pattan 
---

Notes:
v2:
- rebase on top of latest master

 examples/l3fwd-power/main.c | 74 -
 1 file changed, 40 insertions(+), 34 deletions(-)

diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c index 
be50ec049..293b3da4a 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -422,41 +422,10 @@ static int is_done(void)  static void  
signal_exit_now(int sigtype)  {
-   unsigned lcore_id;
-   unsigned int portid;
-   int ret;
-
-   if (sigtype == SIGINT) {
-   if (app_mode == APP_MODE_EMPTY_POLL ||
-   app_mode == APP_MODE_TELEMETRY)
-   quit_signal = true;
 
+   if (sigtype == SIGINT)
+   quit_signal = true;
 
-   for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
-   if (rte_lcore_is_enabled(lcore_id) == 0)
-   continue;
-
-   /* init power management library */
-   ret = rte_power_exit(lcore_id);
-   if (ret)
-   rte_exit(EXIT_FAILURE, "Power management "
-   "library de-initialization failed on "
-   "core%u\n", lcore_id);
-   }
-
-   if (app_mode != APP_MODE_EMPTY_POLL) {
-   RTE_ETH_FOREACH_DEV(portid) {
-   if ((enabled_port_mask & (1 << portid)) == 0)
-   continue;
-
-   rte_eth_dev_stop(portid);
-   rte_eth_dev_close(portid);
-   }
-   }
-   }
-
-   if (app_mode != APP_MODE_EMPTY_POLL)
-   rte_exit(EXIT_SUCCESS, "User forced exit\n");
 }
 
 /*  Freqency scale down timer callback */ @@ -1196,7 +1165,7 @@ 
main_loop(__rte_unused void *dummy)
else
RTE_LOG(INFO, L3FWD_POWER, "RX interrupt won't enable.\n");
 
-   while (1) {
+   while (!is_done()) {
stats[lcore_id].nb_iteration_looped++;
 
cur_tsc = rte_rdtsc();
@@ -1343,6 +1312,8 @@ main_loop(__rte_unused void *dummy)
stats[lcore_id].sleep_time += lcore_idle_hint;
}
}
+
+   return 0;
 }
 
 static int
@@ -2080,6 +2051,26 @@ init_power_library(void)
}
return ret;
 }
+
+static int
+deinit_power_library(void)
+{
+   unsigned int lcore_id;
+   int ret = 0;
+
+   RTE_LCORE_FOREACH(lcore_id) {
+   /* deinit power management library */
+   ret = rte_power_exit(lcore_id);
+   if (ret) {
+   RTE_LOG(ERR, POWER,
+   "Library deinitialization failed on core %u\n",
+   lcore_id);
+   return ret;
+   }
+   }
+   return ret;
+}
+
 static void
 update_telemetry(__rte_unused struct rte_timer *tim,
__rte_unused void *arg)
@@ -2530,8 +2521,23 @@ main(int argc, char **argv)
return -1;
}
 
+   RTE_ETH_FOREACH_DEV(portid)
+   {
+   if ((enabled_port_mask & (1 << portid)) == 0)
+   continue;
+
+   rte_eth_dev_stop(portid);
+   rte_eth_dev_close(portid);
+   }
+
if (app_mode == APP_MODE_EMPTY_POLL)
rte_power_empty_poll_stat_free();
 
+   if (app_mode != APP_MODE_TELEMETRY && deinit_power_library())
+   rte_exit(EXIT_FAILURE, "deinit_power_library failed\n");
+
+   if (rte_eal_cleanup() < 0)
+   RTE_LOG(ERR, L3FWD_POWER, "EAL cleanup failed\n");
+
return 0;
 }
--
2.17.1

Re: [dpdk-dev] [PATCH v2 1/2] l3fwd-power: exit if initializing power library failed

[Xie, WeiX]

Tested-by:  Xie,WeiX < weix@intel.com>

Regards,
Xie Wei


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Anatoly Burakov
Sent: Tuesday, April 21, 2020 1:57 AM
To: dev@dpdk.org
Cc: Hunt, David ; Pattan, Reshma 
Subject: [dpdk-dev] [PATCH v2 1/2] l3fwd-power: exit if initializing power 
library failed

Currently, if power library initialization fails, only a log message is 
displayed. This is suboptimal for a number of reasons, but the main one is that 
telemetry mode does not depend on the power library and can therefore run in 
environments where l3fwd-power would normally not run correctly (such as inside 
a VM). This will lead to attempts to deinitialize the power library on exit, 
with a subsequent forced unclean shutdown of DPDK.

Fix this by only initializing the power library in modes that actually need it, 
and change a log message to a failure to initialize.

Signed-off-by: Anatoly Burakov 
Acked-by: David Hunt 
Reviewed-by: Reshma Pattan 
---
 examples/l3fwd-power/main.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c index 
b46aa7bac..be50ec049 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -2065,15 +2065,17 @@ static int check_ptype(uint16_t portid)  static int
 init_power_library(void)
 {
-   int ret = 0, lcore_id;
-   for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
-   if (rte_lcore_is_enabled(lcore_id)) {
-   /* init power management library */
-   ret = rte_power_init(lcore_id);
-   if (ret)
-   RTE_LOG(ERR, POWER,
+   unsigned int lcore_id;
+   int ret = 0;
+
+   RTE_LCORE_FOREACH(lcore_id) {
+   /* init power management library */
+   ret = rte_power_init(lcore_id);
+   if (ret) {
+   RTE_LOG(ERR, POWER,
"Library initialization failed on core %u\n",
lcore_id);
+   return ret;
}
}
return ret;
@@ -2224,8 +2226,8 @@ main(int argc, char **argv)
if (ret < 0)
rte_exit(EXIT_FAILURE, "Invalid L3FWD parameters\n");
 
-   if (init_power_library())
-   RTE_LOG(ERR, L3FWD_POWER, "init_power_library failed\n");
+   if (app_mode != APP_MODE_TELEMETRY && init_power_library())
+   rte_exit(EXIT_FAILURE, "init_power_library failed\n");
 
if (update_lcore_params() < 0)
rte_exit(EXIT_FAILURE, "update_lcore_params failed\n");
--
2.17.1

[dpdk-dev] [PATCH V2] app/testpmd: fix forward stats after clear stats command

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

Currently, when running start/clear stats&xstats/stop command many times
based on testpmd application, there are incorrect forward Rx/Tx-packets
stats as below:
-- Forward statistics for port 0  --
RX-packets: 18446744073709544808 RX-dropped: 0
TX-packets: 18446744073709536616 TX-dropped: 0


The root cause as below:
1. The struct rte_port of testpmd.h has a member variable
   "struct rte_eth_stats stats" to store the last port statistics.
2. When runnig start command, it execute cmd_start_parsed ->
   start_packet_forwarding -> fwd_stats_reset, which call rte_eth_stats_get
   API function to save current port statistics.
3. When running stop command, it execute fwd_stats_display, which call
   rte_eth_stats_get to get current port statistics, and then minus last
   port statistics.
4. If we run clear stats or xstats after start command, then run stop,
   it may display above incorrect stats because the current Rx/Tx-packets
   is lower than the last saved RX/TX-packets(uint64_t overflow).

This patch fixes it by clearing last port statistics when executing
"clear stats/xstats" command.

Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org

Signed-off-by: Chengwen Feng 
Signed-off-by: Wei Hu (Xavier) 
---
v1 -> v2:
Update the title and the documentation
(doc/guides/testpmd_app_ug/testpmd_funcs.rst) based on
Ferruh Yigit's comment as below:
http://patches.dpdk.org/patch/69252/
---
 app/test-pmd/config.c   | 11 +++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 72f25d152..0d2375607 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -234,10 +234,16 @@ nic_stats_display(portid_t port_id)
 void
 nic_stats_clear(portid_t port_id)
 {
+   struct rte_port *port;
+
if (port_id_is_invalid(port_id, ENABLED_WARN)) {
print_valid_ports();
return;
}
+
+   port = &ports[port_id];
+   /* clear last port statistics because eth stats reset */
+   memset(&port->stats, 0, sizeof(port->stats));
rte_eth_stats_reset(port_id);
printf("\n  NIC statistics for port %d cleared\n", port_id);
 }
@@ -308,12 +314,17 @@ nic_xstats_display(portid_t port_id)
 void
 nic_xstats_clear(portid_t port_id)
 {
+   struct rte_port *port;
int ret;
 
if (port_id_is_invalid(port_id, ENABLED_WARN)) {
print_valid_ports();
return;
}
+
+   port = &ports[port_id];
+   /* clear last port statistics because eth xstats(include stats) reset */
+   memset(&port->stats, 0, sizeof(port->stats));
ret = rte_eth_xstats_reset(port_id);
if (ret != 0) {
printf("%s: Error: failed to reset xstats (port %u): %s",
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a360ecccf..ca83a2ab5 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -237,7 +237,7 @@ Display the RSS hash functions and RSS hash key of a port::
 clear port
 ~~
 
-Clear the port statistics for a given port or for all ports::
+Clear the port statistics and forward engine statistics for a given port or 
for all ports::
 
testpmd> clear port (info|stats|xstats|fdir|stat_qmap) (port_id|all)
 
-- 
2.23.0

[dpdk-dev] [PATCH V3] app/testpmd: fix forward stats after clear stats command

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

Currently, when running start/clear stats&xstats/stop command many times
based on testpmd application, there are incorrect forward Rx/Tx-packets
stats as below:
-- Forward statistics for port 0  --
RX-packets: 18446744073709544808 RX-dropped: 0
TX-packets: 18446744073709536616 TX-dropped: 0


The root cause as below:
1. The struct rte_port of testpmd.h has a member variable
   "struct rte_eth_stats stats" to store the last port statistics.
2. When runnig start command, it execute cmd_start_parsed ->
   start_packet_forwarding -> fwd_stats_reset, which call rte_eth_stats_get
   API function to save current port statistics.
3. When running stop command, it execute fwd_stats_display, which call
   rte_eth_stats_get to get current port statistics, and then minus last
   port statistics.
4. If we run clear stats or xstats after start command, then run stop,
   it may display above incorrect stats because the current Rx/Tx-packets
   is lower than the last saved RX/TX-packets(uint64_t overflow).

This patch fixes it by clearing last port statistics when executing
"clear stats/xstats" command.

Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org

Signed-off-by: Chengwen Feng 
Signed-off-by: Wei Hu (Xavier) 
---
v2 -> v3:
Replace memset operation with calling rte_eth_stats_get API
v1 -> v2:
Update the title and the documentation
(doc/guides/testpmd_app_ug/testpmd_funcs.rst) based on
Ferruh Yigit's comment as below:
http://patches.dpdk.org/patch/69252/
---
 app/test-pmd/config.c   | 26 -
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  2 +-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 72f25d152..712092fdb 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -234,11 +234,26 @@ nic_stats_display(portid_t port_id)
 void
 nic_stats_clear(portid_t port_id)
 {
+   int ret;
+
if (port_id_is_invalid(port_id, ENABLED_WARN)) {
print_valid_ports();
return;
}
-   rte_eth_stats_reset(port_id);
+
+   ret = rte_eth_stats_reset(port_id);
+   if (ret != 0) {
+   printf("%s: Error: failed to reset stats (port %u): %s",
+  __func__, port_id, strerror(ret));
+   return;
+   }
+
+   ret = rte_eth_stats_get(port_id, &ports[port_id].stats);
+   if (ret != 0) {
+   printf("%s: Error: failed to get stats (port %u): %s",
+  __func__, port_id, strerror(ret));
+   return;
+   }
printf("\n  NIC statistics for port %d cleared\n", port_id);
 }
 
@@ -314,10 +329,19 @@ nic_xstats_clear(portid_t port_id)
print_valid_ports();
return;
}
+
ret = rte_eth_xstats_reset(port_id);
if (ret != 0) {
printf("%s: Error: failed to reset xstats (port %u): %s",
   __func__, port_id, strerror(ret));
+   return;
+   }
+
+   ret = rte_eth_stats_get(port_id, &ports[port_id].stats);
+   if (ret != 0) {
+   printf("%s: Error: failed to get stats (port %u): %s",
+  __func__, port_id, strerror(ret));
+   return;
}
 }
 
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a360ecccf..ca83a2ab5 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -237,7 +237,7 @@ Display the RSS hash functions and RSS hash key of a port::
 clear port
 ~~
 
-Clear the port statistics for a given port or for all ports::
+Clear the port statistics and forward engine statistics for a given port or 
for all ports::
 
testpmd> clear port (info|stats|xstats|fdir|stat_qmap) (port_id|all)
 
-- 
2.23.0

Re: [dpdk-dev] [EXT] Re: [PATCH v4 1/4] ethdev: add tm support for shaper config in pkt mode

[Nithin Dabilpuram]

On Mon, Apr 27, 2020 at 10:29:48PM +0530, Jerin Jacob wrote:
> External Email
> 
> --
> On Mon, Apr 27, 2020 at 10:19 PM Ferruh Yigit  wrote:
> >
> > On 4/27/2020 5:29 PM, Jerin Jacob wrote:
> > > On Mon, Apr 27, 2020 at 9:42 PM Ferruh Yigit  
> > > wrote:
> > >>
> > >> On 4/27/2020 10:19 AM, Dumitrescu, Cristian wrote:
> > >>>
> > >>>
> >  -Original Message-
> >  From: Yigit, Ferruh 
> >  Sent: Saturday, April 25, 2020 9:09 PM
> >  To: Dumitrescu, Cristian ; Nithin 
> >  Dabilpuram
> >  ; Singh, Jasvinder ;
> >  Thomas Monjalon ; Andrew Rybchenko
> >  
> >  Cc: dev@dpdk.org; jer...@marvell.com; kka...@marvell.com; Nithin
> >  Dabilpuram 
> >  Subject: Re: [PATCH v4 1/4] ethdev: add tm support for shaper config 
> >  in pkt
> >  mode
> > 
> >  On 4/24/2020 11:28 AM, Dumitrescu, Cristian wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Nithin Dabilpuram 
> > >> Sent: Wednesday, April 22, 2020 6:21 PM
> > >> To: Singh, Jasvinder ; Dumitrescu, 
> > >> Cristian
> > >> ; Thomas Monjalon
> > >> ; Yigit, Ferruh ; Andrew
> > >> Rybchenko 
> > >> Cc: dev@dpdk.org; jer...@marvell.com; kka...@marvell.com; Nithin
> > >> Dabilpuram 
> > >> Subject: [PATCH v4 1/4] ethdev: add tm support for shaper config in 
> > >> pkt
> > >> mode
> > >>
> > >> From: Nithin Dabilpuram 
> > >>
> > >> Some NIC hardware support shaper to work in packet mode i.e
> > >> shaping or ratelimiting traffic is in packets per second (PPS) as
> > >> opposed to default bytes per second (BPS). Hence this patch
> > >> adds support to configure shared or private shaper in packet mode,
> > >> provide rate in PPS and add related tm capabilities in 
> > >> port/level/node
> > >> capability structures.
> > >>
> > >> This patch also updates tm port/level/node capability structures with
> > >> exiting features of scheduler wfq packet mode, scheduler wfq byte 
> > >> mode
> > >> and private/shared shaper byte mode.
> > >>
> > >> SoftNIC PMD is also updated with new capabilities.
> > >>
> > >> Signed-off-by: Nithin Dabilpuram 
> > >> ---
> > >> v3..v4:
> > >> - Update text under packet_mode as per Cristian.
> > >> - Update rte_eth_softnic_tm.c based on Jasvinder's comments.
> > >> - Add error enum
> >  RTE_TM_ERROR_TYPE_SHAPER_PROFILE_PACKET_MODE
> > >> - Fix shaper_profile_check() with packet mode check
> > >> - Fix typo's
> > >>
> > >
> > > Acked-by: Cristian Dumitrescu 
> > >
> > 
> >  Hi Nithin,
> > 
> >  It looks like patch is causing ABI break, I am getting following 
> >  warning [1],
> >  can you please check?
> > 
> >  [1]
> >  https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_XYNFg14u&d=DwIBaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=FZ_tPCbgFOh18zwRPO9H0yDx8VW38vuapifdDfc8SFQ&m=xJB0Qb2Q-1bl0hEDeknUjJqrCDc3z-h0F0e7kj8KvvI&s=R6xtRQRRIIzAilc5z52oYjyHNlvvJB_9SUsKBkpPC6g&e=
> >   
> > >>>
> > >>>
> > >>> Hi Ferruh,
> > >>>
> > >>> The RTE_TM API is marked as experimental, but it looks that this was 
> > >>> not correctly marked when __rte_experimental ABI checker was introduced.
> > >>>
> > >>> It is marked as experimental at the top of the rte_tm.h, similarly to 
> > >>> other APIs introduced around same time, but it was not correctly picked 
> > >>> up by the ABI check procedure when later introduced, so 
> > >>> __rte_experimental was not added to every function.
> > >>>
> > >>
> > >> :(
> > >>
> > >> Is it time to mature them?
> > >>
> > >> As you said they are not marked as experimental both in header file 
> > >> (function
> > >> declarations) and .map file.
> > >>
> > >> The problem is, they are not marked as experimental in DPDK_20.0 ABI 
> > >> (v19.11),
> > >> so marking them as experimental now will break the ABI. Not sure what to 
> > >> do,
> > >> cc'ed a few ABI related names for comment.
> > >>
> > >> For me, we need to proceed as the experimental tag removed and APIs 
> > >> become
> > >> mature starting from v19.11, since this is what happened in practice, 
> > >> and remove
> > >> a few existing being experimental references in the doxygen comments.
> > >
> > > I think, accidentally we can not make a library as NON-experimental.
> > > TM never went through experimental to mature transition(see git log
> > > lib/librte_ethdev/rte_tm.h)
> > > It was a bug to not mark as experimental in each function in the ABI 
> > > process.
> > > Some of the features like packet marking are not even implemented by any 
> > > HW.
> > > I think, we can make API stable only all the features are implemented
> > > by one or two HW.
> >
> > Fair enough, specially if the API is not ready yet.
> >
> > But they were part of stable ABI, and marking them as experimental now will
> > break the 

Re: [dpdk-dev] [PATCH v2 1/2] spinlock: use wfe to reduce contention on aarch64

[Jerin Jacob]

On Sun, Apr 26, 2020 at 2:09 PM Gavin Hu  wrote:
>
> In acquiring a spinlock, cores repeatedly poll the lock variable.
> This is replaced by rte_wait_until_equal API.
>
> Running the micro benchmarking and the testpmd and l3fwd traffic tests
> on ThunderX2, Ampere eMAG80 and Arm N1SDP, everything went well and no
> notable performance gain nor degradation was measured.
>
> Signed-off-by: Gavin Hu 
> Reviewed-by: Ruifeng Wang 
> Reviewed-by: Phil Yang 
> Reviewed-by: Steve Capper 
> Reviewed-by: Ola Liljedahl 
> Reviewed-by: Honnappa Nagarahalli 
> Tested-by: Pavan Nikhilesh 

Acked-by: Jerin Jacob 


> ---
>  lib/librte_eal/include/generic/rte_spinlock.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_eal/include/generic/rte_spinlock.h 
> b/lib/librte_eal/include/generic/rte_spinlock.h
> index 87ae7a4f1..40fe49d5a 100644
> --- a/lib/librte_eal/include/generic/rte_spinlock.h
> +++ b/lib/librte_eal/include/generic/rte_spinlock.h
> @@ -65,8 +65,8 @@ rte_spinlock_lock(rte_spinlock_t *sl)
>
> while (!__atomic_compare_exchange_n(&sl->locked, &exp, 1, 0,
> __ATOMIC_ACQUIRE, __ATOMIC_RELAXED)) {
> -   while (__atomic_load_n(&sl->locked, __ATOMIC_RELAXED))
> -   rte_pause();
> +   rte_wait_until_equal_32((volatile uint32_t *)&sl->locked,
> +  0, __ATOMIC_RELAXED);
> exp = 0;
> }
>  }
> --
> 2.17.1
>

[dpdk-dev] [PATCH v5] eal/cpuflags: add x86 based cpu flags

[Kevin Laatz]

This patch adds CPU flags which will enable the detection of ISA
features available on more recent x86 based CPUs.

The CPUID leaf information can be found in
Table 1-2. "Information Returned by CPUID Instruction" of this document:
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf

The following CPU flags are added in this patch:
- AVX-512 doubleword and quadword instructions.
- AVX-512 integer fused multiply-add instructions.
- AVX-512 conflict detection instructions.
- AVX-512 byte and word instructions.
- AVX-512 vector length instructions.
- AVX-512 vector bit manipulation instructions.
- AVX-512 vector bit manipulation 2 instructions.
- Galois field new instructions.
- Vector AES instructions.
- Vector carry-less multiply instructions.
- AVX-512 vector neural network instructions.
- AVX-512 for bit algorithm instructions.
- AVX-512 vector popcount instructions.
- Cache line demote instructions.
- Direct store instructions.
- Direct store 64B instructions.
- AVX-512 two register intersection instructions.

Signed-off-by: Kevin Laatz 
Acked-by: Harry van Haaren 

---
v2:
  - Squashed patch set into single patch.

v3:
  - Add abignore entry for 'rte_cpu_flag_t'.

v4:
  - Updated commit message to reflect updated ISA doc linked.
  - Fixed line wrap for VNNI comment.
  - Rebased on master.

v5:
  - Update abignore entry justification.
---
 devtools/libabigail.abignore  |  5 +
 lib/librte_eal/x86/include/rte_cpuflags.h | 19 +++
 lib/librte_eal/x86/rte_cpuflags.c | 18 ++
 3 files changed, 42 insertions(+)

diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index a59df8f13..045f436fb 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -11,3 +11,8 @@
 type_kind = enum
 name = rte_crypto_asym_xform_type
 changed_enumerators = RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
+; Ignore this enum update as new flags remain unknown to applications
+[suppress_type]
+   type_kind = enum
+   name = rte_cpu_flag_t
+   changed_enumerators = RTE_CPUFLAG_NUMFLAGS
diff --git a/lib/librte_eal/x86/include/rte_cpuflags.h 
b/lib/librte_eal/x86/include/rte_cpuflags.h
index 25ba47b96..c1d20364d 100644
--- a/lib/librte_eal/x86/include/rte_cpuflags.h
+++ b/lib/librte_eal/x86/include/rte_cpuflags.h
@@ -113,6 +113,25 @@ enum rte_cpu_flag_t {
/* (EAX 8007h) EDX features */
RTE_CPUFLAG_INVTSC, /**< INVTSC */
 
+   RTE_CPUFLAG_AVX512DQ,   /**< AVX512 Doubleword and Quadword 
*/
+   RTE_CPUFLAG_AVX512IFMA, /**< AVX512 Integer Fused 
Multiply-Add */
+   RTE_CPUFLAG_AVX512CD,   /**< AVX512 Conflict Detection*/
+   RTE_CPUFLAG_AVX512BW,   /**< AVX512 Byte and Word */
+   RTE_CPUFLAG_AVX512VL,   /**< AVX512 Vector Length */
+   RTE_CPUFLAG_AVX512VBMI, /**< AVX512 Vector Bit Manipulation 
*/
+   RTE_CPUFLAG_AVX512VBMI2,/**< AVX512 Vector Bit Manipulation 
2 */
+   RTE_CPUFLAG_GFNI,   /**< Galois Field New Instructions 
*/
+   RTE_CPUFLAG_VAES,   /**< Vector AES */
+   RTE_CPUFLAG_VPCLMULQDQ, /**< Vector Carry-less Multiply */
+   RTE_CPUFLAG_AVX512VNNI,
+   /**< AVX512 Vector Neural Network Instructions */
+   RTE_CPUFLAG_AVX512BITALG,   /**< AVX512 Bit Algorithms */
+   RTE_CPUFLAG_AVX512VPOPCNTDQ,/**< AVX512 Vector Popcount */
+   RTE_CPUFLAG_CLDEMOTE,   /**< Cache Line Demote */
+   RTE_CPUFLAG_MOVDIRI,/**< Direct Store Instructions */
+   RTE_CPUFLAG_MOVDIR64B,  /**< Direct Store Instructions 64B 
*/
+   RTE_CPUFLAG_AVX512VP2INTERSECT, /**< AVX512 Two Register 
Intersection */
+
/* The last item */
RTE_CPUFLAG_NUMFLAGS,   /**< This should always be the 
last! */
 };
diff --git a/lib/librte_eal/x86/rte_cpuflags.c 
b/lib/librte_eal/x86/rte_cpuflags.c
index 6492df556..30439e795 100644
--- a/lib/librte_eal/x86/rte_cpuflags.c
+++ b/lib/librte_eal/x86/rte_cpuflags.c
@@ -120,6 +120,24 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(EM64T, 0x8001, 0, RTE_REG_EDX, 29)
 
FEAT_DEF(INVTSC, 0x8007, 0, RTE_REG_EDX,  8)
+
+   FEAT_DEF(AVX512DQ, 0x0007, 0, RTE_REG_EBX, 17)
+   FEAT_DEF(AVX512IFMA, 0x0007, 0, RTE_REG_EBX, 21)
+   FEAT_DEF(AVX512CD, 0x0007, 0, RTE_REG_EBX, 28)
+   FEAT_DEF(AVX512BW, 0x0007, 0, RTE_REG_EBX, 30)
+   FEAT_DEF(AVX512VL, 0x0007, 0, RTE_REG_EBX, 31)
+   FEAT_DEF(AVX512VBMI, 0x0007, 0, RTE_REG_ECX, 1)
+   FEAT_DEF(AVX512VBMI2, 0x0007, 0, RTE_REG_ECX, 6)
+   FEAT_DEF(GFNI, 0x0007, 0, RTE_REG_ECX, 8)
+   FEAT_DEF(VAES, 0x0007, 0, R

[dpdk-dev] [PATCH v2 1/4] event/octeontx: add multi segment support to eventdev

[Harman Kalra]

Adding support for multi segment to the eventdev PMD.

Signed-off-by: Harman Kalra 
---
 drivers/event/octeontx/ssovf_evdev.c  | 33 +++---
 drivers/event/octeontx/ssovf_evdev.h  | 13 
 drivers/event/octeontx/ssovf_worker.c | 90 ---
 drivers/event/octeontx/ssovf_worker.h | 76 +++---
 4 files changed, 189 insertions(+), 23 deletions(-)

diff --git a/drivers/event/octeontx/ssovf_evdev.c 
b/drivers/event/octeontx/ssovf_evdev.c
index f9e93244f..1024b7284 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -146,15 +146,31 @@ ssovf_fastpath_fns_set(struct rte_eventdev *dev)
dev->enqueue_burst = ssows_enq_burst;
dev->enqueue_new_burst = ssows_enq_new_burst;
dev->enqueue_forward_burst = ssows_enq_fwd_burst;
-   dev->dequeue   = ssows_deq;
-   dev->dequeue_burst = ssows_deq_burst;
-   dev->txa_enqueue = sso_event_tx_adapter_enqueue;
-   dev->txa_enqueue_same_dest = dev->txa_enqueue;
 
-   if (edev->is_timeout_deq) {
-   dev->dequeue   = ssows_deq_timeout;
-   dev->dequeue_burst = ssows_deq_timeout_burst;
+   if (!!(edev->rx_offload_flags & OCCTX_RX_MULTI_SEG_F)) {
+   dev->dequeue   = ssows_deq_mseg;
+   dev->dequeue_burst = ssows_deq_burst_mseg;
+
+   if (edev->is_timeout_deq) {
+   dev->dequeue   = ssows_deq_timeout_mseg;
+   dev->dequeue_burst = ssows_deq_timeout_burst_mseg;
+   }
+   } else {
+   dev->dequeue   = ssows_deq;
+   dev->dequeue_burst = ssows_deq_burst;
+
+   if (edev->is_timeout_deq) {
+   dev->dequeue   = ssows_deq_timeout;
+   dev->dequeue_burst = ssows_deq_timeout_burst;
+   }
}
+
+   if (!!(edev->tx_offload_flags & OCCTX_TX_MULTI_SEG_F))
+   dev->txa_enqueue = sso_event_tx_adapter_enqueue_mseg;
+   else
+   dev->txa_enqueue = sso_event_tx_adapter_enqueue;
+
+   dev->txa_enqueue_same_dest = dev->txa_enqueue;
 }
 
 static void
@@ -411,6 +427,7 @@ ssovf_eth_rx_adapter_queue_add(const struct rte_eventdev 
*dev,
 {
int ret = 0;
const struct octeontx_nic *nic = eth_dev->data->dev_private;
+   struct ssovf_evdev *edev = ssovf_pmd_priv(dev);
pki_mod_qos_t pki_qos;
RTE_SET_USED(dev);
 
@@ -447,6 +464,8 @@ ssovf_eth_rx_adapter_queue_add(const struct rte_eventdev 
*dev,
ssovf_log_err("failed to modify QOS, port=%d, q=%d",
nic->port_id, queue_conf->ev.queue_id);
 
+   edev->rx_offload_flags = nic->rx_offload_flags;
+   edev->tx_offload_flags = nic->tx_offload_flags;
return ret;
 }
 
diff --git a/drivers/event/octeontx/ssovf_evdev.h 
b/drivers/event/octeontx/ssovf_evdev.h
index 0e622152c..1c3ae8556 100644
--- a/drivers/event/octeontx/ssovf_evdev.h
+++ b/drivers/event/octeontx/ssovf_evdev.h
@@ -12,6 +12,8 @@
 #include 
 #include 
 
+#include "octeontx_rxtx.h"
+
 #define EVENTDEV_NAME_OCTEONTX_PMD event_octeontx
 
 #define SSOVF_LOG(level, fmt, args...) \
@@ -132,6 +134,7 @@ enum ssovf_type {
 };
 
 struct ssovf_evdev {
+   OFFLOAD_FLAGS; /*Sequence should not be changed */
uint8_t max_event_queues;
uint8_t max_event_ports;
uint8_t is_timeout_deq;
@@ -175,6 +178,14 @@ uint16_t ssows_deq_timeout(void *port, struct rte_event 
*ev,
uint64_t timeout_ticks);
 uint16_t ssows_deq_timeout_burst(void *port, struct rte_event ev[],
uint16_t nb_events, uint64_t timeout_ticks);
+uint16_t ssows_deq_mseg(void *port, struct rte_event *ev,
+   uint64_t timeout_ticks);
+uint16_t ssows_deq_burst_mseg(void *port, struct rte_event ev[],
+   uint16_t nb_events, uint64_t timeout_ticks);
+uint16_t ssows_deq_timeout_mseg(void *port, struct rte_event *ev,
+   uint64_t timeout_ticks);
+uint16_t ssows_deq_timeout_burst_mseg(void *port, struct rte_event ev[],
+   uint16_t nb_events, uint64_t timeout_ticks);
 
 typedef void (*ssows_handle_event_t)(void *arg, struct rte_event ev);
 void ssows_flush_events(struct ssows *ws, uint8_t queue_id,
@@ -182,6 +193,8 @@ void ssows_flush_events(struct ssows *ws, uint8_t queue_id,
 void ssows_reset(struct ssows *ws);
 uint16_t sso_event_tx_adapter_enqueue(void *port,
struct rte_event ev[], uint16_t nb_events);
+uint16_t sso_event_tx_adapter_enqueue_mseg(void *port,
+   struct rte_event ev[], uint16_t nb_events);
 int ssovf_info(struct ssovf_info *info);
 void *ssovf_bar(enum ssovf_type, uint8_t id, uint8_t bar);
 int test_eventdev_octeontx(void);
diff --git a/drivers/event/octeontx/ssovf_worker.c 
b/drivers/event/octeontx/ssovf_worker.c
index ab34233d2..a811c2252 100644
--- a/drivers/event/octeontx/ssovf_worker.c
+++ b/drivers/event/octeontx/ssovf_worker.c
@@

[dpdk-dev] [PATCH v2 0/4] event/octeontx: support new features

[Harman Kalra]

Since event-octeontx PMD and net-octeontx PMD works very
tightly, so this patchset implements the event-octeontx
side changes to support new features added to net-octeontx
PMD.

v2:
* replace __hot with __rte_hot

Harman Kalra (3):
  event/octeontx: add multi segment support to eventdev
  event/octeontx: add framework for Rx/Tx offloads
  event/octeontx: support Rx Tx checksum offload

Vamsi Attunuru (1):
  event/octeontx: add VLAN filter offload support

 drivers/event/octeontx/ssovf_evdev.c  |  24 +-
 drivers/event/octeontx/ssovf_evdev.h  |  19 +-
 drivers/event/octeontx/ssovf_worker.c | 304 +-
 drivers/event/octeontx/ssovf_worker.h | 125 ++-
 drivers/net/octeontx/octeontx_rxtx.h  |  17 ++
 5 files changed, 395 insertions(+), 94 deletions(-)

-- 
2.18.0

[dpdk-dev] [PATCH v2 3/4] event/octeontx: add VLAN filter offload support

[Harman Kalra]

From: Vamsi Attunuru 

Adding rx burst function pointer hooks for vlan filter
offload in event PMD.

Signed-off-by: Vamsi Attunuru 
---
 drivers/event/octeontx/ssovf_worker.c | 38 +++
 drivers/event/octeontx/ssovf_worker.h |  9 +++
 drivers/net/octeontx/octeontx_rxtx.h  | 11 +---
 3 files changed, 37 insertions(+), 21 deletions(-)

diff --git a/drivers/event/octeontx/ssovf_worker.c 
b/drivers/event/octeontx/ssovf_worker.c
index b5873c3fa..a276269d7 100644
--- a/drivers/event/octeontx/ssovf_worker.c
+++ b/drivers/event/octeontx/ssovf_worker.c
@@ -91,7 +91,7 @@ ssows_release_event(struct ssows *ws)
ssows_swtag_untag(ws);
 }
 
-#define R(name, f0, flags)  \
+#define R(name, f1, f0, flags)  \
 static uint16_t __rte_noinline __rte_hot\
 ssows_deq_ ##name(void *port, struct rte_event *ev, uint64_t timeout_ticks)  \
 {   \
@@ -347,49 +347,53 @@ SSO_TX_ADPTR_ENQ_FASTPATH_FUNC
dev->txa_enqueue_same_dest = dev->txa_enqueue;
 
/* Assigning dequeue func pointers */
-   const event_dequeue_t ssow_deq[2] = {
-#define R(name, f0, flags) \
-   [f0] =  ssows_deq_ ##name,
+   const event_dequeue_t ssow_deq[2][2] = {
+#define R(name, f1, f0, flags) \
+   [f1][f0] =  ssows_deq_ ##name,
 
 SSO_RX_ADPTR_ENQ_FASTPATH_FUNC
 #undef R
};
 
dev->dequeue = ssow_deq
+   [!!(edev->rx_offload_flags & OCCTX_RX_VLAN_FLTR_F)]
[!!(edev->rx_offload_flags & OCCTX_RX_MULTI_SEG_F)];
 
-   const event_dequeue_burst_t ssow_deq_burst[2] = {
-#define R(name, f0, flags) \
-   [f0] =  ssows_deq_burst_ ##name,
+   const event_dequeue_burst_t ssow_deq_burst[2][2] = {
+#define R(name, f1, f0, flags) \
+   [f1][f0] =  ssows_deq_burst_ ##name,
 
 SSO_RX_ADPTR_ENQ_FASTPATH_FUNC
 #undef R
};
 
dev->dequeue_burst = ssow_deq_burst
+   [!!(edev->rx_offload_flags & OCCTX_RX_VLAN_FLTR_F)]
[!!(edev->rx_offload_flags & OCCTX_RX_MULTI_SEG_F)];
 
if (edev->is_timeout_deq) {
-   const event_dequeue_t ssow_deq_timeout[2] = {
-#define R(name, f0, flags) \
-   [f0] =  ssows_deq_timeout_ ##name,
+   const event_dequeue_t ssow_deq_timeout[2][2] = {
+#define R(name, f1, f0, flags) \
+   [f1][f0] =  ssows_deq_timeout_ ##name,
 
 SSO_RX_ADPTR_ENQ_FASTPATH_FUNC
 #undef R
};
 
-   dev->dequeue = ssow_deq_timeout
-   [!!(edev->rx_offload_flags & OCCTX_RX_MULTI_SEG_F)];
+   dev->dequeue = ssow_deq_timeout
+   [!!(edev->rx_offload_flags & OCCTX_RX_VLAN_FLTR_F)]
+   [!!(edev->rx_offload_flags & OCCTX_RX_MULTI_SEG_F)];
 
-   const event_dequeue_burst_t ssow_deq_timeout_burst[2] = {
-#define R(name, f0, flags) \
-   [f0] =  ssows_deq_timeout_burst_ ##name,
+   const event_dequeue_burst_t ssow_deq_timeout_burst[2][2] = {
+#define R(name, f1, f0, flags) \
+   [f1][f0] =  ssows_deq_timeout_burst_ ##name,
 
 SSO_RX_ADPTR_ENQ_FASTPATH_FUNC
 #undef R
};
 
-   dev->dequeue_burst = ssow_deq_timeout_burst
-   [!!(edev->rx_offload_flags & OCCTX_RX_MULTI_SEG_F)];
+   dev->dequeue_burst = ssow_deq_timeout_burst
+   [!!(edev->rx_offload_flags & OCCTX_RX_VLAN_FLTR_F)]
+   [!!(edev->rx_offload_flags & OCCTX_RX_MULTI_SEG_F)];
}
 }
diff --git a/drivers/event/octeontx/ssovf_worker.h 
b/drivers/event/octeontx/ssovf_worker.h
index 0eacec69a..b2bcc27c3 100644
--- a/drivers/event/octeontx/ssovf_worker.h
+++ b/drivers/event/octeontx/ssovf_worker.h
@@ -80,6 +80,15 @@ ssovf_octeontx_wqe_to_pkt(uint64_t work, uint16_t port_info,
mbuf->data_len = mbuf->pkt_len;
}
 
+   if (!!(flag & OCCTX_RX_VLAN_FLTR_F)) {
+   if (likely(wqe->s.w2.vv)) {
+   mbuf->ol_flags |= PKT_RX_VLAN;
+   mbuf->vlan_tci =
+   ntohs(*((uint16_t *)((char *)mbuf->buf_addr +
+   mbuf->data_off + wqe->s.w4.vlptr + 2)));
+   }
+   }
+
mbuf->port = rte_octeontx_pchan_map[port_info >> 4][port_info & 0xF];
rte_mbuf_refcnt_set(mbuf, 1);
 
diff --git a/drivers/net/octeontx/octeontx_rxtx.h 
b/drivers/net/octeontx/octeontx_rxtx.h
index 144ae055b..3f2147a02 100644
--- a/drivers/net/octeontx/octeontx_rxtx.h
+++ b/drivers/net/octeontx/octeontx_rxtx.h
@@ -485,10 +485,13 @@ T(noff

[dpdk-dev] [PATCH v2 2/4] event/octeontx: add framework for Rx/Tx offloads

[Harman Kalra]

Adding macro based framework to hook dequeue/enqueue function
pointers to the appropriate function based on rx/tx offloads.

Signed-off-by: Harman Kalra 
---
 drivers/event/octeontx/ssovf_evdev.c  |  36 
 drivers/event/octeontx/ssovf_evdev.h  |  24 +--
 drivers/event/octeontx/ssovf_worker.c | 259 ++
 drivers/net/octeontx/octeontx_rxtx.h  |   7 +
 4 files changed, 150 insertions(+), 176 deletions(-)

diff --git a/drivers/event/octeontx/ssovf_evdev.c 
b/drivers/event/octeontx/ssovf_evdev.c
index 1024b7284..5d074bcbc 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -137,42 +137,6 @@ ssovf_mbox_timeout_ticks(uint64_t ns, uint64_t *tmo_ticks)
return 0;
 }
 
-static void
-ssovf_fastpath_fns_set(struct rte_eventdev *dev)
-{
-   struct ssovf_evdev *edev = ssovf_pmd_priv(dev);
-
-   dev->enqueue   = ssows_enq;
-   dev->enqueue_burst = ssows_enq_burst;
-   dev->enqueue_new_burst = ssows_enq_new_burst;
-   dev->enqueue_forward_burst = ssows_enq_fwd_burst;
-
-   if (!!(edev->rx_offload_flags & OCCTX_RX_MULTI_SEG_F)) {
-   dev->dequeue   = ssows_deq_mseg;
-   dev->dequeue_burst = ssows_deq_burst_mseg;
-
-   if (edev->is_timeout_deq) {
-   dev->dequeue   = ssows_deq_timeout_mseg;
-   dev->dequeue_burst = ssows_deq_timeout_burst_mseg;
-   }
-   } else {
-   dev->dequeue   = ssows_deq;
-   dev->dequeue_burst = ssows_deq_burst;
-
-   if (edev->is_timeout_deq) {
-   dev->dequeue   = ssows_deq_timeout;
-   dev->dequeue_burst = ssows_deq_timeout_burst;
-   }
-   }
-
-   if (!!(edev->tx_offload_flags & OCCTX_TX_MULTI_SEG_F))
-   dev->txa_enqueue = sso_event_tx_adapter_enqueue_mseg;
-   else
-   dev->txa_enqueue = sso_event_tx_adapter_enqueue;
-
-   dev->txa_enqueue_same_dest = dev->txa_enqueue;
-}
-
 static void
 ssovf_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *dev_info)
 {
diff --git a/drivers/event/octeontx/ssovf_evdev.h 
b/drivers/event/octeontx/ssovf_evdev.h
index 1c3ae8556..1f5066c9a 100644
--- a/drivers/event/octeontx/ssovf_evdev.h
+++ b/drivers/event/octeontx/ssovf_evdev.h
@@ -14,6 +14,9 @@
 
 #include "octeontx_rxtx.h"
 
+#define SSO_RX_ADPTR_ENQ_FASTPATH_FUNC OCCTX_RX_FASTPATH_MODES
+#define SSO_TX_ADPTR_ENQ_FASTPATH_FUNC OCCTX_TX_FASTPATH_MODES
+
 #define EVENTDEV_NAME_OCTEONTX_PMD event_octeontx
 
 #define SSOVF_LOG(level, fmt, args...) \
@@ -171,32 +174,13 @@ uint16_t ssows_enq_new_burst(void *port,
const struct rte_event ev[], uint16_t nb_events);
 uint16_t ssows_enq_fwd_burst(void *port,
const struct rte_event ev[], uint16_t nb_events);
-uint16_t ssows_deq(void *port, struct rte_event *ev, uint64_t timeout_ticks);
-uint16_t ssows_deq_burst(void *port, struct rte_event ev[],
-   uint16_t nb_events, uint64_t timeout_ticks);
-uint16_t ssows_deq_timeout(void *port, struct rte_event *ev,
-   uint64_t timeout_ticks);
-uint16_t ssows_deq_timeout_burst(void *port, struct rte_event ev[],
-   uint16_t nb_events, uint64_t timeout_ticks);
-uint16_t ssows_deq_mseg(void *port, struct rte_event *ev,
-   uint64_t timeout_ticks);
-uint16_t ssows_deq_burst_mseg(void *port, struct rte_event ev[],
-   uint16_t nb_events, uint64_t timeout_ticks);
-uint16_t ssows_deq_timeout_mseg(void *port, struct rte_event *ev,
-   uint64_t timeout_ticks);
-uint16_t ssows_deq_timeout_burst_mseg(void *port, struct rte_event ev[],
-   uint16_t nb_events, uint64_t timeout_ticks);
-
 typedef void (*ssows_handle_event_t)(void *arg, struct rte_event ev);
 void ssows_flush_events(struct ssows *ws, uint8_t queue_id,
ssows_handle_event_t fn, void *arg);
 void ssows_reset(struct ssows *ws);
-uint16_t sso_event_tx_adapter_enqueue(void *port,
-   struct rte_event ev[], uint16_t nb_events);
-uint16_t sso_event_tx_adapter_enqueue_mseg(void *port,
-   struct rte_event ev[], uint16_t nb_events);
 int ssovf_info(struct ssovf_info *info);
 void *ssovf_bar(enum ssovf_type, uint8_t id, uint8_t bar);
 int test_eventdev_octeontx(void);
+void ssovf_fastpath_fns_set(struct rte_eventdev *dev);
 
 #endif /* __SSOVF_EVDEV_H__ */
diff --git a/drivers/event/octeontx/ssovf_worker.c 
b/drivers/event/octeontx/ssovf_worker.c
index a811c2252..b5873c3fa 100644
--- a/drivers/event/octeontx/ssovf_worker.c
+++ b/drivers/event/octeontx/ssovf_worker.c
@@ -91,112 +91,62 @@ ssows_release_event(struct ssows *ws)
ssows_swtag_untag(ws);
 }
 
-__rte_always_inline uint16_t __rte_hot
-ssows_deq(void *port, struct rte_event *ev, uint64_t timeout_ticks)
-{
-   struct ssows *ws = port;
-
-   RTE_SET_USED(timeout_ticks);
-
-   if (ws->swtag_req) {
-

[dpdk-dev] [PATCH v2 4/4] event/octeontx: support Rx Tx checksum offload

[Harman Kalra]

Adding support for rx checksum offload. In case of wrong
checksum received (inner/outer l3/l4) it reports the
corresponding layer which has bad checksum. It also adds
rx burst function pointer hook for rx checksum offload to
event PMD.

Signed-off-by: Harman Kalra 
---
 drivers/event/octeontx/ssovf_evdev.c  |   1 +
 drivers/event/octeontx/ssovf_evdev.h  |   2 +
 drivers/event/octeontx/ssovf_worker.c | 127 ++
 drivers/event/octeontx/ssovf_worker.h |  44 -
 drivers/net/octeontx/octeontx_rxtx.h  |  17 +++-
 5 files changed, 168 insertions(+), 23 deletions(-)

diff --git a/drivers/event/octeontx/ssovf_evdev.c 
b/drivers/event/octeontx/ssovf_evdev.c
index 5d074bcbc..1b1a5d939 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -272,6 +272,7 @@ ssovf_port_setup(struct rte_eventdev *dev, uint8_t port_id,
reg_off |= 1 << 16; /* Wait */
ws->getwork = ws->base + reg_off;
ws->port = port_id;
+   ws->lookup_mem = octeontx_fastpath_lookup_mem_get();
 
for (q = 0; q < edev->nb_event_queues; q++) {
ws->grps[q] = ssovf_bar(OCTEONTX_SSO_GROUP, q, 2);
diff --git a/drivers/event/octeontx/ssovf_evdev.h 
b/drivers/event/octeontx/ssovf_evdev.h
index 1f5066c9a..aa5acf246 100644
--- a/drivers/event/octeontx/ssovf_evdev.h
+++ b/drivers/event/octeontx/ssovf_evdev.h
@@ -157,6 +157,7 @@ struct ssows {
uint8_t *getwork;
uint8_t *grps[SSO_MAX_VHGRP];
uint8_t port;
+   void *lookup_mem;
 } __rte_cache_aligned;
 
 static inline struct ssovf_evdev *
@@ -182,5 +183,6 @@ int ssovf_info(struct ssovf_info *info);
 void *ssovf_bar(enum ssovf_type, uint8_t id, uint8_t bar);
 int test_eventdev_octeontx(void);
 void ssovf_fastpath_fns_set(struct rte_eventdev *dev);
+void *octeontx_fastpath_lookup_mem_get(void);
 
 #endif /* __SSOVF_EVDEV_H__ */
diff --git a/drivers/event/octeontx/ssovf_worker.c 
b/drivers/event/octeontx/ssovf_worker.c
index a276269d7..d2d5eea8f 100644
--- a/drivers/event/octeontx/ssovf_worker.c
+++ b/drivers/event/octeontx/ssovf_worker.c
@@ -91,7 +91,7 @@ ssows_release_event(struct ssows *ws)
ssows_swtag_untag(ws);
 }
 
-#define R(name, f1, f0, flags)  \
+#define R(name, f2, f1, f0, flags)  \
 static uint16_t __rte_noinline __rte_hot\
 ssows_deq_ ##name(void *port, struct rte_event *ev, uint64_t timeout_ticks)  \
 {   \
@@ -238,7 +238,8 @@ ssows_flush_events(struct ssows *ws, uint8_t queue_id,
ev.mbuf = ssovf_octeontx_wqe_to_pkt(get_work1,
(ev.event >> 20) & 0x7F,
OCCTX_RX_OFFLOAD_NONE |
-   OCCTX_RX_MULTI_SEG_F);
+   OCCTX_RX_MULTI_SEG_F,
+   ws->lookup_mem);
else
ev.u64 = get_work1;
 
@@ -340,16 +341,16 @@ SSO_TX_ADPTR_ENQ_FASTPATH_FUNC
 
dev->txa_enqueue = ssow_txa_enqueue
[!!(edev->tx_offload_flags & OCCTX_TX_OFFLOAD_MBUF_NOFF_F)]
-   [0]
-   [0]
+   [!!(edev->tx_offload_flags & OCCTX_TX_OFFLOAD_OL3_OL4_CSUM_F)]
+   [!!(edev->tx_offload_flags & OCCTX_TX_OFFLOAD_L3_L4_CSUM_F)]
[!!(edev->tx_offload_flags & OCCTX_TX_MULTI_SEG_F)];
 
dev->txa_enqueue_same_dest = dev->txa_enqueue;
 
/* Assigning dequeue func pointers */
-   const event_dequeue_t ssow_deq[2][2] = {
-#define R(name, f1, f0, flags) \
-   [f1][f0] =  ssows_deq_ ##name,
+   const event_dequeue_t ssow_deq[2][2][2] = {
+#define R(name, f2, f1, f0, flags) \
+   [f2][f1][f0] =  ssows_deq_ ##name,
 
 SSO_RX_ADPTR_ENQ_FASTPATH_FUNC
 #undef R
@@ -357,11 +358,12 @@ SSO_RX_ADPTR_ENQ_FASTPATH_FUNC
 
dev->dequeue = ssow_deq
[!!(edev->rx_offload_flags & OCCTX_RX_VLAN_FLTR_F)]
+   [!!(edev->rx_offload_flags & OCCTX_RX_OFFLOAD_CSUM_F)]
[!!(edev->rx_offload_flags & OCCTX_RX_MULTI_SEG_F)];
 
-   const event_dequeue_burst_t ssow_deq_burst[2][2] = {
-#define R(name, f1, f0, flags) \
-   [f1][f0] =  ssows_deq_burst_ ##name,
+   const event_dequeue_burst_t ssow_deq_burst[2][2][2] = {
+#define R(name, f2, f1, f0, flags) \
+   [f2][f1][f0] =  ssows_deq_burst_ ##name,
 
 SSO_RX_ADPTR_ENQ_FASTPATH_FUNC
 #undef R
@@ -369,12 +371,13 @@ SSO_RX_ADPTR_ENQ_FASTPATH_FUNC
 
dev->dequeue_burst = ssow_deq_burst
[!!(edev->rx_offload_flags & OCCTX_RX_VLAN_FLTR_F)]
+   [!!(edev->rx_offload_flags & OCCTX_RX_OFFLOAD_CSUM_F)]
[

Re: [dpdk-dev] [PATCH v3 1/2] vhost: utilize dpdk dynamic memory allocator

[Maxime Coquelin]

On 4/28/20 11:13 AM, Marvin Liu wrote:
> Replace dynamic memory allocator with dpdk memory allocator.
> 
> Signed-off-by: Marvin Liu 
> 


Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

Re: [dpdk-dev] [PATCH v10 6/9] net/virtio: add vectorized packed ring Rx path

[Liu, Yong]

> -Original Message-
> From: Maxime Coquelin 
> Sent: Tuesday, April 28, 2020 4:44 PM
> To: Liu, Yong ; Ye, Xiaolong ;
> Wang, Zhihong 
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v10 6/9] net/virtio: add vectorized packed ring Rx path
> 
> 
> 
> On 4/28/20 3:14 AM, Liu, Yong wrote:
> >
> >
> >> -Original Message-
> >> From: Maxime Coquelin 
> >> Sent: Monday, April 27, 2020 7:21 PM
> >> To: Liu, Yong ; Ye, Xiaolong
> ;
> >> Wang, Zhihong 
> >> Cc: dev@dpdk.org
> >> Subject: Re: [PATCH v10 6/9] net/virtio: add vectorized packed ring Rx
> path
> >>
> >>
> >>
> >> On 4/26/20 4:19 AM, Marvin Liu wrote:
> >>> Optimize packed ring Rx path with SIMD instructions. Solution of
> >>> optimization is pretty like vhost, is that split path into batch and
> >>> single functions. Batch function is further optimized by AVX512
> >>> instructions. Also pad desc extra structure to 16 bytes aligned, thus
> >>> four elements will be saved in one batch.
> >>>
> >>> Signed-off-by: Marvin Liu 
> >>>
> >>> diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
> >>> index c9edb84ee..102b1deab 100644
> >>> --- a/drivers/net/virtio/Makefile
> >>> +++ b/drivers/net/virtio/Makefile
> >>> @@ -36,6 +36,41 @@ else ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM)
> >> $(CONFIG_RTE_ARCH_ARM64)),)
> >>>  SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) +=
> virtio_rxtx_simple_neon.c
> >>>  endif
> >>>
> >>> +ifneq ($(FORCE_DISABLE_AVX512), y)
> >>> + CC_AVX512_SUPPORT=\
> >>> + $(shell $(CC) -march=native -dM -E - &1 | \
> >>> + sed '/./{H;$$!d} ; x ; /AVX512F/!d; /AVX512BW/!d; /AVX512VL/!d' | \
> >>> + grep -q AVX512 && echo 1)
> >>> +endif
> >>> +
> >>> +ifeq ($(CC_AVX512_SUPPORT), 1)
> >>> +CFLAGS += -DCC_AVX512_SUPPORT
> >>> +SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_packed_avx.c
> >>> +
> >>> +ifeq ($(RTE_TOOLCHAIN), gcc)
> >>> +ifeq ($(shell test $(GCC_VERSION) -ge 83 && echo 1), 1)
> >>> +CFLAGS += -DVIRTIO_GCC_UNROLL_PRAGMA
> >>> +endif
> >>> +endif
> >>> +
> >>> +ifeq ($(RTE_TOOLCHAIN), clang)
> >>> +ifeq ($(shell test
> $(CLANG_MAJOR_VERSION)$(CLANG_MINOR_VERSION) -
> >> ge 37 && echo 1), 1)
> >>> +CFLAGS += -DVIRTIO_CLANG_UNROLL_PRAGMA
> >>> +endif
> >>> +endif
> >>> +
> >>> +ifeq ($(RTE_TOOLCHAIN), icc)
> >>> +ifeq ($(shell test $(ICC_MAJOR_VERSION) -ge 16 && echo 1), 1)
> >>> +CFLAGS += -DVIRTIO_ICC_UNROLL_PRAGMA
> >>> +endif
> >>> +endif
> >>> +
> >>> +CFLAGS_virtio_rxtx_packed_avx.o += -mavx512f -mavx512bw -
> mavx512vl
> >>> +ifeq ($(shell test $(GCC_VERSION) -ge 100 && echo 1), 1)
> >>> +CFLAGS_virtio_rxtx_packed_avx.o += -Wno-zero-length-bounds
> >>> +endif
> >>> +endif
> >>> +
> >>>  ifeq ($(CONFIG_RTE_VIRTIO_USER),y)
> >>>  SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/vhost_user.c
> >>>  SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) +=
> virtio_user/vhost_kernel.c
> >>> diff --git a/drivers/net/virtio/meson.build
> b/drivers/net/virtio/meson.build
> >>> index 15150eea1..8e68c3039 100644
> >>> --- a/drivers/net/virtio/meson.build
> >>> +++ b/drivers/net/virtio/meson.build
> >>> @@ -9,6 +9,20 @@ sources += files('virtio_ethdev.c',
> >>>  deps += ['kvargs', 'bus_pci']
> >>>
> >>>  if arch_subdir == 'x86'
> >>> + if '-mno-avx512f' not in machine_args
> >>> + if cc.has_argument('-mavx512f') and cc.has_argument('-
> >> mavx512vl') and cc.has_argument('-mavx512bw')
> >>> + cflags += ['-mavx512f', '-mavx512bw', '-mavx512vl']
> >>> + cflags += ['-DCC_AVX512_SUPPORT']
> >>> + if (toolchain == 'gcc' and
> >> cc.version().version_compare('>=8.3.0'))
> >>> + cflags += '-DVHOST_GCC_UNROLL_PRAGMA'
> >>> + elif (toolchain == 'clang' and
> >> cc.version().version_compare('>=3.7.0'))
> >>> + cflags += '-
> >> DVHOST_CLANG_UNROLL_PRAGMA'
> >>> + elif (toolchain == 'icc' and
> >> cc.version().version_compare('>=16.0.0'))
> >>> + cflags += '-DVHOST_ICC_UNROLL_PRAGMA'
> >>> + endif
> >>> + sources += files('virtio_rxtx_packed_avx.c')
> >>> + endif
> >>> + endif
> >>>   sources += files('virtio_rxtx_simple_sse.c')
> >>>  elif arch_subdir == 'ppc'
> >>>   sources += files('virtio_rxtx_simple_altivec.c')
> >>> diff --git a/drivers/net/virtio/virtio_ethdev.h
> >> b/drivers/net/virtio/virtio_ethdev.h
> >>> index febaf17a8..5c112cac7 100644
> >>> --- a/drivers/net/virtio/virtio_ethdev.h
> >>> +++ b/drivers/net/virtio/virtio_ethdev.h
> >>> @@ -105,6 +105,9 @@ uint16_t virtio_xmit_pkts_inorder(void
> *tx_queue,
> >> struct rte_mbuf **tx_pkts,
> >>>  uint16_t virtio_recv_pkts_vec(void *rx_queue, struct rte_mbuf
> **rx_pkts,
> >>>   uint16_t nb_pkts);
> >>>
> >>> +uint16_t virtio_recv_pkts_packed_vec(void *rx_queue, struct rte_mbuf
> >> **rx_pkts,
> >>> + uint16_t nb_pkts);
> >>> +
> >>>  int eth_virtio_dev_init(struct rte_eth_dev *eth_dev);
> >>>
> >>>  void virtio_interrupt_handler(void *param);
> >>> diff --git a/dri

Re: [dpdk-dev] [PATCH dpdk-dev v3 2/2] mempool: use shared memzone for rte_mempool_ops

[Tonghao Zhang]

On Mon, Apr 27, 2020 at 8:51 PM Tonghao Zhang  wrote:
>
> On Mon, Apr 27, 2020 at 7:40 PM Thomas Monjalon  wrote:
> >
> > 27/04/2020 10:03, Tonghao Zhang:
> > > On Fri, Apr 17, 2020 at 6:27 AM Thomas Monjalon  
> > > wrote:
> > > >
> > > > 13/04/2020 16:21, xiangxia.m@gmail.com:
> > > > > The order of mempool initiation affects mempool index in the
> > > > > rte_mempool_ops_table. For example, when building APPs with:
> > > > >
> > > > > $ gcc -lrte_mempool_bucket -lrte_mempool_ring ...
> > > > >
> > > > > The "bucket" mempool will be registered firstly, and its index
> > > > > in table is 0 while the index of "ring" mempool is 1. DPDK
> > > > > uses the mk/rte.app.mk to build APPs, and others, for example,
> > > > > Open vSwitch, use the libdpdk.a or libdpdk.so to build it.
> > > > > The mempool lib linked in dpdk and Open vSwitch is different.
> > > >
> > > > We are supposed to use pkg-config to link DPDK.
> > > > Does the problem appear between a DPDK compiled with meson
> > > > and an application linked with pkg-config information?
> Hi Thomas,
> The library mempool linked order can trigger that problem. but when
> the library is loaded
> dynamically, trigger that problem too.
> as Olivier Matz said:
> The fact that the ops index changes during mempool driver lifetime is
> indeed frightening, especially knowning that this is a dynamic
> registration that could happen at any moment in the life of the
> application.
>
> the message in https://mails.dpdk.org/archives/dev/2020-March/159354.html
Hi Thomas,
For first patch, I guess we support a callback for other library, it
make the codes much cleaner
at eal layer. Otherwise, if we init for library, we may include their
header file.
There is a better solution ?
> > > > If the problem really needs to be solved,
> > > > the EAL patch (first of this series) needs to be discussed
> > > > and reviewed carefully. I don't imagine it being done in 20.05.
> > >
> > > will I stop update the patches or when the patch is ready and then
> > > decide applied or not?
> >
> > As I said, it requires more discussion.
> > Please start by answering my question above.
> I got it, Thanks.
> >
>
>
> --
> Best regards, Tonghao



-- 
Best regards, Tonghao

[dpdk-dev] [PATCH] examples: add flush after stats printing

[Andrew Rybchenko]

From: Georgiy Levashov 

When printf()'s stdout is line-buffered for terminal, it is fully
buffered for pipes. So, stdout listener can only get the output
when it is flushed (on program termination, when buffer is filled or
manual flush).

stdout buffer might fill slowly since every stats report could be small.

Also when it is fully filled it might contain a part of the last stats
report which makes it very inconvenient for any automation which reads
and parses the output.

Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org

Signed-off-by: Georgiy Levashov 
Signed-off-by: Andrew Rybchenko 
---
 examples/bbdev_app/main.c | 2 ++
 examples/ioat/ioatfwd.c   | 2 ++
 examples/kni/main.c   | 2 ++
 examples/l2fwd-crypto/main.c  | 2 ++
 examples/l2fwd-event/main.c   | 2 ++
 examples/l2fwd-jobstats/main.c| 3 +++
 examples/l2fwd-keepalive/main.c   | 2 ++
 examples/l2fwd/main.c | 2 ++
 examples/link_status_interrupt/main.c | 2 ++
 examples/tep_termination/main.c   | 2 ++
 examples/vhost/main.c | 2 ++
 11 files changed, 23 insertions(+)

diff --git a/examples/bbdev_app/main.c b/examples/bbdev_app/main.c
index fb38dc3a72..68a46050c0 100644
--- a/examples/bbdev_app/main.c
+++ b/examples/bbdev_app/main.c
@@ -659,6 +659,8 @@ print_stats(struct stats_lcore_params *stats_lcore)
print_lcore_stats(stats_lcore->lconf[l_id].lcore_stats, l_id);
}
 
+   fflush(stdout);
+
free(xstats);
free(xstats_names);
 }
diff --git a/examples/ioat/ioatfwd.c b/examples/ioat/ioatfwd.c
index 7255ff3c9e..0de20cc7d6 100644
--- a/examples/ioat/ioatfwd.c
+++ b/examples/ioat/ioatfwd.c
@@ -294,6 +294,8 @@ print_stats(char *prgname)
printf("\n");
print_total_stats(&delta_ts);
 
+   fflush(stdout);
+
ts.total_packets_tx += delta_ts.total_packets_tx;
ts.total_packets_rx += delta_ts.total_packets_rx;
ts.total_packets_dropped += delta_ts.total_packets_dropped;
diff --git a/examples/kni/main.c b/examples/kni/main.c
index 29fc37e1fb..d9396310cc 100644
--- a/examples/kni/main.c
+++ b/examples/kni/main.c
@@ -158,6 +158,8 @@ print_stats(void)
kni_stats[i].tx_dropped);
}
printf("==  ==      
  \n");
+
+   fflush(stdout);
 }
 
 /* Custom handling of signals to handle stats and kni processing */
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 61d78295d4..506c303954 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -334,6 +334,8 @@ print_stats(void)
   total_packets_dropped,
   total_packets_errors);
printf("\n\n");
+
+   fflush(stdout);
 }
 
 static int
diff --git a/examples/l2fwd-event/main.c b/examples/l2fwd-event/main.c
index 9cc29d7324..9ce505167c 100644
--- a/examples/l2fwd-event/main.c
+++ b/examples/l2fwd-event/main.c
@@ -516,6 +516,8 @@ print_stats(struct l2fwd_resources *rsrc)
   total_packets_rx,
   total_packets_dropped);
printf("\n\n");
+
+   fflush(stdout);
 }
 
 static void
diff --git a/examples/l2fwd-jobstats/main.c b/examples/l2fwd-jobstats/main.c
index c1ca100ed0..1bcaec3c91 100644
--- a/examples/l2fwd-jobstats/main.c
+++ b/examples/l2fwd-jobstats/main.c
@@ -329,6 +329,9 @@ show_stats_cb(__rte_unused void *param)
}
 
printf("\n\n");
+
+   fflush(stdout);
+
rte_eal_alarm_set(timer_period * US_PER_S, show_stats_cb, NULL);
 }
 
diff --git a/examples/l2fwd-keepalive/main.c b/examples/l2fwd-keepalive/main.c
index 2ae5a3c6a9..b1757c0b22 100644
--- a/examples/l2fwd-keepalive/main.c
+++ b/examples/l2fwd-keepalive/main.c
@@ -160,6 +160,8 @@ print_stats(__rte_unused struct rte_timer *ptr_timer,
   total_packets_rx,
   total_packets_dropped);
printf("\n\n");
+
+   fflush(stdout);
 }
 
 static void
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 88ddfe5897..623b74f2f3 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -146,6 +146,8 @@ print_stats(void)
   total_packets_rx,
   total_packets_dropped);
printf("\n\n");
+
+   fflush(stdout);
 }
 
 static void
diff --git a/examples/link_status_interrupt/main.c 
b/examples/link_status_interrupt/main.c
index 38422f6ac5..94802c7ca1 100644
--- a/examples/link_status_interrupt/main.c
+++ b/examples/link_status_interrupt/main.c
@@ -162,6 +162,8 @@ print_stats(void)
   total_packets

Re: [dpdk-dev] [PATCH v1] maintainers: update for AMD xgbe and ccp crypto

[Aaron Conole]

Thomas Monjalon  writes:

> 27/04/2020 14:58, Aaron Conole:
>> Ferruh Yigit  writes:
>> > [1] Two issues reported
>> > a) ninja: build stopped: Error writing to build log: Disk quota
>> > exceeded.
>> 
>> This occurs on some of the ARM64 builds.  Travis is aware of the issue,
>> but don't seem urgently fixing it. :-/  I think we have a series
>> outstanding that should be applied to drop those builds for now.
>
> I saw some "Disk quota exceeded" on x86 static builds.
> So I changed my mind, I am not sure dropping only Arm from Travis
> is a solution, even temporary.

Okay.

>
>> > b) No output has been received in the last 10m0s, this potentially 
>> > indicates a
>> > stalled build or something wrong with the build itself.
>> 
>> This is a future enhancement I need to work on.  When a build has jobs
>> that are stalled / errored, we need to restart them (at least once).  Or
>> otherwise flag it.  It especially happens when internal travis
>> infrastructure fails.
>
> Yes Travis infrastructure fails. Always.
> Travis is free, but it is not a reason to provide a randomly failing tool.

It has been quite useful - it shows us that we still have some
incomplete unit tests and also some racy unit tests.  I agree, it
shouldn't be failing the way it is.

> I suggest switching to other platforms like OBS or our community lab,
> preferring the most reliable one.

OBS and community lab isn't as easy for individual developers to
integrate with.  One thing that's been useful for me is to push to my
github repo and see the results of all the build configurations.  It
doesn't require much effort from my side to ensure that code works.  I
don't always do this (but that's my bad habit), but when I do it proves
very useful.

Maybe the new github-ci (I think it's called 'actions') would be good to
investigate.  Also, Cirrus-CI lets us test on windows and freebsd.  And
there's no reason we can't use all of them.

[dpdk-dev] [PATCH 2/3] net/sfc/base: use simpler EF10 family run-time checks

[Andrew Rybchenko]

Fixes: 4625c4f5277d ("net/sfc/base: factor out upstream port vAdaptor 
allocation")
Fixes: 4f12e20c85dc ("net/sfc/base: introduce EVB module for SR-IOV")
Fixes: 18c8e84d7726 ("net/sfc/base: support proxy auth operations for SR-IOV")
Cc: sta...@dpdk.org

Signed-off-by: Andrew Rybchenko 
---
 drivers/net/sfc/base/ef10_evb.c   | 8 ++--
 drivers/net/sfc/base/ef10_nic.c   | 4 +---
 drivers/net/sfc/base/ef10_proxy.c | 8 ++--
 3 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/net/sfc/base/ef10_evb.c b/drivers/net/sfc/base/ef10_evb.c
index f290339f2f..d541db4980 100644
--- a/drivers/net/sfc/base/ef10_evb.c
+++ b/drivers/net/sfc/base/ef10_evb.c
@@ -15,9 +15,7 @@
 ef10_evb_init(
__inefx_nic_t *enp)
 {
-   EFSYS_ASSERT(enp->en_family == EFX_FAMILY_HUNTINGTON ||
-   enp->en_family == EFX_FAMILY_MEDFORD ||
-   enp->en_family == EFX_FAMILY_MEDFORD2);
+   EFSYS_ASSERT(EFX_FAMILY_IS_EF10(enp));
 
return (0);
 }
@@ -26,9 +24,7 @@ ef10_evb_init(
 ef10_evb_fini(
__inefx_nic_t *enp)
 {
-   EFSYS_ASSERT(enp->en_family == EFX_FAMILY_HUNTINGTON ||
-   enp->en_family == EFX_FAMILY_MEDFORD ||
-   enp->en_family == EFX_FAMILY_MEDFORD2);
+   EFSYS_ASSERT(EFX_FAMILY_IS_EF10(enp));
 }
 
__checkReturn   efx_rc_t
diff --git a/drivers/net/sfc/base/ef10_nic.c b/drivers/net/sfc/base/ef10_nic.c
index d1802da0bd..34fa45e8c1 100644
--- a/drivers/net/sfc/base/ef10_nic.c
+++ b/drivers/net/sfc/base/ef10_nic.c
@@ -2288,9 +2288,7 @@ ef10_nic_init(
efx_rc_t rc;
boolean_t alloc_vadaptor = B_TRUE;
 
-   EFSYS_ASSERT(enp->en_family == EFX_FAMILY_HUNTINGTON ||
-   enp->en_family == EFX_FAMILY_MEDFORD ||
-   enp->en_family == EFX_FAMILY_MEDFORD2);
+   EFSYS_ASSERT(EFX_FAMILY_IS_EF10(enp));
 
/* Enable reporting of some events (e.g. link change) */
if ((rc = efx_mcdi_log_ctrl(enp)) != 0)
diff --git a/drivers/net/sfc/base/ef10_proxy.c 
b/drivers/net/sfc/base/ef10_proxy.c
index 9be9e221d5..19c11c6ebc 100644
--- a/drivers/net/sfc/base/ef10_proxy.c
+++ b/drivers/net/sfc/base/ef10_proxy.c
@@ -13,9 +13,7 @@
 ef10_proxy_auth_init(
__inefx_nic_t *enp)
 {
-   EFSYS_ASSERT(enp->en_family == EFX_FAMILY_HUNTINGTON ||
-   enp->en_family == EFX_FAMILY_MEDFORD ||
-   enp->en_family == EFX_FAMILY_MEDFORD2);
+   EFSYS_ASSERT(EFX_FAMILY_IS_EF10(enp));
 
return (0);
 }
@@ -24,9 +22,7 @@ ef10_proxy_auth_init(
 ef10_proxy_auth_fini(
__inefx_nic_t *enp)
 {
-   EFSYS_ASSERT(enp->en_family == EFX_FAMILY_HUNTINGTON ||
-   enp->en_family == EFX_FAMILY_MEDFORD ||
-   enp->en_family == EFX_FAMILY_MEDFORD2);
+   EFSYS_ASSERT(EFX_FAMILY_IS_EF10(enp));
 }
 
 static __checkReturn   efx_rc_t
-- 
2.17.1

[dpdk-dev] [PATCH 3/3] net/sfc/base: fix build when EVB is enabled

[Andrew Rybchenko]

Make local MCDI helper functions static.

Fixes: f0bda0cd680d ("net/sfc/base: add MCDI wrappers for vPort and vSwitch in 
EVB")
Fixes: ea94d14dbea0 ("net/sfc/base: provide APIs to configure and reset vPort")
Cc: sta...@dpdk.org

Signed-off-by: Andrew Rybchenko 
---
 drivers/net/sfc/base/ef10_evb.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/sfc/base/ef10_evb.c b/drivers/net/sfc/base/ef10_evb.c
index d541db4980..aeeaa5189f 100644
--- a/drivers/net/sfc/base/ef10_evb.c
+++ b/drivers/net/sfc/base/ef10_evb.c
@@ -27,7 +27,7 @@ ef10_evb_fini(
EFSYS_ASSERT(EFX_FAMILY_IS_EF10(enp));
 }
 
-   __checkReturn   efx_rc_t
+static __checkReturn   efx_rc_t
 efx_mcdi_vswitch_alloc(
__inefx_nic_t *enp,
__inefx_vport_id_t vport_id,
@@ -94,7 +94,7 @@ efx_mcdi_vswitch_alloc(
return (rc);
 }
 
-   __checkReturn   efx_rc_t
+static __checkReturn   efx_rc_t
 efx_mcdi_vswitch_free(
__inefx_nic_t *enp)
 {
@@ -125,7 +125,7 @@ efx_mcdi_vswitch_free(
return (rc);
 }
 
-   __checkReturn   efx_rc_t
+static __checkReturn   efx_rc_t
 efx_mcdi_vport_alloc(
__inefx_nic_t *enp,
__inefx_vport_type_t vport_type,
@@ -188,7 +188,7 @@ efx_mcdi_vport_alloc(
return (rc);
 }
 
-   __checkReturn   efx_rc_t
+static __checkReturn   efx_rc_t
 efx_mcdi_vport_free(
__inefx_nic_t *enp,
__inefx_vport_id_t vport_id)
@@ -219,7 +219,7 @@ efx_mcdi_vport_free(
return (rc);
 }
 
-   __checkReturn   efx_rc_t
+static __checkReturn   efx_rc_t
 efx_mcdi_vport_mac_addr_add(
__inefx_nic_t *enp,
__inefx_vport_id_t vport_id,
@@ -254,7 +254,7 @@ efx_mcdi_vport_mac_addr_add(
return (rc);
 }
 
-   __checkReturn   efx_rc_t
+static __checkReturn   efx_rc_t
 efx_mcdi_vport_mac_addr_del(
__inefx_nic_t *enp,
__inefx_vport_id_t vport_id,
@@ -289,7 +289,7 @@ efx_mcdi_vport_mac_addr_del(
return (rc);
 }
 
-   __checkReturn   efx_rc_t
+static __checkReturn   efx_rc_t
 efx_mcdi_port_assign(
__inefx_nic_t *enp,
__inefx_vport_id_t vport_id,
@@ -326,7 +326,7 @@ efx_mcdi_port_assign(
return (rc);
 }
 
-   __checkReturn   efx_rc_t
+static __checkReturn   efx_rc_t
 efx_mcdi_vport_reconfigure(
__inefx_nic_t *enp,
__inefx_vport_id_t vport_id,
-- 
2.17.1

[dpdk-dev] [PATCH 1/3] net/sfc/base: use simpler EF10 family conditional code check

[Andrew Rybchenko]

Fixes: 4f12e20c85dc ("net/sfc/base: introduce EVB module for SR-IOV")
Fixes: 18c8e84d7726 ("net/sfc/base: support proxy auth operations for SR-IOV")
Cc: sta...@dpdk.org

Signed-off-by: Andrew Rybchenko 
---
 drivers/net/sfc/base/ef10_evb.c  | 4 ++--
 drivers/net/sfc/base/efx_evb.c   | 4 ++--
 drivers/net/sfc/base/efx_proxy.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/sfc/base/ef10_evb.c b/drivers/net/sfc/base/ef10_evb.c
index a1528508ea..f290339f2f 100644
--- a/drivers/net/sfc/base/ef10_evb.c
+++ b/drivers/net/sfc/base/ef10_evb.c
@@ -9,7 +9,7 @@
 
 #if EFSYS_OPT_EVB
 
-#if EFSYS_OPT_HUNTINGTON || EFSYS_OPT_MEDFORD || EFSYS_OPT_MEDFORD2
+#if EFX_OPTS_EF10()
 
__checkReturn   efx_rc_t
 ef10_evb_init(
@@ -549,5 +549,5 @@ ef10_evb_vport_stats(
EFX_STATS_UPLOAD, 0));
 }
 
-#endif /* EFSYS_OPT_HUNTINGTON || EFSYS_OPT_MEDFORD || EFSYS_OPT_MEDFORD2 */
+#endif /* EFX_OPTS_EF10() */
 #endif /* EFSYS_OPT_EVB */
diff --git a/drivers/net/sfc/base/efx_evb.c b/drivers/net/sfc/base/efx_evb.c
index 9725ba1f45..17318b7e11 100644
--- a/drivers/net/sfc/base/efx_evb.c
+++ b/drivers/net/sfc/base/efx_evb.c
@@ -28,7 +28,7 @@ static const efx_evb_ops_t__efx_evb_dummy_ops = {
 };
 #endif /* EFSYS_OPT_SIENA */
 
-#if EFSYS_OPT_HUNTINGTON || EFSYS_OPT_MEDFORD || EFSYS_OPT_MEDFORD2
+#if EFX_OPTS_EF10()
 static const efx_evb_ops_t __efx_evb_ef10_ops = {
ef10_evb_init,  /* eeo_init */
ef10_evb_fini,  /* eeo_fini */
@@ -44,7 +44,7 @@ static const efx_evb_ops_t__efx_evb_ef10_ops = {
ef10_evb_vport_reconfigure, /* eeo_vport_reconfigure */
ef10_evb_vport_stats,   /* eeo_vport_stats */
 };
-#endif /* EFSYS_OPT_HUNTINGTON || EFSYS_OPT_MEDFORD || EFSYS_OPT_MEDFORD2 */
+#endif /* EFX_OPTS_EF10() */
 
__checkReturn   efx_rc_t
 efx_evb_init(
diff --git a/drivers/net/sfc/base/efx_proxy.c b/drivers/net/sfc/base/efx_proxy.c
index 5b4e98c381..24baa5a3a4 100644
--- a/drivers/net/sfc/base/efx_proxy.c
+++ b/drivers/net/sfc/base/efx_proxy.c
@@ -23,7 +23,7 @@ static const efx_proxy_ops_t  __efx_proxy_dummy_ops = {
 };
 #endif /* EFSYS_OPT_SIENA */
 
-#if EFSYS_OPT_HUNTINGTON || EFSYS_OPT_MEDFORD || EFSYS_OPT_MEDFORD2
+#if EFX_OPTS_EF10()
 static const efx_proxy_ops_t   __efx_proxy_ef10_ops = {
ef10_proxy_auth_init,   /* epo_init */
ef10_proxy_auth_fini,   /* epo_fini */
@@ -35,7 +35,7 @@ static const efx_proxy_ops_t  
__efx_proxy_ef10_ops = {
ef10_proxy_auth_exec_cmd,   /* epo_exec_cmd */
ef10_proxy_auth_get_privilege_mask, /* epo_get_privilege_mask */
 };
-#endif /* EFSYS_OPT_HUNTINGTON || EFSYS_OPT_MEDFORD || EFSYS_OPT_MEDFORD2 */
+#endif /* EFX_OPTS_EF10() */
 
__checkReturn   efx_rc_t
 efx_proxy_auth_init(
-- 
2.17.1

Re: [dpdk-dev] [PATCH v10 6/9] net/virtio: add vectorized packed ring Rx path

[Maxime Coquelin]

On 4/28/20 3:01 PM, Liu, Yong wrote:
>>> Maxime,
>>> Thanks for point it out, it will add extra cache miss in datapath.
>>> And its impact on performance is around 1% in loopback case.
>> Ok, thanks for doing the test. I'll try to run some PVP benchmarks
>> on my side because when doing IO loopback, the cache pressure is
>> much less important.
>>
>>> While benefit of vectorized path will be more than that number.
>> Ok, but I disagree for two reasons:
>>  1. You have to keep in mind than non-vectorized is the default and
>> encouraged mode to use. Indeed, it takes a lot of shortcuts like not
>> checking header length (so no error stats), etc...
>>
> Ok, I will keep non-vectorized same as before.
> 
>>  2. It's like saying it's OK it degrades by 5% on $CPU_VENDOR_A because
>> the gain is 20% on $CPU_VENDOR_B.
>>
>> In the case we see more degradation in real-world scenario, you might
>> want to consider using ifdefs to avoid adding padding in the non-
>> vectorized case, like you did to differentiate Virtio PMD to Virtio-user
>> PMD in patch 7.
>>
> Maxime,
> The performance difference is so slight, so I ignored for it look like a 
> sampling error. 

Agree for IO loopback, but it adds one more cache line access per burst,
which might be see in some real-life use cases.

> It maybe not suitable to add new configuration for such setting which only 
> used inside driver.

Wait, the Virtio-user #ifdef is based on the defconfig options? How can
it work since both Virtio PMD and Virtio-user PMD can be selected at the
same time?

I thought it was a define set before the headers inclusion and unset
afterwards, but I didn't checked carefully.

> Virtio driver can check whether virtqueue is using vectorized path when 
> initialization, will use padded structure if it is.
> I have added some tested code and now performance came back.  Since code has 
> changed in initialization process,  it need some time for regression check.

Ok, works for me.

I am investigating a linkage issue with your series, which does not
happen systematically (see below, it happens also with clang). David
pointed me to some Intel patches removing the usage if __rte_weak,
could it be related?


gcc  -o app/test/dpdk-test
'app/test/3062f5d@@dpdk-test@exe/commands.c.o'
'app/test/3062f5d@@dpdk-test@exe/packet_burst_generator.c.o'
'app/test/3062f5d@@dpdk-test@exe/test.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_acl.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_alarm.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_atomic.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_barrier.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_bpf.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_byteorder.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cmdline.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cmdline_cirbuf.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cmdline_etheraddr.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cmdline_ipaddr.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cmdline_lib.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cmdline_num.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cmdline_portlist.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cmdline_string.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_common.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cpuflags.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_crc.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cryptodev.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cryptodev_asym.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cryptodev_blockcipher.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cryptodev_security_pdcp.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_cycles.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_debug.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_distributor.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_distributor_perf.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_eal_flags.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_eal_fs.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_efd.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_efd_perf.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_errno.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_event_crypto_adapter.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_event_eth_rx_adapter.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_event_ring.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_event_timer_adapter.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_eventdev.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_external_mem.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_fbarray.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_fib.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_fib_perf.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_fib6.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_fib6_perf.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_func_reentrancy.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_flow_classify.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_hash.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_hash_functions.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_hash_multiwriter.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_hash_readwrite.c.o'
'app/test/3062f5d@@dpdk-test@exe/test_hash_perf.c.o'
'app/test/306

Re: [dpdk-dev] [EXT] [PATCH] trace: fix build with gcc 10

[Phil Yang]

> -Original Message-
> From: Sunil Kumar Kori 
> Sent: Tuesday, April 28, 2020 6:52 PM
> To: Phil Yang ; jer...@marvell.com; dev@dpdk.org
> Cc: David Marchand ; Ruifeng Wang
> ; Lijian Zhang ; nd
> ; nd 
> Subject: RE: [EXT] [PATCH] trace: fix build with gcc 10
> 



> >>
> >Hello, there is one more thread going on regarding this. Please have a look
> on
> >below patch.
> >https://urldefense.proofpoint.com/v2/url?u=http-
> >3A__patches.dpdk.org_patch_69382_&d=DwIGaQ&c=nKjWec2b6R0mOyPa
> z7x
> >tfQ&r=dXeXaAMkP5COgn1zxHMyaF1_d9IIuq6vHQO6NrIPjaE&m=WFCcD0E
> avY
> >uGMZUUoJWIQunwTAwgxAju2rK4s3Nr-t4&s=iMF8PSGMB8S-
> >rDR0kJGOZ1el3MzeOKfxZQxX-Oyg54g&e=
> >
> >Hi Sunil,
> >
> >Sorry, I didn’t notice that. Thanks for the link.
> >
> >I have two points:
> >1. Will this patch resolves both mentioned warnings/error in  patch 69382 ?
> >[Phil] Yes, this patch resolved the same issue mentioned by David in patch
> >69382.
> >
> >2. David has suggested another way of doing it. Please check that too.
> >[Phil]  I think both David’s and my patches are correct.
> >My patch can guarantee a correct ‘size’ information in snprinf(). It omits 
> >the
> >memory allocation operation for the incorrect input arguments case.
> >David’s suggestion resolves the potential directory copy fail issue and it
> saves
> >some memory space in the normal case. But it needs to allocate memory in
> >the incorrect input case.
> >
> >So, I think we can bind these two patches together?
> Make sense.
> So can you please combine both the patches and share ?
> 

Sure. 
I will update it in v2.

Re: [dpdk-dev] [EXT] Re: [PATCH v3 1/1] bus/pci: optimise scanning with whitelist/blacklist

[Sunil Kumar Kori]

>-Original Message-
>From: Gaëtan Rivet 
>Sent: Tuesday, April 28, 2020 12:14 AM
>To: Sunil Kumar Kori 
>Cc: step...@networkplumber.org; david.march...@redhat.com; Jerin Jacob
>Kollanukkaran ; dev@dpdk.org
>Subject: [EXT] Re: [dpdk-dev] [PATCH v3 1/1] bus/pci: optimise scanning with
>whitelist/blacklist
>
>External Email
>
>--
>Hello Sunil,
>
>As it seems that this patch does not overly alarm people using the PCI
>bus, I have a few comments on this version. Sending those a little
>earlier will allow you to change as needed before proceeding with your
>tests.
>
>On 20/04/20 12:25 +0530, Sunil Kumar Kori wrote:
>> rte_bus_scan API scans all the available PCI devices irrespective of white
>> or black listing parameters then further devices are probed based on white
>> or black listing parameters. So unnecessary CPU cycles are wasted during
>> rte_pci_scan.
>>
>> For Octeontx2 platform with core frequency 2.4 Ghz, rte_bus_scan
>consumes
>> around 26ms to scan around 90 PCI devices but all may not be used by the
>> application. So for the application which uses 2 NICs, rte_bus_scan
>> consumes few microseconds and rest time is saved with this patch.
>>
>> Patch restricts devices to be scanned as per below mentioned conditions:
>>  - All devices will be scanned if no parameters are passed.
>>  - Only white listed devices will be scanned if white list is available.
>>  - All devices, except black listed, will be scanned if black list is
>>available.
>>
>> Signed-off-by: Sunil Kumar Kori 
>> ---
>> v3:
>>  - remove __rte_experimental from private function.
>>  - remove entry from map file too.
>> v2:
>>  - Added function to validate ignorance of device based on PCI address.
>>  - Marked device validation function as experimental.
>>
>>  drivers/bus/pci/bsd/pci.c| 13 -
>>  drivers/bus/pci/linux/pci.c  |  3 +++
>>  drivers/bus/pci/pci_common.c | 34
>++
>>  drivers/bus/pci/private.h| 11 +++
>>  4 files changed, 60 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/bus/pci/bsd/pci.c b/drivers/bus/pci/bsd/pci.c
>> index ebbfeb13a..c8d954751 100644
>> --- a/drivers/bus/pci/bsd/pci.c
>> +++ b/drivers/bus/pci/bsd/pci.c
>> @@ -338,6 +338,7 @@ rte_pci_scan(void)
>>  .match_buf_len = sizeof(matches),
>>  .matches = &matches[0],
>>  };
>> +struct rte_pci_addr pci_addr;
>>
>>  /* for debug purposes, PCI can be disabled */
>>  if (!rte_eal_has_pci())
>> @@ -357,9 +358,19 @@ rte_pci_scan(void)
>>  goto error;
>>  }
>>
>> -for (i = 0; i < conf_io.num_matches; i++)
>> +for (i = 0; i < conf_io.num_matches; i++) {
>> +pci_addr.domain = matches[i].pc_sel.pc_domain;
>> +pci_addr.bus = matches[i].pc_sel.pc_bus;
>> +pci_addr.devid = matches[i].pc_sel.pc_dev;
>> +pci_addr.function = matches[i].pc_sel.pc_func;
>> +
>> +/* Check that device should be ignored or not  */
>
>This comment is unnecessary, the function name should be sufficient to
>describe the check done.
>
Ack

>> +if (pci_addr_ignore_device(&pci_addr))
>> +continue;
>> +
>
>As this function is almost a copy of pci_ignore_device(), with a twist
>on the addr, I think the name pci_ignore_device_addr() would be more
>helpful.
>
>I think in general however, that exposed symbols, even internals,
>should be prefixed with rte_. It was (almost) ok for
>pci_ignore_device() to forego the namespace as it is a static function
>that will be mangled on export, but that won't be the case for your
>function.
>
>Please add rte_ prefix.
>
Ack

>>  if (pci_scan_one(fd, &matches[i]) < 0)
>>  goto error;
>> +}
>>
>>  dev_count += conf_io.num_matches;
>>  } while(conf_io.status == PCI_GETCONF_MORE_DEVS);
>> diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
>> index 71b0a3053..92bdad826 100644
>> --- a/drivers/bus/pci/linux/pci.c
>> +++ b/drivers/bus/pci/linux/pci.c
>> @@ -487,6 +487,9 @@ rte_pci_scan(void)
>>  if (parse_pci_addr_format(e->d_name, sizeof(e->d_name),
>&addr) != 0)
>>  continue;
>>
>> +if (pci_addr_ignore_device(&addr))
>> +continue;
>> +
>>  snprintf(dirname, sizeof(dirname), "%s/%s",
>>  rte_pci_get_sysfs_path(), e->d_name);
>>
>> diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
>> index 3f5542076..a350a1993 100644
>> --- a/drivers/bus/pci/pci_common.c
>> +++ b/drivers/bus/pci/pci_common.c
>> @@ -589,6 +589,40 @@ pci_dma_unmap(struct rte_device *dev, void
>*addr, uint64_t iova, size_t len)
>>  return -1;
>>  }
>>
>> +static struct rte_devargs *
>> +pci_addr_dev

[dpdk-dev] [RFC] ring: count and empty optimizations

[Morten Brørup]

Olivier (maintainer of the Ring),

I would like to suggest a couple of minor optimizations to the ring library.


1. Testing if the ring is empty is as simple as comparing the producer and 
consumer pointers:

static inline int
rte_ring_empty(const struct rte_ring *r)
{
-   return rte_ring_count(r) == 0;
+   uint32_t prod_tail = r->prod.tail;
+   uint32_t cons_tail = r->cons.tail;
+   return cons_tail == prod_tail;
}

In theory, this optimization reduces the number of potential cache misses from 
3 to 2 by not having to read r->mask in rte_ring_count().


2. It is not possible to enqueue more elements than the capacity of a ring, so 
the count function does not need to test if the capacity is exceeded:

static inline unsigned
rte_ring_count(const struct rte_ring *r)
{
uint32_t prod_tail = r->prod.tail;
uint32_t cons_tail = r->cons.tail;
uint32_t count = (prod_tail - cons_tail) & r->mask;
-   return (count > r->capacity) ? r->capacity : count;
+   return count;
}

I cannot even come up with a race condition in this function where the count 
would exceed the capacity. Maybe I missed something?


Med venlig hilsen / kind regards
- Morten Brørup

Re: [dpdk-dev] [EXT] Re: [PATCH v4 1/4] ethdev: add tm support for shaper config in pkt mode

[Ferruh Yigit]

On 4/28/2020 12:51 PM, Nithin Dabilpuram wrote:
> On Mon, Apr 27, 2020 at 10:29:48PM +0530, Jerin Jacob wrote:
>> External Email
>>
>> --
>> On Mon, Apr 27, 2020 at 10:19 PM Ferruh Yigit  wrote:
>>>
>>> On 4/27/2020 5:29 PM, Jerin Jacob wrote:
 On Mon, Apr 27, 2020 at 9:42 PM Ferruh Yigit  
 wrote:
>
> On 4/27/2020 10:19 AM, Dumitrescu, Cristian wrote:
>>
>>
>>> -Original Message-
>>> From: Yigit, Ferruh 
>>> Sent: Saturday, April 25, 2020 9:09 PM
>>> To: Dumitrescu, Cristian ; Nithin 
>>> Dabilpuram
>>> ; Singh, Jasvinder ;
>>> Thomas Monjalon ; Andrew Rybchenko
>>> 
>>> Cc: dev@dpdk.org; jer...@marvell.com; kka...@marvell.com; Nithin
>>> Dabilpuram 
>>> Subject: Re: [PATCH v4 1/4] ethdev: add tm support for shaper config in 
>>> pkt
>>> mode
>>>
>>> On 4/24/2020 11:28 AM, Dumitrescu, Cristian wrote:


> -Original Message-
> From: Nithin Dabilpuram 
> Sent: Wednesday, April 22, 2020 6:21 PM
> To: Singh, Jasvinder ; Dumitrescu, Cristian
> ; Thomas Monjalon
> ; Yigit, Ferruh ; Andrew
> Rybchenko 
> Cc: dev@dpdk.org; jer...@marvell.com; kka...@marvell.com; Nithin
> Dabilpuram 
> Subject: [PATCH v4 1/4] ethdev: add tm support for shaper config in 
> pkt
> mode
>
> From: Nithin Dabilpuram 
>
> Some NIC hardware support shaper to work in packet mode i.e
> shaping or ratelimiting traffic is in packets per second (PPS) as
> opposed to default bytes per second (BPS). Hence this patch
> adds support to configure shared or private shaper in packet mode,
> provide rate in PPS and add related tm capabilities in port/level/node
> capability structures.
>
> This patch also updates tm port/level/node capability structures with
> exiting features of scheduler wfq packet mode, scheduler wfq byte mode
> and private/shared shaper byte mode.
>
> SoftNIC PMD is also updated with new capabilities.
>
> Signed-off-by: Nithin Dabilpuram 
> ---
> v3..v4:
> - Update text under packet_mode as per Cristian.
> - Update rte_eth_softnic_tm.c based on Jasvinder's comments.
> - Add error enum
>>> RTE_TM_ERROR_TYPE_SHAPER_PROFILE_PACKET_MODE
> - Fix shaper_profile_check() with packet mode check
> - Fix typo's
>

 Acked-by: Cristian Dumitrescu 

>>>
>>> Hi Nithin,
>>>
>>> It looks like patch is causing ABI break, I am getting following 
>>> warning [1],
>>> can you please check?
>>>
>>> [1]
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_XYNFg14u&d=DwIBaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=FZ_tPCbgFOh18zwRPO9H0yDx8VW38vuapifdDfc8SFQ&m=xJB0Qb2Q-1bl0hEDeknUjJqrCDc3z-h0F0e7kj8KvvI&s=R6xtRQRRIIzAilc5z52oYjyHNlvvJB_9SUsKBkpPC6g&e=
>>>  
>>
>>
>> Hi Ferruh,
>>
>> The RTE_TM API is marked as experimental, but it looks that this was not 
>> correctly marked when __rte_experimental ABI checker was introduced.
>>
>> It is marked as experimental at the top of the rte_tm.h, similarly to 
>> other APIs introduced around same time, but it was not correctly picked 
>> up by the ABI check procedure when later introduced, so 
>> __rte_experimental was not added to every function.
>>
>
> :(
>
> Is it time to mature them?
>
> As you said they are not marked as experimental both in header file 
> (function
> declarations) and .map file.
>
> The problem is, they are not marked as experimental in DPDK_20.0 ABI 
> (v19.11),
> so marking them as experimental now will break the ABI. Not sure what to 
> do,
> cc'ed a few ABI related names for comment.
>
> For me, we need to proceed as the experimental tag removed and APIs become
> mature starting from v19.11, since this is what happened in practice, and 
> remove
> a few existing being experimental references in the doxygen comments.

 I think, accidentally we can not make a library as NON-experimental.
 TM never went through experimental to mature transition(see git log
 lib/librte_ethdev/rte_tm.h)
 It was a bug to not mark as experimental in each function in the ABI 
 process.
 Some of the features like packet marking are not even implemented by any 
 HW.
 I think, we can make API stable only all the features are implemented
 by one or two HW.
>>>
>>> Fair enough, specially if the API is not ready yet.
>>>
>>> But they were part of stable ABI, and marking them as experimental now will
>>> break the old applications using these APIs.
>>
>> it is still marked as EXPERIMENTAL everywhere and API is not read

Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add tm support for shaper config in pkt mode

[Ferruh Yigit]

On 4/27/2020 5:59 PM, Jerin Jacob wrote:
> On Mon, Apr 27, 2020 at 10:19 PM Ferruh Yigit  wrote:
>>
>> On 4/27/2020 5:29 PM, Jerin Jacob wrote:
>>> On Mon, Apr 27, 2020 at 9:42 PM Ferruh Yigit  wrote:

 On 4/27/2020 10:19 AM, Dumitrescu, Cristian wrote:
>
>
>> -Original Message-
>> From: Yigit, Ferruh 
>> Sent: Saturday, April 25, 2020 9:09 PM
>> To: Dumitrescu, Cristian ; Nithin 
>> Dabilpuram
>> ; Singh, Jasvinder ;
>> Thomas Monjalon ; Andrew Rybchenko
>> 
>> Cc: dev@dpdk.org; jer...@marvell.com; kka...@marvell.com; Nithin
>> Dabilpuram 
>> Subject: Re: [PATCH v4 1/4] ethdev: add tm support for shaper config in 
>> pkt
>> mode
>>
>> On 4/24/2020 11:28 AM, Dumitrescu, Cristian wrote:
>>>
>>>
 -Original Message-
 From: Nithin Dabilpuram 
 Sent: Wednesday, April 22, 2020 6:21 PM
 To: Singh, Jasvinder ; Dumitrescu, Cristian
 ; Thomas Monjalon
 ; Yigit, Ferruh ; Andrew
 Rybchenko 
 Cc: dev@dpdk.org; jer...@marvell.com; kka...@marvell.com; Nithin
 Dabilpuram 
 Subject: [PATCH v4 1/4] ethdev: add tm support for shaper config in pkt
 mode

 From: Nithin Dabilpuram 

 Some NIC hardware support shaper to work in packet mode i.e
 shaping or ratelimiting traffic is in packets per second (PPS) as
 opposed to default bytes per second (BPS). Hence this patch
 adds support to configure shared or private shaper in packet mode,
 provide rate in PPS and add related tm capabilities in port/level/node
 capability structures.

 This patch also updates tm port/level/node capability structures with
 exiting features of scheduler wfq packet mode, scheduler wfq byte mode
 and private/shared shaper byte mode.

 SoftNIC PMD is also updated with new capabilities.

 Signed-off-by: Nithin Dabilpuram 
 ---
 v3..v4:
 - Update text under packet_mode as per Cristian.
 - Update rte_eth_softnic_tm.c based on Jasvinder's comments.
 - Add error enum
>> RTE_TM_ERROR_TYPE_SHAPER_PROFILE_PACKET_MODE
 - Fix shaper_profile_check() with packet mode check
 - Fix typo's

>>>
>>> Acked-by: Cristian Dumitrescu 
>>>
>>
>> Hi Nithin,
>>
>> It looks like patch is causing ABI break, I am getting following warning 
>> [1],
>> can you please check?
>>
>> [1]
>> https://pastebin.com/XYNFg14u
>
>
> Hi Ferruh,
>
> The RTE_TM API is marked as experimental, but it looks that this was not 
> correctly marked when __rte_experimental ABI checker was introduced.
>
> It is marked as experimental at the top of the rte_tm.h, similarly to 
> other APIs introduced around same time, but it was not correctly picked 
> up by the ABI check procedure when later introduced, so 
> __rte_experimental was not added to every function.
>

 :(

 Is it time to mature them?

 As you said they are not marked as experimental both in header file 
 (function
 declarations) and .map file.

 The problem is, they are not marked as experimental in DPDK_20.0 ABI 
 (v19.11),
 so marking them as experimental now will break the ABI. Not sure what to 
 do,
 cc'ed a few ABI related names for comment.

 For me, we need to proceed as the experimental tag removed and APIs become
 mature starting from v19.11, since this is what happened in practice, and 
 remove
 a few existing being experimental references in the doxygen comments.
>>>
>>> I think, accidentally we can not make a library as NON-experimental.
>>> TM never went through experimental to mature transition(see git log
>>> lib/librte_ethdev/rte_tm.h)
>>> It was a bug to not mark as experimental in each function in the ABI 
>>> process.
>>> Some of the features like packet marking are not even implemented by any HW.
>>> I think, we can make API stable only all the features are implemented
>>> by one or two HW.
>>
>> Fair enough, specially if the API is not ready yet.
>>
>> But they were part of stable ABI, and marking them as experimental now will
>> break the old applications using these APIs.
> 
> it is still marked as EXPERIMENTAL everywhere and API is not ready yet.

Existing experimental marks are text only for human parsing.

The compiler attribute and build time checks are missing, and the symbol in the
binary doesn't have experimental tag. Our scripts and automated checks won't
detect it as experimental.

My point is just having experimental comment in header file is not enough to
qualify the APIs as experimental.

> Anyway, we need to break the ABI to make it work on various HW.
> I am not sure what to do?
> IMO, We need to send a patch as Fixes: for the bug of not adding
> __rte_ex

Re: [dpdk-dev] [PATCH 5/5] app/test-flow-perf: add packet forwarding support

[Or Gerlitz]

On Thu, Apr 9, 2020 at 6:44 PM Wisam Jaddo  wrote:
>
> Introduce packet forwarding support to the app to do
> some performance measurements.
>
> The measurements are reported in term of packet per
> second unit. The forwarding will start after the end
> of insertion/deletion operations.
>
> The support has single and multi performance measurements.

single and multi core? if not, then multi of what?

[dpdk-dev] [PATCH v2] trace: fix build with gcc 10

[Phil Yang]

Prevent from writing beyond the allocated memory.

GCC 10 compiling output:
eal_common_trace_utils.c: In function 'eal_trace_dir_args_save':
eal_common_trace_utils.c:290:24: error: '__builtin___sprintf_chk'   \
may write a terminating nul past the end of the destination \
[-Werror=format-overflow=]
  290 |  sprintf(dir_path, "%s/", optarg);
  |^

Fixes: 8af866df8d8c ("trace: add trace directory configuration parameter")

Signed-off-by: Phil Yang 
Reviewed-by: Lijian Zhang 
Tested-by: Lijian Zhang 
---
v2:
use asprintf instead of sprintf.

 lib/librte_eal/common/eal_common_trace_utils.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_trace_utils.c 
b/lib/librte_eal/common/eal_common_trace_utils.c
index fce8892..2ffb8af 100644
--- a/lib/librte_eal/common/eal_common_trace_utils.c
+++ b/lib/librte_eal/common/eal_common_trace_utils.c
@@ -268,7 +268,7 @@ eal_trace_dir_args_save(char const *optarg)
 {
struct trace *trace = trace_obj_get();
uint32_t size = sizeof(trace->dir);
-   char *dir_path = NULL;
+   char *dir_path;
int rc;
 
if (optarg == NULL) {
@@ -276,18 +276,20 @@ eal_trace_dir_args_save(char const *optarg)
return -EINVAL;
}
 
-   if (strlen(optarg) >= size) {
+   /* the specified trace directory name cannot
+* exceed PATH_MAX-1.
+*/
+   if (strlen(optarg) >= (size - 1)) {
trace_err("input string is too big");
return -ENAMETOOLONG;
}
 
-   dir_path = (char *)calloc(1, size);
-   if (dir_path == NULL) {
-   trace_err("fail to allocate memory");
+   rc = asprintf(&dir_path, "%s/", optarg);
+   if (rc == -1) {
+   trace_err("failed to copy directory: %s", strerror(errno));
return -ENOMEM;
}
 
-   sprintf(dir_path, "%s/", optarg);
rc = trace_dir_update(dir_path);
 
free(dir_path);
-- 
2.7.4

Re: [dpdk-dev] [PATCH v10 6/9] net/virtio: add vectorized packed ring Rx path

[Liu, Yong]

> -Original Message-
> From: Maxime Coquelin 
> Sent: Tuesday, April 28, 2020 9:46 PM
> To: Liu, Yong ; Ye, Xiaolong ;
> Wang, Zhihong 
> Cc: dev@dpdk.org; Honnappa Nagarahalli
> ; jer...@marvell.com
> Subject: Re: [PATCH v10 6/9] net/virtio: add vectorized packed ring Rx path
> 
> 
> 
> On 4/28/20 3:01 PM, Liu, Yong wrote:
> >>> Maxime,
> >>> Thanks for point it out, it will add extra cache miss in datapath.
> >>> And its impact on performance is around 1% in loopback case.
> >> Ok, thanks for doing the test. I'll try to run some PVP benchmarks
> >> on my side because when doing IO loopback, the cache pressure is
> >> much less important.
> >>
> >>> While benefit of vectorized path will be more than that number.
> >> Ok, but I disagree for two reasons:
> >>  1. You have to keep in mind than non-vectorized is the default and
> >> encouraged mode to use. Indeed, it takes a lot of shortcuts like not
> >> checking header length (so no error stats), etc...
> >>
> > Ok, I will keep non-vectorized same as before.
> >
> >>  2. It's like saying it's OK it degrades by 5% on $CPU_VENDOR_A because
> >> the gain is 20% on $CPU_VENDOR_B.
> >>
> >> In the case we see more degradation in real-world scenario, you might
> >> want to consider using ifdefs to avoid adding padding in the non-
> >> vectorized case, like you did to differentiate Virtio PMD to Virtio-user
> >> PMD in patch 7.
> >>
> > Maxime,
> > The performance difference is so slight, so I ignored for it look like a
> sampling error.
> 
> Agree for IO loopback, but it adds one more cache line access per burst,
> which might be see in some real-life use cases.
> 
> > It maybe not suitable to add new configuration for such setting which
> only used inside driver.
> 
> Wait, the Virtio-user #ifdef is based on the defconfig options? How can
> it work since both Virtio PMD and Virtio-user PMD can be selected at the
> same time?
> 
> I thought it was a define set before the headers inclusion and unset
> afterwards, but I didn't checked carefully.
> 

Maxime,
The difference between virtio PMD and Virtio-user PMD addresses is handled by 
vq->offset. 

When virtio PMD is running, offset will be set to buf_iova.
vq->offset = offsetof(struct rte_mbuf, buf_iova);

When virtio_user PMD is running, offset will be set to buf_addr.
vq->offset = offsetof(struct rte_mbuf, buf_addr);

> > Virtio driver can check whether virtqueue is using vectorized path when
> initialization, will use padded structure if it is.
> > I have added some tested code and now performance came back.  Since
> code has changed in initialization process,  it need some time for regression
> check.
> 
> Ok, works for me.
> 
> I am investigating a linkage issue with your series, which does not
> happen systematically (see below, it happens also with clang). David
> pointed me to some Intel patches removing the usage if __rte_weak,
> could it be related?
> 

I checked David's patch, it only changed i40e driver. Meanwhile attribute 
__rte_weak should still be in virtio_rxtx.c. 
I will follow David's patch, eliminate the usage of weak attribute. 

> 
> gcc  -o app/test/dpdk-test
> 'app/test/3062f5d@@dpdk-test@exe/commands.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/packet_burst_generator.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_acl.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_alarm.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_atomic.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_barrier.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_bpf.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_byteorder.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cmdline.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cmdline_cirbuf.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cmdline_etheraddr.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cmdline_ipaddr.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cmdline_lib.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cmdline_num.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cmdline_portlist.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cmdline_string.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_common.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cpuflags.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_crc.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cryptodev.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cryptodev_asym.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cryptodev_blockcipher.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cryptodev_security_pdcp.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_cycles.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_debug.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_distributor.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_distributor_perf.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_eal_flags.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_eal_fs.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_efd.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_efd_perf.c.o'
> 'app/test/3062f5d@@dpdk-test@exe/test_errno.c.o'
> 'app/test/3062f5d@@dpdk-test

Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add tm support for shaper config in pkt mode

[Bruce Richardson]

On Tue, Apr 28, 2020 at 03:06:20PM +0100, Ferruh Yigit wrote:
> On 4/27/2020 5:59 PM, Jerin Jacob wrote:
> > On Mon, Apr 27, 2020 at 10:19 PM Ferruh Yigit  
> > wrote:
> >>
> >> On 4/27/2020 5:29 PM, Jerin Jacob wrote:
> >>> On Mon, Apr 27, 2020 at 9:42 PM Ferruh Yigit  
> >>> wrote:
> 
>  On 4/27/2020 10:19 AM, Dumitrescu, Cristian wrote:
> >
> >
> >> -Original Message-
> >> From: Yigit, Ferruh 
> >> Sent: Saturday, April 25, 2020 9:09 PM
> >> To: Dumitrescu, Cristian ; Nithin 
> >> Dabilpuram
> >> ; Singh, Jasvinder ;
> >> Thomas Monjalon ; Andrew Rybchenko
> >> 
> >> Cc: dev@dpdk.org; jer...@marvell.com; kka...@marvell.com; Nithin
> >> Dabilpuram 
> >> Subject: Re: [PATCH v4 1/4] ethdev: add tm support for shaper config 
> >> in pkt
> >> mode
> >>
> >> On 4/24/2020 11:28 AM, Dumitrescu, Cristian wrote:
> >>>
> >>>
>  -Original Message-
>  From: Nithin Dabilpuram 
>  Sent: Wednesday, April 22, 2020 6:21 PM
>  To: Singh, Jasvinder ; Dumitrescu, 
>  Cristian
>  ; Thomas Monjalon
>  ; Yigit, Ferruh ; Andrew
>  Rybchenko 
>  Cc: dev@dpdk.org; jer...@marvell.com; kka...@marvell.com; Nithin
>  Dabilpuram 
>  Subject: [PATCH v4 1/4] ethdev: add tm support for shaper config in 
>  pkt
>  mode
> 
>  From: Nithin Dabilpuram 
> 
>  Some NIC hardware support shaper to work in packet mode i.e
>  shaping or ratelimiting traffic is in packets per second (PPS) as
>  opposed to default bytes per second (BPS). Hence this patch
>  adds support to configure shared or private shaper in packet mode,
>  provide rate in PPS and add related tm capabilities in 
>  port/level/node
>  capability structures.
> 
>  This patch also updates tm port/level/node capability structures with
>  exiting features of scheduler wfq packet mode, scheduler wfq byte 
>  mode
>  and private/shared shaper byte mode.
> 
>  SoftNIC PMD is also updated with new capabilities.
> 
>  Signed-off-by: Nithin Dabilpuram 
>  ---
>  v3..v4:
>  - Update text under packet_mode as per Cristian.
>  - Update rte_eth_softnic_tm.c based on Jasvinder's comments.
>  - Add error enum
> >> RTE_TM_ERROR_TYPE_SHAPER_PROFILE_PACKET_MODE
>  - Fix shaper_profile_check() with packet mode check
>  - Fix typo's
> 
> >>>
> >>> Acked-by: Cristian Dumitrescu 
> >>>
> >>
> >> Hi Nithin,
> >>
> >> It looks like patch is causing ABI break, I am getting following 
> >> warning [1],
> >> can you please check?
> >>
> >> [1]
> >> https://pastebin.com/XYNFg14u
> >
> >
> > Hi Ferruh,
> >
> > The RTE_TM API is marked as experimental, but it looks that this was 
> > not correctly marked when __rte_experimental ABI checker was introduced.
> >
> > It is marked as experimental at the top of the rte_tm.h, similarly to 
> > other APIs introduced around same time, but it was not correctly picked 
> > up by the ABI check procedure when later introduced, so 
> > __rte_experimental was not added to every function.
> >
> 
>  :(
> 
>  Is it time to mature them?
> 
>  As you said they are not marked as experimental both in header file 
>  (function
>  declarations) and .map file.
> 
>  The problem is, they are not marked as experimental in DPDK_20.0 ABI 
>  (v19.11),
>  so marking them as experimental now will break the ABI. Not sure what to 
>  do,
>  cc'ed a few ABI related names for comment.
> 
>  For me, we need to proceed as the experimental tag removed and APIs 
>  become
>  mature starting from v19.11, since this is what happened in practice, 
>  and remove
>  a few existing being experimental references in the doxygen comments.
> >>>
> >>> I think, accidentally we can not make a library as NON-experimental.
> >>> TM never went through experimental to mature transition(see git log
> >>> lib/librte_ethdev/rte_tm.h)
> >>> It was a bug to not mark as experimental in each function in the ABI 
> >>> process.
> >>> Some of the features like packet marking are not even implemented by any 
> >>> HW.
> >>> I think, we can make API stable only all the features are implemented
> >>> by one or two HW.
> >>
> >> Fair enough, specially if the API is not ready yet.
> >>
> >> But they were part of stable ABI, and marking them as experimental now will
> >> break the old applications using these APIs.
> > 
> > it is still marked as EXPERIMENTAL everywhere and API is not ready yet.
> 
> Existing experimental marks are text only for human parsing.
> 
> The compiler attribute and build time checks are missing, and the symbol in 
> 

Re: [dpdk-dev] [PATCH v10 6/9] net/virtio: add vectorized packed ring Rx path

[Maxime Coquelin]

On 4/28/20 4:43 PM, Liu, Yong wrote:
> 
> 
>> -Original Message-
>> From: Maxime Coquelin 
>> Sent: Tuesday, April 28, 2020 9:46 PM
>> To: Liu, Yong ; Ye, Xiaolong ;
>> Wang, Zhihong 
>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>> ; jer...@marvell.com
>> Subject: Re: [PATCH v10 6/9] net/virtio: add vectorized packed ring Rx path
>>
>>
>>
>> On 4/28/20 3:01 PM, Liu, Yong wrote:
> Maxime,
> Thanks for point it out, it will add extra cache miss in datapath.
> And its impact on performance is around 1% in loopback case.
 Ok, thanks for doing the test. I'll try to run some PVP benchmarks
 on my side because when doing IO loopback, the cache pressure is
 much less important.

> While benefit of vectorized path will be more than that number.
 Ok, but I disagree for two reasons:
  1. You have to keep in mind than non-vectorized is the default and
 encouraged mode to use. Indeed, it takes a lot of shortcuts like not
 checking header length (so no error stats), etc...

>>> Ok, I will keep non-vectorized same as before.
>>>
  2. It's like saying it's OK it degrades by 5% on $CPU_VENDOR_A because
 the gain is 20% on $CPU_VENDOR_B.

 In the case we see more degradation in real-world scenario, you might
 want to consider using ifdefs to avoid adding padding in the non-
 vectorized case, like you did to differentiate Virtio PMD to Virtio-user
 PMD in patch 7.

>>> Maxime,
>>> The performance difference is so slight, so I ignored for it look like a
>> sampling error.
>>
>> Agree for IO loopback, but it adds one more cache line access per burst,
>> which might be see in some real-life use cases.
>>
>>> It maybe not suitable to add new configuration for such setting which
>> only used inside driver.
>>
>> Wait, the Virtio-user #ifdef is based on the defconfig options? How can
>> it work since both Virtio PMD and Virtio-user PMD can be selected at the
>> same time?
>>
>> I thought it was a define set before the headers inclusion and unset
>> afterwards, but I didn't checked carefully.
>>
> 
> Maxime,
> The difference between virtio PMD and Virtio-user PMD addresses is handled by 
> vq->offset. 
> 
> When virtio PMD is running, offset will be set to buf_iova.
> vq->offset = offsetof(struct rte_mbuf, buf_iova);
> 
> When virtio_user PMD is running, offset will be set to buf_addr.
> vq->offset = offsetof(struct rte_mbuf, buf_addr);

Ok, but below is a build time check:

+#ifdef RTE_VIRTIO_USER
+   __m128i flag_offset = _mm_set_epi64x(flags_temp, (uint64_t)vq->offset);
+#else
+   __m128i flag_offset = _mm_set_epi64x(flags_temp, 0);
+#endif

So how can it work for a single build for both Virtio and Virtio-user?

>>> Virtio driver can check whether virtqueue is using vectorized path when
>> initialization, will use padded structure if it is.
>>> I have added some tested code and now performance came back.  Since
>> code has changed in initialization process,  it need some time for regression
>> check.
>>
>> Ok, works for me.
>>
>> I am investigating a linkage issue with your series, which does not
>> happen systematically (see below, it happens also with clang). David
>> pointed me to some Intel patches removing the usage if __rte_weak,
>> could it be related?
>>
> 
> I checked David's patch, it only changed i40e driver. Meanwhile attribute 
> __rte_weak should still be in virtio_rxtx.c. 
> I will follow David's patch, eliminate the usage of weak attribute. 

Yeah, I meant below issue could be linked to __rte_weak, not that i40e
patch was the cause of this problem.

Re: [dpdk-dev] [PATCH] rte_trace: fix build on PPC64

[Thinh Tran]

Agreed, this is not rte_trace issue. Moving to rte_common.h does not 
work neither, because altivec.h is included after and redefine bool

This conflict happens on PPC64, I'll create a different patch.

Thanks,
Thinh Tran

On 4/28/2020 2:57 AM, Jerin Jacob wrote:

On Tue, Apr 28, 2020 at 3:29 AM Thinh Tran  wrote:


The AltiVec header file breaks boolean type:

In file included from ../lib/librte_mempool/rte_mempool_trace_fp.h:18:0,
  from ../lib/librte_mempool/rte_mempool.h:54,
  from ../lib/librte_mbuf/rte_mbuf.h:38,
  from ../lib/librte_net/rte_ether.h:23,
  from ../drivers/common/mlx5/mlx5_nl.h:10,
  from ../drivers/common/mlx5/mlx5_nl.c:23:
../lib/librte_eal/include/rte_trace_point.h: In function
‘__rte_trace_point_fp_is_enabled’:
../lib/librte_eal/include/rte_trace_point.h:226:9: error: incompatible
types when returning type ‘int’ but ‘__vector __bool int {aka
__vector(4) __bool int}’ was expected
   return false;

This is the same as
  https://git.dpdk.org/dpdk/commit/?id=725f5dd

and yet, there is no better solution for it

Signed-off-by: Thinh Tran 
---
  lib/librte_eal/include/rte_trace_point.h | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/lib/librte_eal/include/rte_trace_point.h 
b/lib/librte_eal/include/rte_trace_point.h
index 4d956ec16..2ede9e3ba 100644
--- a/lib/librte_eal/include/rte_trace_point.h
+++ b/lib/librte_eal/include/rte_trace_point.h
@@ -26,6 +26,12 @@ extern "C" {
  #include 
  #include 

+#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__)
+#undef bool
+/* redefine as in stdbool.h */
+#define bool _Bool
+#endif


NACK.

Please move the fix to rte_common.h or similar as it not specific to trace.
if you do so, the following hack also not need.
https://git.dpdk.org/dpdk/commit/?id=725f5dd


+
  /** The tracepoint object. */
  typedef uint64_t rte_trace_point_t;

--
2.17.1

Re: [dpdk-dev] [PATCH] rte_trace: fix build on PPC64

[David Marchand]

On Tue, Apr 28, 2020 at 5:02 PM Thinh Tran  wrote:
>
> Agreed, this is not rte_trace issue. Moving to rte_common.h does not
> work neither, because altivec.h is included after and redefine bool
> This conflict happens on PPC64, I'll create a different patch.

Please look at Ori patch.
Thanks.

http://patchwork.dpdk.org/patch/69426/

-- 
David Marchand

Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add tm support for shaper config in pkt mode

[Luca Boccassi]

On Tue, 2020-04-28 at 15:45 +0100, Bruce Richardson wrote:
> On Tue, Apr 28, 2020 at 03:06:20PM +0100, Ferruh Yigit wrote:
> > On 4/27/2020 5:59 PM, Jerin Jacob wrote:
> > > On Mon, Apr 27, 2020 at 10:19 PM Ferruh Yigit  
> > > wrote:
> > > > On 4/27/2020 5:29 PM, Jerin Jacob wrote:
> > > > > On Mon, Apr 27, 2020 at 9:42 PM Ferruh Yigit  
> > > > > wrote:
> > > > > > On 4/27/2020 10:19 AM, Dumitrescu, Cristian wrote:
> > > > > > > 
> > > > > > > > -Original Message-
> > > > > > > > From: Yigit, Ferruh 
> > > > > > > > Sent: Saturday, April 25, 2020 9:09 PM
> > > > > > > > To: Dumitrescu, Cristian ; 
> > > > > > > > Nithin Dabilpuram
> > > > > > > > ; Singh, Jasvinder 
> > > > > > > > ;
> > > > > > > > Thomas Monjalon ; Andrew Rybchenko
> > > > > > > > 
> > > > > > > > Cc: dev@dpdk.org; jer...@marvell.com; kka...@marvell.com; Nithin
> > > > > > > > Dabilpuram 
> > > > > > > > Subject: Re: [PATCH v4 1/4] ethdev: add tm support for shaper 
> > > > > > > > config in pkt
> > > > > > > > mode
> > > > > > > > 
> > > > > > > > On 4/24/2020 11:28 AM, Dumitrescu, Cristian wrote:
> > > > > > > > > 
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Nithin Dabilpuram 
> > > > > > > > > > Sent: Wednesday, April 22, 2020 6:21 PM
> > > > > > > > > > To: Singh, Jasvinder ; 
> > > > > > > > > > Dumitrescu, Cristian
> > > > > > > > > > ; Thomas Monjalon
> > > > > > > > > > ; Yigit, Ferruh 
> > > > > > > > > > ; Andrew
> > > > > > > > > > Rybchenko 
> > > > > > > > > > Cc: dev@dpdk.org; jer...@marvell.com; kka...@marvell.com; 
> > > > > > > > > > Nithin
> > > > > > > > > > Dabilpuram 
> > > > > > > > > > Subject: [PATCH v4 1/4] ethdev: add tm support for shaper 
> > > > > > > > > > config in pkt
> > > > > > > > > > mode
> > > > > > > > > > 
> > > > > > > > > > From: Nithin Dabilpuram 
> > > > > > > > > > 
> > > > > > > > > > Some NIC hardware support shaper to work in packet mode i.e
> > > > > > > > > > shaping or ratelimiting traffic is in packets per second 
> > > > > > > > > > (PPS) as
> > > > > > > > > > opposed to default bytes per second (BPS). Hence this patch
> > > > > > > > > > adds support to configure shared or private shaper in 
> > > > > > > > > > packet mode,
> > > > > > > > > > provide rate in PPS and add related tm capabilities in 
> > > > > > > > > > port/level/node
> > > > > > > > > > capability structures.
> > > > > > > > > > 
> > > > > > > > > > This patch also updates tm port/level/node capability 
> > > > > > > > > > structures with
> > > > > > > > > > exiting features of scheduler wfq packet mode, scheduler 
> > > > > > > > > > wfq byte mode
> > > > > > > > > > and private/shared shaper byte mode.
> > > > > > > > > > 
> > > > > > > > > > SoftNIC PMD is also updated with new capabilities.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Nithin Dabilpuram 
> > > > > > > > > > ---
> > > > > > > > > > v3..v4:
> > > > > > > > > > - Update text under packet_mode as per Cristian.
> > > > > > > > > > - Update rte_eth_softnic_tm.c based on Jasvinder's comments.
> > > > > > > > > > - Add error enum
> > > > > > > > RTE_TM_ERROR_TYPE_SHAPER_PROFILE_PACKET_MODE
> > > > > > > > > > - Fix shaper_profile_check() with packet mode check
> > > > > > > > > > - Fix typo's
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Acked-by: Cristian Dumitrescu 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Hi Nithin,
> > > > > > > > 
> > > > > > > > It looks like patch is causing ABI break, I am getting 
> > > > > > > > following warning [1],
> > > > > > > > can you please check?
> > > > > > > > 
> > > > > > > > [1]
> > > > > > > > https://pastebin.com/XYNFg14u
> > > > > > > 
> > > > > > > Hi Ferruh,
> > > > > > > 
> > > > > > > The RTE_TM API is marked as experimental, but it looks that this 
> > > > > > > was not correctly marked when __rte_experimental ABI checker was 
> > > > > > > introduced.
> > > > > > > 
> > > > > > > It is marked as experimental at the top of the rte_tm.h, 
> > > > > > > similarly to other APIs introduced around same time, but it was 
> > > > > > > not correctly picked up by the ABI check procedure when later 
> > > > > > > introduced, so __rte_experimental was not added to every function.
> > > > > > > 
> > > > > > 
> > > > > > :(
> > > > > > 
> > > > > > Is it time to mature them?
> > > > > > 
> > > > > > As you said they are not marked as experimental both in header file 
> > > > > > (function
> > > > > > declarations) and .map file.
> > > > > > 
> > > > > > The problem is, they are not marked as experimental in DPDK_20.0 
> > > > > > ABI (v19.11),
> > > > > > so marking them as experimental now will break the ABI. Not sure 
> > > > > > what to do,
> > > > > > cc'ed a few ABI related names for comment.
> > > > > > 
> > > > > > For me, we need to proceed as the experimental tag removed and APIs 
> > > > > > become
> > > > > > mature starting from v19.11, since this is what happened in 
> > > > > > practice, and remove
> > > > > > a few existing being expe

Re: [dpdk-dev] [PATCH] rte_trace: fix build on PPC64

[Thinh Tran]

I looked at it, but I have a simpler patch below that can resolve the 
conflict, including after removing previous patches in mlx4/mlx5


Thanks,
Thinh Tran

 diff --git a/lib/librte_eal/ppc/include/rte_memcpy.h 
b/lib/librte_eal/ppc/include/rte_memcpy.h

index 25311ba1d..abeede231 100644
--- a/lib/librte_eal/ppc/include/rte_memcpy.h
+++ b/lib/librte_eal/ppc/include/rte_memcpy.h
@@ -11,6 +11,10 @@
 /*To include altivec.h, GCC version must  >= 4.8 */
 #include 

+/* redefine as in stdbool.h */
+#undef bool
+#define bool _Bool
+
 #ifdef __cplusplus
 extern "C" {
 #endif

On 4/28/2020 10:04 AM, David Marchand wrote:

On Tue, Apr 28, 2020 at 5:02 PM Thinh Tran  wrote:


Agreed, this is not rte_trace issue. Moving to rte_common.h does not
work neither, because altivec.h is included after and redefine bool
This conflict happens on PPC64, I'll create a different patch.


Please look at Ori patch.
Thanks.

http://patchwork.dpdk.org/patch/69426/

Re: [dpdk-dev] [PATCH v3 2/2] vhost: binary search address mapping table

[Maxime Coquelin]

On 4/28/20 11:13 AM, Marvin Liu wrote:
> If Tx zero copy enabled, gpa to hpa mapping table is updated one by
> one. This will harm performance when guest memory backend using 2M
> hugepages. Now utilize binary search to find the entry in mapping
> table, meanwhile set threshold to 256 entries for linear search.
> 
> Signed-off-by: Marvin Liu 
> 
> diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile
> index e592795f2..8769afaad 100644
> --- a/lib/librte_vhost/Makefile
> +++ b/lib/librte_vhost/Makefile
> @@ -10,7 +10,7 @@ EXPORT_MAP := rte_vhost_version.map
>  
>  CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
>  CFLAGS += -I vhost_user
> -CFLAGS += -fno-strict-aliasing
> +CFLAGS += -fno-strict-aliasing -Wno-maybe-uninitialized
>  LDLIBS += -lpthread
>  
>  ifeq ($(RTE_TOOLCHAIN), gcc)
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> index 507dbf214..a0fee39d5 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -546,20 +546,46 @@ extern int vhost_data_log_level;
>  #define MAX_VHOST_DEVICE 1024
>  extern struct virtio_net *vhost_devices[MAX_VHOST_DEVICE];
>  
> +#define VHOST_BINARY_SEARCH_THRESH 256
> +static int guest_page_addrcmp(const void *p1, const void *p2)
> +{
> + const struct guest_page *page1 = (const struct guest_page *)p1;
> + const struct guest_page *page2 = (const struct guest_page *)p2;
> +
> + if (page1->guest_phys_addr > page2->guest_phys_addr)
> + return 1;
> + if (page1->guest_phys_addr < page2->guest_phys_addr)
> + return -1;
> +
> + return 0;
> +}
> +
>  /* Convert guest physical address to host physical address */
>  static __rte_always_inline rte_iova_t
>  gpa_to_hpa(struct virtio_net *dev, uint64_t gpa, uint64_t size)
>  {
>   uint32_t i;
>   struct guest_page *page;
> -
> - for (i = 0; i < dev->nr_guest_pages; i++) {
> - page = &dev->guest_pages[i];
> -
> - if (gpa >= page->guest_phys_addr &&
> - gpa + size < page->guest_phys_addr + page->size) {
> - return gpa - page->guest_phys_addr +
> -page->host_phys_addr;
> + struct guest_page key;
> +
> + if (dev->nr_guest_pages >= VHOST_BINARY_SEARCH_THRESH) {

I would have expected the binary search to be more efficient for much
smaller number of pages. Have you done some tests to define this
threshold value?

> + key.guest_phys_addr = gpa;
> + page = bsearch(&key, dev->guest_pages, dev->nr_guest_pages,
> +sizeof(struct guest_page), guest_page_addrcmp);
> + if (page) {
> + if (gpa + size < page->guest_phys_addr + page->size)
> + return gpa - page->guest_phys_addr +
> + page->host_phys_addr;
> + }

Is all the generated code inlined?

I see that in the elf file:
2386: 00874f7016 FUNCLOCAL  DEFAULT   13 guest_page_addrcmp

> + } else {
> + for (i = 0; i < dev->nr_guest_pages; i++) {
> + page = &dev->guest_pages[i];
> +
> + if (gpa >= page->guest_phys_addr &&
> + gpa + size < page->guest_phys_addr +
> + page->size)
> + return gpa - page->guest_phys_addr +
> +page->host_phys_addr;
>   }
>   }
>  
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> index 79fcb9d19..15e50d27d 100644
> --- a/lib/librte_vhost/vhost_user.c
> +++ b/lib/librte_vhost/vhost_user.c
> @@ -965,6 +965,12 @@ add_guest_pages(struct virtio_net *dev, struct 
> rte_vhost_mem_region *reg,
>   reg_size -= size;
>   }
>  
> + /* sort guest page array if over binary search threshold */
> + if (dev->nr_guest_pages >= VHOST_BINARY_SEARCH_THRESH) {
> + qsort((void *)dev->guest_pages, dev->nr_guest_pages,
> + sizeof(struct guest_page), guest_page_addrcmp);
> + }
> +
>   return 0;
>  }
>  
>