On 05/18/2017 05:41 PM, Jesper Dangaard Brouer wrote:
There is no reason to use a compile time constant MAX_IPTNL_ENTRIES
shared between the _user.c and _kern.c, when map_data[].def.max_entries
can tell us dynamically what the max_entries were of the ELF map that
the bpf loaded created.
Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com>
Previous code was perhaps a bit more robust in the sense that the
order of the map wouldn't matter due to MAX_IPTNL_ENTRIES being
shared. Now you rely on it being in slot 1 (map_data[1].def.max_entries)
from "maps" section in ELF.
samples/bpf/xdp_tx_iptunnel_common.h | 2 --
samples/bpf/xdp_tx_iptunnel_kern.c | 2 +-
samples/bpf/xdp_tx_iptunnel_user.c | 14 +++++++++-----
3 files changed, 10 insertions(+), 8 deletions(-)
Not sure it's worth it given this actually adds more code and makes
it more fragile at the same time. Only point I could see is to demo
usage of map_data[1].def.max_entries for sample code.
Perhaps at the very minimum add a warning comment to xdp_tx_iptunnel_kern.c
that should the code be further extended with additional maps, that
ordering of struct bpf_map_def entries really matters here to not break
the _user.c part.
Other than that, this should be sent as stand-alone "cleanup" ...
