gatekeeper
gatekeeper copied to clipboard
gt_lpm_ud expected, got number error in version 1.1.0
gt_lpm_ud does not exist in version 1.0.0, gt_lpm_ud expected, got number appears after upgrading to 1.1.0
How did you upgrade? Please describe how to reproduce the problem.
I cleared the old dpdk and used the latest linux kernel 5.4.0-122-generic and recompiled gatekeeper os :Ubuntu 20.04.4 LTS
5.4.0-110 The kernel after this version no longer supports igb_uio, can't use more than this kernel version with dpdk 20.11?
Annotated the code for lpm initialization, GT can already run normally, examples/policy.lua, But I use gkctl to reload policy.lua, and still continue to report the following error /opt/gatekeeper1.1.0/lua/examples/policy.lua:192: bad argument #1 to 'lpm_add' (gt_lpm_ud expected, got number)
5.4.0-110 The kernel after this version no longer supports igb_uio, can't use more than this kernel version with dpdk 20.11?
You are right; the kernel module igb_uio
is no longer the preferred way to allocate NICs to DPDK. Instead, the kernel module vfio-pci
is the preferred choice now. See section "Enable the kernel module vfio-pci
" in the README.md file of v1.1.0 to see how to use this newer kernel module.
Annotated the code for lpm initialization, GT can already run normally, examples/policy.lua, But I use gkctl to reload policy.lua, and still continue to report the following error /opt/gatekeeper1.1.0/lua/examples/policy.lua:192: bad argument #1 to 'lpm_add' (gt_lpm_ud expected, got number)
This problem seems similar to the one you reported in Issue #581. But I haven't had the chance to investigate this problem further.
I completely emptied, gatekeeper all 1.0.0 files and dpdk, reinstalled 1.1.0, still the same error occurs. I installed the GK server in the same way without any problems and it can run normally, but the GT server cannot initialize the LPM at all, and it can be successfully started by skipping the LPM. However, policy settings cannot be made for LPM. From the log, bad argument #1 to 'lpm_add' (gt_lpm_ud expected, got number), this error means that the obtained gt_lpm_ud is not an object handle, but a number. Is it caused by the non-object handle returned by new_lpm?
You are right, the bug was in lpmlib.new_lpm()
. I just merged pull request #610 which fixes this issue.