From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 4 09:45:26 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19E92FC0; Mon, 4 Aug 2014 09:45:26 +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 865CC2F38; Mon, 4 Aug 2014 09:45:25 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XEAsQ-000COY-5a; Mon, 04 Aug 2014 09:32:06 +0400 Message-ID: <53DF55FA.8010303@FreeBSD.org> Date: Mon, 04 Aug 2014 13:44:26 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: ipfw named objejcts, table values and syntax change References: <53DC01DE.3000000@FreeBSD.org> <53DCA25C.1000108@FreeBSD.org> In-Reply-To: <53DCA25C.1000108@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw , "freebsd-net@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 09:45:26 -0000 On 02.08.2014 12:33, Alexander V. Chernikov wrote: > On 02.08.2014 10:33, Luigi Rizzo wrote: >> >> >> On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov >> > wrote: >> >> Hello all. >> >> I'm currently working on to enhance ipfw in some areas. >> The most notable (and user-visible) change is named table support. >> The other one is support for different lookup algorithms for different >> key types. >> >> For example, new ipfw permits writing this: >> >> ipfw table tb1 create type cidr >> ipfw add allow ip from table(tl1) to any >> ipfw add allow ip from any lookup dst-ip tb1 >> >> ipfw table if1 create type iface >> ipfw add skipto tablearg ip from any to any via table(if1) >> >> or even this: >> ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port >> ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444 >> ipfw add allow ip from any to any flow table(fl1) >> >> all these changes fully preserve backward compatibility. >> (actually tables needs now to be created before use and their type needs >> to match with opcode used, but new ipfw(8) performs auto-creation >> for cidr tables). >> >> There is another thing I'm going to change and I'm not sure I can keep >> the same compatibility level. >> >> Table values, from one point of view, can be classified to the following >> types: >> >> - skipto argument >> - fwd argument (*) >> - link to another object (nat, pipe, queue) >> - plain u32 (not bound to any object) >> (divert/tee,netgraph,tag/utag,limit) >> >> There are the following reasons why I think it is necessary to implement >> explicit table values typing (like tables): >> - Implementing fwd tablearg for IPv6 hosts requires indirection table >> - Converting nat/pipe instance ids to names renders values unusable >> - retiring old hack with storing saved pointer of found object/rule >> inside rule w/o proper locking >> - making faster skipto >> >> >> ​​i don't buy the idea that you need typed arguments >> for all the cases above. Maybe the case that >> may make sense is the fwd argument (and in the future >> something else). >> We already discussed, i think, the fact that now it >> is legal to have references to non existing things >> (skipto, pipes etc.) implemented as u32. >> Removing that would break configurations. > It depends on actual implementation. This can be preserved by > auto-creating necessary objects in kernel and/or in userspace, so > we can (and should) avoid breaking in this particular way. Can you please explain your vision on values another time? As far as I understand, you're not against it in general, but the details matter: * IP address can be one of the types (it won't break much, and we can simply skip that one for MFC) * what about typing for nat/pipes ? we're not going to convert their ids to names? (or maybe you can suggest other non-disruptive way?) * everything else is type "u32" >> Efficiency is not affected, even for skipto, > It depends on workload. While binary search is fast in terms of cpu, it > is may be not so fast in terms of memory (since each of the rule is > allocated by separate malloc() (and that is another thing which is worth > discussing)). > >> and while i agree that unprotected writes to the pointers >> in rules should not happen, these pointers are changed >> infrequently so a global read-mostly lock should be >> sufficient to protect all changes to the rules. >> >> cheers >> luigi >> >> >> So, as the result, table will have lookup key type (already done), >> value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some >> additional restrictions (like inability to add non-existing nat instance >> id). >> >> This change will break (at least) scenarios where people are >> using one table for both nat/pipe instances (and keep nat ids in sync >> with pipe ones). For example: >> >> ipfw table 1 add 10.0.10.0/24 110 >> ipfw table 1 add 10.0.20.0/24 120 >> >> ipfw add 100 nat tablearg from table(1) to any via vlanX in >> .. >> ipfw add 500 pipe tablearg from table(1) to any via ix0 out >> >> It looks like it is not so easy to bind values for given table to >> different objects (or different tasks) (and lack of compatibility kills >> hope for MFC). >> >> Ideas? >> >> >> >> >> >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to >> "freebsd-ipfw-unsubscribe@freebsd.org >> " >> >> >> >> >> -- >> -----------------------------------------+------------------------------- >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . >> Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2211611 . via >> Diotisalvi 2 >> Mobile +39-338-6809875 . 56122 >> PISA (Italy) >> -----------------------------------------+-------------------------------