>> >> Add ptype set default functionality i.e. enable ptype by default and >> report ptypes even if application disables ptypes. >> >> Signed-off-by: Pavan Nikhilesh <pbhagavat...@marvell.com> > >May be it is better to have >rte_ethdev_supported_ptype_set_dummy() >in ethdev library and use it in PMDs instead of duplicating the function >in all drivers. Or even treat NULL as dummy? It will remove the patch >completely.
But how would we differentiate drivers that actually support ptypes vs drivers that don’t do ptypes at all?. Maybe we could return the OR'd result of get_ptypes for now? To summarize: If we agree that rte_eth_dev_set_supported_ptypes() will return successfully set ptype mask then: 1. If PMD doesn’t support get then we can return 0, application will softparse ptypes. 2. If a subset of ptypes requested by the application through `set_supported_ptypes` are not supported then it will return subset of ptypes that are supported set and rest will be parsed in software. 3. If we choose to not have [6/7] i.e. if a PMD has a get function but not set function we can match the masks in `rte_eth_dev_set_supported_ptypes` and return supported ptype mask. 4. If application calls `rte_eth_dev_set_supported_ptypes` with mask as '0' then packet_type might be undefined. Let me know your thoughts. Thanks, Pavan
