[EXT] Re: [PATCH v9 3/6] ethdev: add trace points for ethdev (part two)

[Ferruh Yigit]

On 2/8/2023 11:00 AM, Ferruh Yigit wrote:
> On 2/8/2023 10:42 AM, Ankur Dwivedi wrote:
>>>> +RTE_TRACE_POINT(
>>>> +	rte_ethdev_trace_set_mc_addr_list,
>>>> +	RTE_TRACE_POINT_ARGS(uint16_t port_id,
>>>> +		const struct rte_ether_addr *mc_addr_set, uint32_t
>>> nb_mc_addr,
>>>> +		int ret),
>>>> +	rte_trace_point_emit_u16(port_id);
>>>> +	rte_trace_point_emit_ptr(mc_addr_set);
>>> What about recording this as blob?
>>> But 'mc_addr_set' is array of addresses, so length needs to be
>>> 'RTE_ETHER_ADDR_LEN * nb_mc_addr'.
>> The mc_addr_set pointer can be NULL in rte_eth_dev_set_mc_addr_list. In that case the
>> blob function will give seg fault. Hence I think blob cannot be used here.
> Does it make sense to make 'rte_trace_point_emit_blob()' accept NULL and
> fill all array with 0 in that case to cover this kind of cases?


btw, 'rte_trace_point_emit_blob()' already checks for NULL, so expect it
won't give segmentation fault, but won't record the value.
Not sure if not recording the value cause problem later when parsing the
trace file.