On 6/10/25 11:47 AM, Pablo Neira Ayuso wrote:
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.
This looks good to me. Let me include it on my series and extend the
free interface.
Thanks Pablo!
Would probably require a few more api calls including iterators.
Fernando, do you spot anything else thats missing for your use cases?
