Right. Most if not all maps(as I did not check everyone) has a roughly 4GB limit on total map memory consumption per map. The return error code will be -E2BIG. On Fri, Jan 26, 2018 at 7:05 PM, Zvi Effron <zeffron@xxxxxxxxxxxxx> wrote: > Hello, > > There is a hard limit, I've run into it before. Assuming the error > you're getting is E2BIG (which I believe indicates you've hit the > limit), then it's possible to figure out how much space (and how many > entries) are available for what you're storing by looking at the code > from https://elixir.free-electrons.com/linux/latest/source/kernel/bpf/hashtab.c#L304 > through line 341 (if I've traced things through the kernel correctly). > > In my project, I worked around the limitation by using a map of maps. > That allowed me multiply the storage available to me and significantly > go past the limit (I ran out of memory well before I couldn't create > the map do to limitations). > > Best, > --Zvi > > On Fri, Jan 26, 2018 at 1:58 PM, Eric Leblond <eric@xxxxxxxxx> wrote: >> Hello, >> >> I've just finished the initial version of eBPF and XDP support in >> Suricata [1] (thanks Jesper for the help) and among other eBPF features >> the code is using CPU_ARRAY_MAP to store a flow table in Ipv4 and IPv6. >> >> The max_entries is set to 32768 in the code [2] but I did give a try to >> higher value. On my 8 cores system, the allocation of the memory for >> the IPv6 table failed between 2000000 and 3000000. >> >> Is there some kind of hard limit or a formula to compute the max ? >> >> How will evolve performances if we increase the max_entries ? >> >> Link: >> [1]: https://github.com/OISF/suricata/pull/3193 >> [2]: https://github.com/OISF/suricata/pull/3193/files#diff-97ad4f31d96b >> db666457562cea00a57aR85 >> >> Best regards, >> -- >> Eric Leblond <eric@xxxxxxxxx> >> Blog: https://home.regit.org/
|