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. 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. Maxim. >> >> But why do we need this inside ODP? It time be reasonable to say that >> it's number of pages/sizes visible to current ODP instance (i.e. not the >> system global.) >> > > A system can simultaneously support multiple huge page sizes and an > application may > for example do some alignment decisions based on this information. I found > this issues when implementing shm for odp-dpdk and trying to pass the > validation tests. This API change enables adding a proper test for > odp_shm_info_t.page_size. > > -Matias > >
