From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 9 21:02:12 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ED71FE1; Thu, 9 Oct 2014 21:02:12 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADA92AAA; Thu, 9 Oct 2014 21:02:11 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=[10.0.0.120]) by mail.ipfw.ru with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XcGr8-00033L-DF; Thu, 09 Oct 2014 20:46:22 +0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: HEADS UP: Merging projects/ipfw to HEAD From: Alexander V. Chernikov In-Reply-To: <542FE9A7.9090208@FreeBSD.org> Date: Fri, 10 Oct 2014 01:02:05 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02957253-78AC-4CDF-AD48-86D219667F02@ipfw.ru> References: <542FE9A7.9090208@FreeBSD.org> To: "Alexander V. Chernikov" X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-current@freebsd.org, freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 21:02:12 -0000 On 04 Oct 2014, at 16:35, Alexander V. Chernikov = wrote: > Hi, >=20 > I'm going to merge projects/ipfw branch to HEAD in the middle of next = week. Merged in r 272840. >=20 > What has changed: >=20 > Main user-visible changes are related to tables: >=20 > * Tables are now identified by names, not numbers. There can be up to = 65k tables with up to 63-byte long names. > * Tables are now set-aware (default off), so you can switch/move them = atomically with rules. > * More functionality is supported (swap, lock, limits, user-level = lookup, batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet = fields at once. > * Ability to add different type of lookup algorithms for particular = table type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array = and flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for = different tablearg users >=20 > Some examples (see ipfw(8) manual page for the description): >=20 > 0:02 [2] zfscurr0# ipfw table fl2 create type = flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib > 0:02 [2] zfscurr0# ipfw table fl2 info > +++ table(fl2), set(0) +++ > kindex: 0, type: flow:src-ip,proto,dst-port > valtype: number, references: 0 > algorithm: flow:hash > items: 0, size: 280 > 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 > 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 > 0:02 [2] zfscurr0# ipfw table fl2 list > +++ table(fl2), set(0) +++ > 2a02:6b8::333,6,443 45000 > 10.0.0.92,6,80 22000 > 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 = flow 'table(fl2)' >=20 > ipfw table mi_test create type cidr algo "cidr:hash masks=3D/30,/64" > ipfw table mi_test add 10.0.0.8/30 > ipfw table mi_test add 2a02:6b8:b010::1/64 25 >=20 > # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 > added: 1.1.1.1/32 1111 > added: 2.2.2.2/32 2222 > # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 > exists: 2.2.2.2/32 2200 > added: 4.4.4.4/32 4444 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error but keeps inserted items > # ipfw table si list > +++ table(si), set(0) +++ > 1.1.1.1/32 1111 > 2.2.2.2/32 2222 > 4.4.4.4/32 4444 > # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 = 5.5.5.5/32 5555 > added(reverted): 3.3.3.3/32 3333 > exists: 4.4.4.4/32 4400 > ignored: 5.5.5.5/32 5555 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error and reverts added records >=20 > Performance changes: > * Main ipfw lock was converted to rmlock > * Rule counters were separated from rule itself and made per-cpu. > * Radix table entries fits into 128 bytes > * struct ip_fw is now more compact so more rules will fit into 64 = bytes > * interface tables uses array of existing ifindexes for faster match >=20 > ABI changes: > All functionality supported by old ipfw(8) remains functional. Old & = new binaries can work together with the following restrictions: > * Tables named other than ^\d+$ are shown as table(65535) in ruleset = in old binaries > * I'm a bit unsure about "lookup src-port|dst-port N" case, something = may be broken here. Anyway, this can be fixed for MFC >=20 > Internal changes:. > Changing table ids to numbers resulted in format modification for most = sockopt codes. > Old sopt format was compact, but very hard to extend (no versioning, = inability to add more opcodes), so > * All relevant opcodes were converted to TLV-based versioned = IP_FW3-based codes. > * The remaining opcodes were also converted to be able to eliminate = all older opcodes at once > * All IP_FW3 handlers uses special API instead of calling sooptcopy* = directly to ease adding another communication methods > * struct ip_fw is now different for kernel and userland > * tablearg value has been changed to 0 to ease future extensions > * table "values" are now indexes in special value array which holds = extended data for given index > * Batched add/delete has been added to tables code > * Most changes has been done to permit batched rule addition. > * interface tracking API has been added (started on demand) to permit = effective interface tables operations > * O(1) skipto cache, currently turned off by default at compile-time = (eats 512K). >=20 > * Several steps has been made towards making libipfw: > * most of new functions were separated into "parse/prepare/show and = actuall-do-stuff" pieces (already merged). > * there are separate functions for parsing text string into "struct = ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). > * Probably some more less significant/forgotten features >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20