Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > Hmm, this looks like the API leaks internal data layout from nftables to > > libnftnl and vice versa? IMO thats a non-starter, sorry. > > > > I see that options are essentially unlimited values, so perhaps nftables > > should build the netlink blob(s) directly, similar to nftnl_udata()? > > > > Pablo, any better idea? > > Maybe this API for tunnel options are proposed in this patch? Looks good, thanks Pablo! > Consider this a sketch/proposal, this is compiled tested only. > > struct obj_ops also needs a .free interface to release the tunnel > options object. nftnl_tunnel_opts_set() seems to be useable for erspan and vxlan. Do you have a suggestion for the geneve case where 'infinite' options get added? Maybe add nftnl_tunnel_opts_append() ? Or nftnl_tunnel_opts_add(), so api user can push multiple option objects to a tunnel, similar to how rules get added to chains? Would probably require a few more api calls including iterators. Fernando, do you spot anything else thats missing for your use cases?
