v2: fix to prefer closest match
get_hugepage_dir() was implemented in such a way that a --huge-dir option had to
exactly match the mountpoint, but there's no reason for this restriction. Fix
the implementation to allow a sub-directory within a suitable hugetlbfs
mountpoint to be specified, preferring the closest match.
Signed-of
get_hugepage_dir() was implemented in such a way that a --huge-dir option
had to exactly match the mountpoint, but there's no reason for this
restriction. Fix the implementation to allow a sub-directory within a
suitable hugetlbfs mountpoint to be specified.
Signed-off-by: John Levon
---
lib/eal
get_hugepage_dir() was implemented in such a way that a --huge-dir
option had to exactly match the mountpoint, but there's no reason for
this restriction: DPDK might not be the only user of hugepages, and
shouldn't assume it owns an entire mountpoint. For example, if I have
/dev/hugepages/myapp, an
On Tue, Aug 17, 2021 at 10:05 PM John Levon wrote:
> On Mon, Aug 09, 2021 at 12:24:34PM +0100, John Levon wrote:
>
> > get_hugepage_dir() was implemented in such a way that a --huge-dir
> > option had to exactly match the mountpoint, but there's no reason for
> > this restriction: DPDK might not b
On Mon, Aug 9, 2021 at 4:54 PM John Levon wrote:
>
> get_hugepage_dir() was implemented in such a way that a --huge-dir
> option had to exactly match the mountpoint, but there's no reason for
> this restriction: DPDK might not be the only user of hugepages, and
> shouldn't assume it owns an entire
On Mon, Aug 09, 2021 at 12:24:34PM +0100, John Levon wrote:
> get_hugepage_dir() was implemented in such a way that a --huge-dir
> option had to exactly match the mountpoint, but there's no reason for
> this restriction: DPDK might not be the only user of hugepages, and
> shouldn't assume it owns
7 matches
Mail list logo
