On 2018-02-20 17:54, Pablo Neira Ayuso wrote: > On Tue, Feb 20, 2018 at 04:44:48PM +0100, Felix Fietkau wrote: >> On 2018-02-20 16:35, Pablo Neira Ayuso wrote: >> > On Tue, Feb 20, 2018 at 04:06:11PM +0100, Felix Fietkau wrote: >> >> On 2018-02-20 16:01, Pablo Neira Ayuso wrote: > [...] >> > I guess this is related to net/netfilter/xt_FLOWOFFLOAD.c. >> > >> > You probably could add net/ipv4/netfilter/ipt_FLOWOFFLOAD.c and >> > net/ipv6/netfilter/ip6t_FLOWOFFLOAD.c, so we can skip placing ipv4 and >> > ipv6 code in the same file. >> >> That's exactly what I wanted to avoid. > > I would like to avoid the opposite, if possible. > >> Since nf_flow_table_ipv6 depends on nftables, I'd have to make two >> extra modules, one for the ipv4 hook, one for the ipv6 hook. > > What is the current dependency between nf_flow_table_ipv6 and > nftables? I tried to reduce dependencies as much as possible. nft_register_flowtable_type nft_unregister_flowtable_type Resolving those dependencies through other ways than splitting up the code would get awkward and convoluted, since the flowtable type is what nftables needs to be able to call into the flow offload code without depending on it. >> So we'd have: >> ipt_FLOWOFFLOAD.ko, >> ip6t_FLOWOFFLOAD.ko >> nf_flow_table_ipv4.ko (without nft bits) >> nf_flow_table_ipv6.ko (without nft bits) >> nft_flow_table_ipv4.ko (with just nft bits) >> nft_flow_table_ipv6.ko (with just nft bits) >> >> I'd say the overhead of having all those modules split up is not that >> much smaller than the overhead of including ipv6 code in the core module >> even when it may not be needed. > > I see. > > When we do this, ie. place IPv4 and IPv6 code in the same file, we end > up needing #ifdefs, I have bad experience with this. > > What is CONFIG_IPV6 is disabled? Dealing with that would only need one single #ifdef (if it needs one at all), so it's very simple. >> By the way, .text size of nf_flow_table_hw.o with IPv4 + IPv6 combined >> is less than 3.5 KiB (when compiled for ARM). > > But people can also compile this modules built-in if they want to > shrink image size, right?The main reason why I have an issue with this approach is the fact that we have to provide reasonably sized precompiled distribution as well, but for embedded devices. Splitting things up unnecessarily causes bloat for common configurations that almost everybody uses. - Felix -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
