Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Mar 2019 00:56:39 +0000 (UTC)
From:      Kristof Provost <kp@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org
Subject:   svn commit: r344975 - stable/11/sys/netpfil/pf
Message-ID:  <201903100056.x2A0ud2j013436@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: kp
Date: Sun Mar 10 00:56:39 2019
New Revision: 344975
URL: https://svnweb.freebsd.org/changeset/base/344975

Log:
  pf: Small performance tweak
  
  Because fetching a counter is a rather expansive function we should use
  counter_u64_fetch() in pf_state_expires() only when necessary. A "rdr
  pass" rule should not cause more effort than separate "rdr" and "pass"
  rules. For rules with adaptive timeout values the call of
  counter_u64_fetch() should be accepted, but otherwise not.
  
  From the man page:
      The adaptive timeout values can be defined both globally and for
      each rule.  When used on a per-rule basis, the values relate to the
      number of states created by the rule, otherwise to the total number
      of states.
  
  This handling of adaptive timeouts is done in pf_state_expires().  The
  calculation needs three values: start, end and states.
  
  1. Normal rules "pass .." without adaptive setting meaning "start = 0"
     runs in the else-section and therefore takes "start" and "end" from
     the global default settings and sets "states" to pf_status.states
     (= total number of states).
  
  2. Special rules like
     "pass .. keep state (adaptive.start 500 adaptive.end 1000)"
     have start != 0, run in the if-section and take "start" and "end"
     from the rule and set "states" to the number of states created by
     their rule using counter_u64_fetch().
  
  Thats all ok, but there is a third case without special handling in the
  above code snippet:
  
  3. All "rdr/nat pass .." statements use together the pf_default_rule.
     Therefore we have "start != 0" in this case and we run the
     if-section but we better should run the else-section in this case and
     do not fetch the counter of the pf_default_rule but take the total
     number of states.
  
  Submitted by:	Andreas Longwitz <longwitz@incore.de>

Modified:
  stable/11/sys/netpfil/pf/pf.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/netpfil/pf/pf.c
==============================================================================
--- stable/11/sys/netpfil/pf/pf.c	Sun Mar 10 00:56:38 2019	(r344974)
+++ stable/11/sys/netpfil/pf/pf.c	Sun Mar 10 00:56:39 2019	(r344975)
@@ -1548,7 +1548,7 @@ pf_state_expires(const struct pf_state *state)
 	if (!timeout)
 		timeout = V_pf_default_rule.timeout[state->timeout];
 	start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START];
-	if (start) {
+	if (start && state->rule.ptr != &V_pf_default_rule) {
 		end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END];
 		states = counter_u64_fetch(state->rule.ptr->states_cur);
 	} else {



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201903100056.x2A0ud2j013436>