bogdanPricope replied on github web page:
platform/linux-generic/pktio/tap.c
line 10
@@ -92,23 +92,30 @@ static int tap_pktio_open(odp_pktio_t id ODP_UNUSED,
int fd, skfd, flags;
uint32_t mtu;
struct ifreq ifr;
- pktio_ops_tap_data_t *tap = odp_ops_data(pktio_entry, tap);
+ pktio_ops_tap_data_t *tap = NULL;
if (strncmp(devname, "tap:", 4) != 0)
return -1;
+ if (pool == ODP_POOL_INVALID)
Comment:
No, this pool is used to allocate packets (for recv side).
> Josep Puigdemont(joseppc) wrote:
> Ok, I may be splitting hairs now, but I thought we were just checking whether
> the pool parameter passed to pktio_open was valid, and bail out if not. We
> are not actually using this pool to allocate this pktio's private data, right?
>> bogdanPricope wrote
>> Alloc/free vs. array has this disadvantage: you need to allocate the memory
>> at some point and free it if the operation fails for any reason. It is
>> better to delay the allocation until after some common checks.
>>
>> stncmp: open calls are not on fast path ... no reason to optimize the
>> performance ... but repeated memory alloc/free may affect some pool
>> implementations
>>> bogdanPricope wrote
>>> It will require a cast when is called.
>>> A pktio_type may implement another way to allocate memory starting form the
>>> name of the pool / is not mandatory to use those macros but are helpful for
>>> existing pktio types.
>>>> bogdanPricope wrote
>>>> _p comes form (pktio_entry_t *)
>>>>> Josep Puigdemont(joseppc) wrote:
>>>>> It probably belongs to its own patch, but now that you are at it, it
>>>>> could even be moved even further up, as it is probably faster than
>>>>> checking for "tap:" in the device string.
>>>>>> Josep Puigdemont(joseppc) wrote:
>>>>>> (_p)? There are a couple more, also in odp_ops_data_free.
>>>>>>> Josep Puigdemont(joseppc) wrote:
>>>>>>> Maybe we can return (void *)? This way we would not care if pktios name
>>>>>>> (or define) their private structures according to the naming
>>>>>>> conventions implicit in the macro.
https://github.com/Linaro/odp/pull/297#discussion_r151413393
updated_at 2017-11-17 16:48:29
