CODEWITHSUNDEEP
linuxbpfebpf
Vector
Vector

Reputation: 77

What are the limitations of bpf virtual machine and bpf map？

I am using ebpf+XDP to make some demo.

when I use a large memory MAP, for example:

BPF_HASH(cache, u64, u64, 10240000);
BPF_HASH(filter1, u32, u64, 10240000);
BPF_HASH(filter2, struct XXX, u16, 10240000);

when I run this demo, After running for a while, the program is automatically killed.

here is the error said:

Out of memory: KIll process 1618 (sshd) score 0 or sacrifice child
Killed process 1618 (sshd) total-vm:625792kB, anon-rss:0kB, file-rss:4kB, shmem-rss:0kB

I do not understand what dose this error mean.

Is this the system limit or bpf vm limit or map limit ?

Here is the result when I run "free -g".

              total        used        free      shared  buff/cache   available
Mem:              3           0           3           0           0           3
Swap:             3           0           3

Upvotes: 3

Views: 4430

Answers (1)

Qeole
Qeole

Reputation: 9114

When you create BPF maps, memory is allocated in kernel space for those maps. Obviously, the bigger they are, the more memory is needed.

While BPF has virtually no limitation on the size of the maps (other than the maximum value for the 32 bit unsigned integer which is passed to the kernel to give map size), the kernel itself has constraints due to the underlying hardware. If the kernel were to run completely out of memory, Bad Things Would Happen. Typically, it would hang or crash. To avoid that, when memory becomes scarce, the Out Of Memory (OOM) killer goes into action and kills a process, as an attempt to free memory.

From what I understand, this is what happens in your case. The limit is not from BPF or BPF maps, but simply from your system (kernel) running out of memory. You can maybe obtain more information in kernel logs with dmesg when the kill occurs (see also how to read the logs).

So to answer to the question as you phrased in the title: BPF maps are not limited in size, other than by the maximum value we can possibly pass to the bpf() system call (a uint_32, so that's about 4GB). Non-root users may have additional restrictions on the amount of space they may be able to lock in the kernel (root can remove those restrictions with ulimit -l in the shell or setrlimit() in a C program). Other “limits” for the BPF infrastructure exist (stack size, number of tail calls, etc.) but I do not think listing all of them here would help much. You can find more information about them in the Cilium guide.

Upvotes: 5

Related Questions