ipfw named objejcts, table values and syntax change

[Alexander V. Chernikov]

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 at freebsd.org <mailto:melifaro at 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 at freebsd.org <mailto:freebsd-ipfw at freebsd.org> mailing list
>>      http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>>      To unsubscribe, send any mail to
>>      "freebsd-ipfw-unsubscribe at freebsd.org
>>      <mailto:freebsd-ipfw-unsubscribe at freebsd.org>"
>>
>>
>>
>>
>> -- 
>> -----------------------------------------+-------------------------------
>>   Prof. Luigi RIZZO, rizzo at iet.unipi.it <mailto:rizzo at 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)
>> -----------------------------------------+-------------------------------