On 19. September 2014 08:51:48 MESZ, Arturo Borrero Gonzalez <arturo.borrero.glez@xxxxxxxxx> wrote: >On 18 September 2014 20:34, Patrick McHardy <kaber@xxxxxxxxx> wrote: >> On 18. September 2014 20:18:18 MESZ, Arturo Borrero Gonzalez ><arturo.borrero.glez@xxxxxxxxx> wrote: >>>The sets mechanism options was not being stored anywhere. >>> >>>We want to know in which cases the user explicitly set the mechanism >>>options. In that case, we also want to dump back the info. >>> >> >> I don't think this is needed. Basically we always want to dump >options for non-constant sets, since they couldn't have been chosen >automatically, and don't need to dump them for constant sets, since >they can always be determined automatically based on the contents. >> > >Could you please elaborate? > >If the set is non-constant, currently the options are by default >NFT_SET_POL_PERFORMANCE and size 0. >Do you want these options to be printed to the end user even when the >user did not originally use the 'policy xx' and 'size xx' statements? >Or in the other hand, to never print the options even when the user >gave an explicit config? No. When we have literal/constant sets we can automatically determine the options, and we don't need to return them from the kernel. We could, but its useless. For named sets any options that are not the default must have been specified by the user. So we must always dump them unless they are the default. >In the case of constant sets, what If I want to test the performance >of different policies? I need to know which policy is applied to a >given set, (in order to change it). Well, the mechanism is supposed to pick the best implementation. For testing, you can unload modules, the kernel won't autoload if at least one set implementation is available. -- 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
