Re: [dpdk-dev] [PATCH v9] net/ice: optimize protocol extraction by dynamic mbuf API

[Thomas Monjalon <thomas@monjalon.net>]

08/11/2019 15:01, Wang, Haiyue:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 07/11/2019 11:44, Haiyue Wang:
> > > --- a/drivers/net/ice/rte_pmd_ice_version.map
> > > +++ b/drivers/net/ice/rte_pmd_ice_version.map
> > > +EXPERIMENTAL {
> > > +	global:
> > > +
> > > +	# added in 19.11
> > > +	rte_net_ice_dynfield_proto_xtr_metadata_offs;
> > > +	rte_net_ice_dynflag_proto_xtr_vlan_mask;
> > > +	rte_net_ice_dynflag_proto_xtr_ipv4_mask;
> > > +	rte_net_ice_dynflag_proto_xtr_ipv6_mask;
> > > +	rte_net_ice_dynflag_proto_xtr_ipv6_flow_mask;
> > > +	rte_net_ice_dynflag_proto_xtr_tcp_mask;
> > > +};
> > 
> > Given that you provide some functions to access to the metadata,
> > why do you need to export these flags and field in the .map?
> >
> > However, the functions are missing in the .map.
> > Did you try to compile as a shared library?
> > 
> 
> These functions are 'static inline', no need to be exported in the

Yes I missed they are inline.

> .map. And the macros like 'PKT_RX_DYNF_PROTO_XTR_XXX', in fact, their
> real definitions are global values defined in rte_pmd_ice like:
> rte_net_ice_dynflag_proto_xtr_xxx_mask.
> 
> Since rte_pmd_ice are required to compiled as a shared library, so
> it is needed to export these flags and field in the .map.
> 
> This design is referred to the below upstream practice about dynamic
> mbuf.
> 
> commit 7743e81854944ed17df05bfdcba26556cb41ca0c
> Author: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> Date:   Tue Nov 5 14:19:30 2019 +0000
> 
>     ethdev: extend flow metadata
> 
> --- a/lib/librte_ethdev/rte_ethdev_version.map
> +++ b/lib/librte_ethdev/rte_ethdev_version.map
> @@ -289,4 +289,7 @@ EXPERIMENTAL {
>         rte_eth_rx_hairpin_queue_setup;
>         rte_eth_tx_burst_mode_get;
>         rte_eth_tx_hairpin_queue_setup;
> +       rte_flow_dynf_metadata_offs;
> +       rte_flow_dynf_metadata_mask;
> +       rte_flow_dynf_metadata_register;
>  };

Yes all these internals are exported because we use macros
or inline functions.
Matter of tradeoff between API cleaning and performance...