Date: Mon, 9 Jul 2012 12:57:34 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> 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 Message-ID: <20120709085734.GM21957@FreeBSD.org> In-Reply-To: <FFC22579-B8A1-41E9-B955-9E0D22709C19@lists.zabbadoz.net> References: <201207040737.q647br5k096035@svn.freebsd.org> <FFC22579-B8A1-41E9-B955-9E0D22709C19@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120709085734.GM21957>