Date: Fri, 22 Jun 2012 13:56:02 +0000 (UTC) From: Gleb Smirnoff <glebius@FreeBSD.org> To: src-committers@freebsd.org, svn-src-projects@freebsd.org Subject: svn commit: r237442 - projects/pf/head/sys/contrib/pf/net Message-ID: <201206221356.q5MDu27L081764@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: glebius Date: Fri Jun 22 13:56:01 2012 New Revision: 237442 URL: http://svn.freebsd.org/changeset/base/237442 Log: Spelling. Modified: projects/pf/head/sys/contrib/pf/net/pf_lb.c Modified: projects/pf/head/sys/contrib/pf/net/pf_lb.c ============================================================================== --- projects/pf/head/sys/contrib/pf/net/pf_lb.c Fri Jun 22 12:15:38 2012 (r237441) +++ projects/pf/head/sys/contrib/pf/net/pf_lb.c Fri Jun 22 13:56:01 2012 (r237442) @@ -471,7 +471,7 @@ pf_map_addr(sa_family_t af, struct pf_ru * forwarding thread needs to modify rule. * * This is done w/o locking, because performance is assumed - * more importand than round-robin precision. + * more important than round-robin precision. * * In the simpliest case we just update the "rpool->cur" * pointer. However, if pool contains tables or dynamic @@ -481,7 +481,7 @@ pf_map_addr(sa_family_t af, struct pf_ru * * Things get worse, if table contains not hosts, but * prefixes. In this case counter also stores machine state, - * and for IPv6 address, counter can be updated atomically. + * and for IPv6 address, counter can't be updated atomically. * Probably, using round-robin on a table containing IPv6 * prefixes (or even IPv4) would cause a panic. */
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206221356.q5MDu27L081764>