On Tue, Jun 10, 2025 at 08:01:41AM +0200, Florian Westphal wrote: > 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? nftnl_tunnel_opts_add() sounds good. It should be possible to replace nftnl_tunnel_opts_set() by nftnl_tunnel_opts_add(), then a single function for this purpose is provided. As for vxlan and erpan, allow only one single call to nftnl_tunnel_opts_add(). See attachment, compile tested only. > Would probably require a few more api calls including iterators. > > Fernando, do you spot anything else thats missing for your use cases?
