On Tue, 15 Dec 2015, Mike Belopuhov wrote: > > Yet another possibility is to drop 'once' rules as too complex to > > implement for multiprocessor but I have no idea if this is viable. > > It is. And I have said that before with an authority of the implementor > of "once" rules: since we don't have any userland applications that > would use this yet, we can ditch them for now and possibly devise a > better approach later. > Don't make your lives harder than they have to be!
I tend to agree! And I can't see a way to reimplement it for a multithreaded pf without introducing downsides. Quoting pf.conf(5) "once - Creates a one shot rule that will remove itself from an active ruleset after the first match." A 'first' match presupposes a total ordering. This comes for free when pf is single-threaded but concurrent rule matching must take the trouble to re-impose it somewhere. (I assume that pf aims to do concurrent matching of packets against the ruleset.) One approach serialises the candidacy of 'once' rules during rule matching. This ensures an unambiguous first match but costs pf a latent glass jaw. In the worst case, a 'once' rule heads the ruleset and matches any packet. Its candidacy therefore covers the entire rule-matching process and so fully serialises it. The other approach serialises the packets matched by 'once' rules, after rule processing is done. This doesn't create a glass jaw but does permit the 'once' rule to match more than once. To my taste neither alternative is especially palatable. That said, a 'quick' 'once' rule has no candidacy window so it can be serialised by atomically testing/setting a flag when evaluating it. This also both avoids the glass jaw and provides at most one first match. (Note that this issue of determining the first match is independent of whether a 'once' rule, having matched, is purged.) On Wed, 16 Dec 2015, Mike Belopuhov wrote: > It just occurred to me that another possibility would be a match-only > rule that matches one but doesn't involve any purging machinery. That is an interesting idea. Like a 'quick' rule, a match rule has no candidacy window. However a 'once' match rule can no longer influence pass/block state --- I can't see how it is usefull? best, Richard.
