Date: Mon, 04 Aug 2014 13:44:26 +0400 From: "Alexander V. Chernikov" <melifaro@FreeBSD.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: freebsd-ipfw <freebsd-ipfw@freebsd.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: ipfw named objejcts, table values and syntax change Message-ID: <53DF55FA.8010303@FreeBSD.org> In-Reply-To: <53DCA25C.1000108@FreeBSD.org> References: <53DC01DE.3000000@FreeBSD.org> <CA%2BhQ2%2BgNjA0rucTYAaPYQKtEMt9GZLC6RCi%2BOgPVRpuDC5Ei7Q@mail.gmail.com> <53DCA25C.1000108@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>> <melifaro@freebsd.org <mailto:melifaro@freebsd.org>> 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 <http://10.0.10.0/24>; 110
>> ipfw table 1 add 10.0.20.0/24 <http://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 <mailto: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
>> <mailto:freebsd-ipfw-unsubscribe@freebsd.org>"
>>
>>
>>
>>
>> --
>> -----------------------------------------+-------------------------------
>> Prof. Luigi RIZZO, rizzo@iet.unipi.it <mailto:rizzo@iet.unipi.it> .
>> Dip. di Ing. dell'Informazione
>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
>> TEL +39-050-2211611 <tel:%2B39-050-2211611> . via
>> Diotisalvi 2
>> Mobile +39-338-6809875 <tel:%2B39-338-6809875> . 56122
>> PISA (Italy)
>> -----------------------------------------+-------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53DF55FA.8010303>