[dpdk-dev] [PATCH v3 01/12] ethdev: add API to query packet type filling info
Tan, Jianfeng
jianfeng.tan at intel.com
Thu Feb 25 17:36:17 CET 2016
Hi Konstantin,
On 2/25/2016 11:46 PM, Ananyev, Konstantin wrote:
> Hi Jainfeng,
>
>> Add a new API rte_eth_dev_get_ptype_info to query whether/what packet
>> type can be filled by given pmd rx burst function.
>>
>> Signed-off-by: Jianfeng Tan <jianfeng.tan at intel.com>
>> ---
>> lib/librte_ether/rte_ethdev.c | 32 ++++++++++++++++++++++++++++++++
>> lib/librte_ether/rte_ethdev.h | 23 +++++++++++++++++++++++
>> 2 files changed, 55 insertions(+)
>>
>> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
>> index 1257965..b52555b 100644
>> --- a/lib/librte_ether/rte_ethdev.c
>> +++ b/lib/librte_ether/rte_ethdev.c
>> @@ -1576,6 +1576,38 @@ rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info)
>> dev_info->driver_name = dev->data->drv_name;
>> }
>>
>> +int
>> +rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask,
>> + uint32_t **p_ptypes)
>> +{
>> + int i, j, ret;
>> + struct rte_eth_dev *dev;
>> + const uint32_t *all_ptypes;
>> +
>> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>> + dev = &rte_eth_devices[port_id];
>> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_ptype_info_get, -ENOTSUP);
>> + all_ptypes = (*dev->dev_ops->dev_ptype_info_get)(dev);
>> +
>> + if (!all_ptypes)
>> + return 0;
>> +
>> + for (i = 0, ret = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
>> + if (all_ptypes[i] & ptype_mask)
>> + ret++;
>> + if (ret == 0)
>> + return 0;
>> +
>> + *p_ptypes = (uint32_t *)malloc(sizeof(uint32_t) * ret);
>> + if (*p_ptypes == NULL)
>> + return -ENOMEM;
>
> I thought we all agreed to follow snprintf()-like logic and avoid any memory allocations inside that function.
> So why malloc() again?
> Konstantin
>
Sorry for the setback. I still have concerns that snprintf()-like needs
to be called twice by an application to get the ptype info. So I write
this implementation for you to comment.
So what's the reason why we should avoid memory allocations inside that
function?
Thanks,
Jianfeng
More information about the dev
mailing list