[restored Cc list]
On Thu, Mar 10, 2022 at 01:23:03PM +0100, Florian Westphal wrote:
> Phil Sutter <phil@xxxxxx> wrote:
> > On Thu, Mar 10, 2022 at 01:11:55PM +0100, Florian Westphal wrote:
> > > Phil Sutter <phil@xxxxxx> wrote:
> > > > When dumping a large ruleset, common protocol matches such as for TCP
> > > > port number significantly slow down rule printing due to repeated calls
> > > > for getprotobynumber(). The latter does not involve any caching, so
> > > > /etc/protocols is consulted over and over again.
> > >
> > > > As a simple countermeasure, make functions converting between proto
> > > > number and name prefer the built-in list of "well-known" protocols. This
> > > > is not a perfect solution, repeated rules for protocol names libxtables
> > > > does not cache (e.g. igmp or dccp) will still be slow. Implementing
> > > > getprotoent() result caching could solve this.
> > >
> > > Hmm, I think we could just extend xtables_chain_protos[].
> >
> > Statically, i.e. add more entries based on "usual" /etc/protocols
> > contents or dynamically from getprotoent() results?
>
> I meant statically, I don't see why you'd need to do that for igmp or
> dccp (or any other well-known protocol for that matter).
I hesitated because we take users' ability to override the definitions.
Yet giving it another thought, you're right:
When translating name to number, it is very unlikely users would reuse
a common name ('tcp' for instance) for another protocol value. They'll
probably just add new ones.
In reverse direction, it is inconvenient at most: People may prefer
'ipv6-icmp' over 'icmpv6', but whatever name libxtables has stored will
at least parse OK later.
Thanks, Phil
