On Thu, Jun 12, 2025 at 03:01:44PM +0200, Fernando Fernandez Mancera wrote: > > > 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. Sure, go ahead, thanks.
