Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Sep 2012 11:08:06 +0400
From:      Gleb Smirnoff <glebius@FreeBSD.org>
To:        Ermal Lu?i <eri@FreeBSD.org>
Cc:        pf@FreeBSD.org, net@FreeBSD.org
Subject:   Re: [HEADS UP] merging projects/pf into head
Message-ID:  <20120906070806.GM15915@glebius.int.ru>
In-Reply-To: <CAPBZQG0KHs_ckvn0TPr38Z_vPokziZH=1xx1NG53Ld8rkV_JJg@mail.gmail.com>
References:  <20120905115140.GF15915@FreeBSD.org> <CAPBZQG0KHs_ckvn0TPr38Z_vPokziZH=1xx1NG53Ld8rkV_JJg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
  Ermal,

On Wed, Sep 05, 2012 at 10:09:23PM +0200, Ermal Lu?i wrote:
E> Its good to see results on your work and is good moving forward.
E> Claiming better behavior, under DoS or other comparison without showing any data
E> or technical reason is a bit over this RFC.

Benchmark by authors are always biased, thus I didn't boast about results.
Much better if benchmarking is performed by someone else. If you insist
here is some data:

1) Casting UDP flood of 400k states in this simple setup:

	[box A] -> [pf] -> [blackhole]

   On my particular box, head pf can forward 520 kpps and anything above is
lost. SMP-pf can do 980 kpps. If we increase number of states, results would
be more dramatic. If we make load bidirectional (which is the case in 99%)
results would be more dramatic. Increasing number of rx/tx threads (more NICs,
or more smart NICs) as well as increasing number of CPUs would make results
even more dramatic.

2) DoSes

Results are just empirical. At my job, when running old pf and encountering
DoS attack, we usually notice that by bad web sites responsibility, customers
complaining, etc. The box under attack is very unresponsive via ssh. With new
SMP-pf a DoS may come in and if it doesn't consume entire bandwidth it can be
noticed only post-factum when looking at monitoring plots.

I'd appreciate if you perform benchmarking and testing. As said above,
results from author are usually biased, but results from opponents more
interesting.

E> >   1) Move pf out of contrib.
E> I do not see a reason behind this, any particular reason?

It is no longer contributed source, but source developed by the FreeBSD project.

E> >   2) Refactor the pfvar.h into pf.h and pf_var.h. Provide stable
E> >      kernel<->pfctl ABI. And probably other clean up tasks.
E> Just this reason is a bit contradictory with 1) above!
E> Let alone what does this mean to the user?! Nothing?
E> They are after syntax stability, not breaking their machines on
E> upgrade, ABI is nothing to them.

Do you understand that "absense of stable ABI" == "breaking machines
after upgrade"?

Right now, the structures supplied via ioctl() include many fields
that aren't related to API, but are internal kernel. Any internal
kernel change breaks ABI. If new API structures are introduced, then
we can do a lot of hacking on pf in 11.0-CURRENT with ability to
safely merge changes to 10.0-STABLE.


-- 
Totus tuus, Glebius.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120906070806.GM15915>