Re: nftables code size (was: Re: [PATCH nf-next 0/2] ebtables: add support for ICMP and IGMP type/code matching)

[Pablo Neira Ayuso]

On Wed, Apr 11, 2018 at 06:40:34AM +0200, Matthias Schiffer wrote:
> On 03/04/2018 12:16 PM, Matthias Schiffer wrote:
> > I noticed that more than 25% of binary size of libnftnl are made up of
> > snprintf functions. Having these in a library with the goal to abstract the
> > netlink interface of nftables seems questionable to me, but I have no idea
> > if it would be viable to move these functions to nft or to a separate 
> > library.
> 
> As an experiment, I created a reduced version of libnftnl by ripping out
> all import/export functions and related code like buffer handling. This
> reduced the size of libnftnl.so from 155KB to 110KB (on x86-64, -Os,
> stripped, uncompressed), a reduction of roughly 30%.
> 
> I would like to look into splitting libnftnl into two parts, which could be
> called libnftnl-core and libnftnl, to make nftables more suited for tiny
> embedded systems. All basic functions that do not deal with textual
> representations of rules (i.e. the reduced libnftnl I built) would be moved
> into libnftnl-core.
> 
> Does this sound like a good idea, and would such a drastic change be
> acceptable for upstream inclusion, given the current libnftnl API can be
> preserved?

Could you wrap the import/export code around the --with-json-parsing?
I mean, turn this into --with-json or such, so you can just compile
out that code, which is what is giving you the savings in terms of
size, right?

I'm trying to keep it simple here :-)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: nftables code size (was: Re: [PATCH nf-next 0/2] ebtables: add support for ICMP and IGMP type/code matching)

[Florian Westphal]

Matthias Schiffer  wrote:
> As an experiment, I created a reduced version of libnftnl by ripping out
> all import/export functions and related code like buffer handling. This
> reduced the size of libnftnl.so from 155KB to 110KB (on x86-64, -Os,
> stripped, uncompressed), a reduction of roughly 30%.

[..]

> Does this sound like a good idea, and would such a drastic change be
> acceptable for upstream inclusion, given the current libnftnl API can be
> preserved?

Seems like a good idea to split this up.

I think as first step you could even send a patch that
just excludes all unneeded snprintf etc. code from the build.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

nftables code size (was: Re: [PATCH nf-next 0/2] ebtables: add support for ICMP and IGMP type/code matching)

[Matthias Schiffer]

On 03/04/2018 12:16 PM, Matthias Schiffer wrote:
> I noticed that more than 25% of binary size of libnftnl are made up of
> snprintf functions. Having these in a library with the goal to abstract the
> netlink interface of nftables seems questionable to me, but I have no idea
> if it would be viable to move these functions to nft or to a separate library.

As an experiment, I created a reduced version of libnftnl by ripping out
all import/export functions and related code like buffer handling. This
reduced the size of libnftnl.so from 155KB to 110KB (on x86-64, -Os,
stripped, uncompressed), a reduction of roughly 30%.

I would like to look into splitting libnftnl into two parts, which could be
called libnftnl-core and libnftnl, to make nftables more suited for tiny
embedded systems. All basic functions that do not deal with textual
representations of rules (i.e. the reduced libnftnl I built) would be moved
into libnftnl-core.

Does this sound like a good idea, and would such a drastic change be
acceptable for upstream inclusion, given the current libnftnl API can be
preserved?

Kind regards,
Matthias



signature.asc
Description: OpenPGP digital signature