Srivats P <pstavirs@xxxxxxxxx> writes:
> Hi,
>
> The sample xdpsock_user.c program does a setrlimit(RLIMIT_MEMLOCK) but
> subsequently doesn't do a mlock or pass MAP_LOCKED flag to mmap().
> Same with xdp-tutorial which has the following comment but I don't see
> any locking happening anywhere in the code.
>
> /* Allow unlimited locking of memory, so all memory needed for packet
> * buffers can be locked.
> */
>
> What is the purpose behind this setrlimit? Does the libbpf/xdp library
> do a mlock internally?
>
> I came to know that BPF maps need the setrlimit and I assume the xsk
> APIs create a XSK map internally - so is that the only reason?
Yes, the setrlimit() is there because all BPF objects in the kernel
(including maps and programs) were accounted against that limit, and it
was a global limit, making it basically impossible to predict what a
good value was. Thankfully, this has since been fixed and maps are now
accounted using memcgs, as of commit: 97306be45fbe ("Merge branch
'switch to memcg-based memory accounting'") which was included in the
5.11 kernel release. So if your kernel is new enough you don't need the
setrlimit() anymore; but I guess no one has bothered to update the
samples yet :)
-Toke
|