Josep Puigdemont(joseppc) 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:
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_r151410000
updated_at 2017-11-17 16:48:29
