On Mon, Jul 3, 2017 at 7:40 AM, Elo, Matias (Nokia - FI/Espoo) <[email protected]> wrote: > Ping.
Is the rest of the patch (implementation, validation test updates, doc updates) in preparation? The API changes have already been reviewed by both Petri and me. > > >> On 5 Jun 2017, at 10:11, Elo, Matias (Nokia - FI/Espoo) >> <[email protected]> wrote: >> >> >>> On 2 Jun 2017, at 16:48, Maxim Uvarov <[email protected]> wrote: >>> >>> On 06/02/17 12:44, Elo, Matias (Nokia - FI/Espoo) wrote: >>>>>> >>>>>> /** >>>>>> + * System huge page sizes in bytes >>>>>> + * >>>>>> + * Returns the number of huge page sizes supported by the system. >>>>>> Outputs up to >>>>>> + * 'num' sizes when the 'size' array pointer is not NULL. If return >>>>>> value is >>>>>> + * larger than 'num', there are more supported sizes than the function >>>>>> was >>>>>> + * allowed to output. If return value (N) is less than 'num', only sizes >>>>>> + * [0 ... N-1] have been written. Returned values are ordered from >>>>>> smallest to >>>>>> + * largest. >>>>>> + * >>>>>> + * @param[out] size Points to an array of huge page sizes for output >>>>>> + * @param num Maximum number of huge page sizes to output >>>>>> + * >>>>>> + * @return Number of supported huge page sizes >>>>>> + * @retval 0 on no huge pages >>>>>> + */ >>>>>> +unsigned odp_sys_huge_page_size_all(uint64_t size[], unsigned num); >>>>>> + >>>>> >>>>> I think it has to be int. -1 on error, 0 - no hp, > 0 pages. >>>>> For linux it might be similar to getpagesizes() >>>>> https://linux.die.net/man/3/getpagesizes >>>>> """ >>>>> if pagesizes is NULL and n_elem is 0, then the number of pages the >>>>> system supports is returned. Otherwise, pagesizes is filled with at most >>>>> n_elem page sizes. >>>>> """ >>>>> >>>> >>>> getpagesizes() returns -1 in a case of invalid function arguments. >>>> odp_sys_huge_page_size_all() is documented so that the application cannot >>>> pass invalid arguments. So an internal error would be the only >>>> possibility. I don't see this to be likely as the function is only reading >>>> system info. >>>> >>>> Adding -1 return value would also increase application complexity as the >>>> error return value would require special handling from application. >>>> >>> >>> We have to be consistent with all odp api functions. We do not have >>> unsigned function, they are int. >> >> We do have odp_pktio_max_index(), which returns unsigned, and anyway this >> shouldn't be a reason not to use otherwise valid return value. Regarding >> consistency, not returning -1 follows the same return value style as the >> rest of the functions in system_info.h (odp_sys_huge_page_size(), >> odp_sys_page_size(), odp_sys_cache_line_size()). >> >>> This function is not fast path so >>> additional check is ok. And -1 can be returned on permission error to >>> assess /proc or /sys files for example or any other internal failure. >> >> From application point of view the outcome is still the same (no huge pages) >> and returning -1 would make this function inconsistent with the other >> functions in this module as noted above. >> >> -Matias >> >> >
