From owner-svn-src-all@FreeBSD.ORG Mon Jul 9 08:57:36 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0546D106566C; Mon, 9 Jul 2012 08:57:36 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0868FC08; Mon, 9 Jul 2012 08:57:35 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q698vYMh085328; Mon, 9 Jul 2012 12:57:34 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q698vYgO085327; Mon, 9 Jul 2012 12:57:34 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 9 Jul 2012 12:57:34 +0400 From: Gleb Smirnoff To: "Bjoern A. Zeeb" Message-ID: <20120709085734.GM21957@FreeBSD.org> References: <201207040737.q647br5k096035@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r238092 - in head/sys: net netinet netinet6 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 08:57:36 -0000 On Sat, Jul 07, 2012 at 09:36:11PM +0000, Bjoern A. Zeeb wrote: B> > Author: glebius B> > Date: Wed Jul 4 07:37:53 2012 B> > New Revision: 238092 B> > URL: http://svn.freebsd.org/changeset/base/238092 B> > B> > Log: B> > When ip_output()/ip6_output() is supplied a struct route *ro argument, B> > it skips FLOWTABLE lookup. However, the non-NULL ro has dual meaning B> > here: it may be supplied to provide route, and it may be supplied to B> > store and return to caller the route that ip_output()/ip6_output() B> > finds. In the latter case skipping FLOWTABLE lookup is pessimisation. B> > B> > The difference between struct route filled by FLOWTABLE and filled B> > by rtalloc() family is that the former doesn't hold a reference on B> > its rtentry. Reference is hold by flow entry, and it is about to B> > be released in future. Thus, route filled by FLOWTABLE shouldn't B> > be passed to RTFREE() macro. B> > B> > - Introduce new flag for struct route/route_in6, that marks route B> > not holding a reference on rtentry. B> > - Introduce new macro RO_RTFREE() that cleans up a struct route B> > depending on its kind. B> > - All callers to ip_output()/ip6_output() that do supply non-NULL B> > but empty route should use RO_RTFREE() to free results of B> > lookup. B> > - ip_output()/ip6_output() now do FLOWTABLE lookup always when B> > ro->ro_rt == NULL. B> B> B> Just read the description but you realize that the proper fix is to B> make flowtable code a bit slower and do proper reference counting? B> B> Currently a cache flowtable entry might still be releases while a packet B> in being processed using it, right? I think we should connect Kip to the discussion. Flowtable is designed to be fast and lockless, and not refcounting rtentries per packet. Yes, it is theoretically racy. But my patch didn't bring in anything new to this pecularity of flowtable. -- Totus tuus, Glebius.