On Wed, Oct 11, 2023 at 04:00:07PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > Rationale was that if you have no rules that check on labels then > > > there is never a need to allocate the space. > > > > > > I'm working on a patchset that will also set/enable the label > > > extension if its enabled on the template. The idea is to convert > > > ovs and act_ct to it, currently they point-blank increment > > > net->ct.labels_used which means that all conntrack objects get the > > > label area allocated. > > > > > > But thats not what the counter was (originally) meant to convey, it > > > was really 'number of connlabel rules'. > > > > > As soon as act_ct or ovs modules are loaded, then all the namespaces > > > see 'I need conntrack labels', which completely voids all attempts to > > > avoid ct->ext allocation. > > > > OK, so instead a of per-netns sysctl toggle, you propose to use the > > conntrack template to selectively enable this. > > I think for iptables/nftables current approach is fine. > > Otherwise someone has to explain to me what the use case is for > setting connlabels from netlink but no rules in place that make > any decision based on that. Agreed. I don't need this myself. I just found this bugzilla ticket while reviewing recent reports. I think my patch for conntrack command line is fine by now (documentation plus deal with corner case that triggers ENOSPC from update path). So yes, agreed, if anyone has a use case for no rules while having connlabel, they should come here and explain.
