From owner-svn-src-all@freebsd.org  Sun Mar 10 00:56:40 2019
Return-Path: <owner-svn-src-all@freebsd.org>
Delivered-To: svn-src-all@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41C6C153E97D;
 Sun, 10 Mar 2019 00:56:40 +0000 (UTC) (envelope-from kp@FreeBSD.org)
Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org
 [IPv6:2610:1c1:1:606c::19:3])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 server-signature RSA-PSS (4096 bits)
 client-signature RSA-PSS (4096 bits) client-digest SHA256)
 (Client CN "mxrelay.nyi.freebsd.org",
 Issuer "Let's Encrypt Authority X3" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id D945C83451;
 Sun, 10 Mar 2019 00:56:39 +0000 (UTC) (envelope-from kp@FreeBSD.org)
Received: from repo.freebsd.org (repo.freebsd.org
 [IPv6:2610:1c1:1:6068::e6a:0])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CEB651B469;
 Sun, 10 Mar 2019 00:56:39 +0000 (UTC) (envelope-from kp@FreeBSD.org)
Received: from repo.freebsd.org ([127.0.1.37])
 by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x2A0udmO013437;
 Sun, 10 Mar 2019 00:56:39 GMT (envelope-from kp@FreeBSD.org)
Received: (from kp@localhost)
 by repo.freebsd.org (8.15.2/8.15.2/Submit) id x2A0ud2j013436;
 Sun, 10 Mar 2019 00:56:39 GMT (envelope-from kp@FreeBSD.org)
Message-Id: <201903100056.x2A0ud2j013436@repo.freebsd.org>
X-Authentication-Warning: repo.freebsd.org: kp set sender to kp@FreeBSD.org
 using -f
From: Kristof Provost <kp@FreeBSD.org>
Date: Sun, 10 Mar 2019 00:56:39 +0000 (UTC)
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
X-SVN-Group: stable-11
X-SVN-Commit-Author: kp
X-SVN-Commit-Paths: stable/11/sys/netpfil/pf
X-SVN-Commit-Revision: 344975
X-SVN-Commit-Repository: base
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: D945C83451
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org
X-Spamd-Result: default: False [-2.96 / 15.00];
 local_wl_from(0.00)[FreeBSD.org];
 NEURAL_HAM_MEDIUM(-1.00)[-1.000,0];
 NEURAL_HAM_LONG(-1.00)[-1.000,0];
 NEURAL_HAM_SHORT(-0.96)[-0.957,0];
 ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]
X-BeenThere: svn-src-all@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "SVN commit messages for the entire src tree \(except for &quot;
 user&quot; and &quot; projects&quot; \)" <svn-src-all.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-all>,
 <mailto:svn-src-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all/>
List-Post: <mailto:svn-src-all@freebsd.org>
List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-all>,
 <mailto:svn-src-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Mar 2019 00:56:40 -0000

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 {