> On 6/19/2024 11:11 AM, Chaoyong He wrote:
> > From: Long Wu <long...@corigine.com>
> >
> > The Rx packet type offload feature may affect the performance, so add
> > a control flag for applications to turn it on or off.
> >
> > Signed-off-by: Long Wu <long...@corigine.com>
> > ---
> > lib/ethdev/rte_ethdev.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > 548fada1c7..be86983e24 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -1555,6 +1555,7 @@ struct rte_eth_conf { #define
> > RTE_ETH_RX_OFFLOAD_OUTER_UDP_CKSUM RTE_BIT64(18)
> > #define RTE_ETH_RX_OFFLOAD_RSS_HASH RTE_BIT64(19)
> > #define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT RTE_BIT64(20)
> > +#define RTE_ETH_RX_OFFLOAD_PTYPES RTE_BIT64(21)
> >
> > #define RTE_ETH_RX_OFFLOAD_CHECKSUM
> (RTE_ETH_RX_OFFLOAD_IPV4_CKSUM | \
> > RTE_ETH_RX_OFFLOAD_UDP_CKSUM | \
>
> Hi Chaoyong,
>
> Instead of having an offload for ptypes, we have APIs for this,
>
> First one is 'rte_eth_dev_get_supported_ptypes()' that application can learn
> the supported packet types.
>
> Second one is more related to above flag, it is 'rte_eth_dev_set_ptypes()'
> which application can set which pytpes is required, it can be set to disable
> all
> packet type parsing, can be similar to not requesting
> 'RTE_ETH_RX_OFFLOAD_PTYPES'.
>
> With above two APIs, do we still need the offload flag?
>
At present, the purpose of the ops 'rte_eth_dev_set_ptypes()' is to set the
range of packet types to handle.
Of course, we can maintain a flag for each application and driver based on the
return value of this ops;
but this is a bit troublesome.
So, we hope to follow the example of RSS, in addition to
'rte_eth_dev_rss_hash_update()' and 'rte_eth_dev_rss_hash_conf_get()', we also
want to set a flag for
the ptype function similar to RTE_ETH_RX_OFFLOAD_RSS_HASH.
>
> Another concern with adding new offload flag is backward compatibility, all
> existing drivers that support packet type parsing should be updated to list
> this
> offload flag as capability. Also they need to be updated to configure packet
> parsing based on user requested offload configuration.
>
If you agree with this design suggestion, we will adapt all the related code to
ptypes for each PMDs and 'test-pmd' applications in the next patch.
Do you think this okay?
> Briefly, we can't just introduce a new offload flag for an existing
> capability and
> update only one driver, all drivers needs to be updated.
