On 30 Oct 2018, at 14:29, Bjoern A. Zeeb wrote:
On 30 Oct 2018, at 12:23, Kristof Provost wrote:
I’m not too familiar with this part of the vnet code, but it looks to me like we’ve got more per-vnet variables that was originally anticipated, so we may need to just increase the allocated space.

Can you elfdump -a the two modules and see how big their set_vnet section sizes are? I see:

pf.ko:  sh_size: 6664
ipl.ko: sh_size: 2992

I see exactly the same numbers.

VNET_MODMIN is two pages (8k). So yes, that would exceed the module space. Having 6.6k global variable space is a bit excessive? Where does that come from? multicast used to have a similar problem in the past that it could not be loaded as a module as it had a massive array there and we changed it to be malloced and that reduced it to a pointer.

0000000000000f38 l O set_vnet 0000000000000428 vnet_entry_pfr_nulltable
That’s a default table. It’s large because it uses MAXPATHLEN for the pfrt_anchor string.

0000000000000b10 l O set_vnet 00000000000003d0 vnet_entry_pf_default_rule
Default rule. Rules potentially contain names, tag names, interface names, … so it’s a large structure.

0000000000001370 l O set_vnet 0000000000000690 vnet_entry_pf_main_anchor
Anchors use MAXPATHLEN for the anchor path, so that’s 1024 bytes right away.

0000000000000000 l O set_vnet 0000000000000120 vnet_entry_pf_status

pf status. Mostly counters.

I’ll see about putting moving those into the heap on my todo list.

Best regards,
Kristof
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to