ipfw2 for dragonflybsd

[bycn82]

*thanks*

On Tue, Dec 9, 2014 at 4:48 PM, Sepherosa Ziehau <sepherosa at gmail.com>
wrote:

> You could use tools/tools/netrate/accept_connect/kq_accept_server and
> kq_connect_client.  Make sure you have following settings on both end:
> net.inet.ip.portrange.last=40000
> route change -net YOUR_TEST_SUBNET -msl 10
>
>
>
> On Sun, Dec 7, 2014 at 1:06 PM, bycn82 <bycn82 at gmail.com> wrote:
> > "lockless state" was there, but any recommendation about the testing in
> > order to know the performance different?
> >
> > On Fri, Dec 5, 2014 at 5:25 PM, Sepherosa Ziehau <sepherosa at gmail.com>
> > wrote:
> >>
> >> On Fri, Dec 5, 2014 at 3:39 PM, bycn82 <bycn82 at gmail.com> wrote:
> >> > It will be good to have a try on this "lock-less NAT" in order to know
> >> > the
> >> > performance. but IMHO, I think the performance will not be good
> >> > especially
> >> > when the machines has lots of CPU.
> >>
> >>
> >> Number of CPUs does not matter that much, since its bwteen at most two
> >> CPUs (two netisrs).\
> >>
> >> Best Regards,
> >> sephe
> >>
> >>
> >> >
> >> > Anyway , next will be "lockless" for "keep-state". maybe this weekend
> :)
> >> >
> >> >
> >> > On Fri, Dec 5, 2014 at 3:11 PM, Sepherosa Ziehau <sepherosa at gmail.com
> >
> >> > wrote:
> >> >>
> >> >> On Fri, Dec 5, 2014 at 2:38 AM, Matthew Dillon
> >> >> <dillon at apollo.backplane.com> wrote:
> >> >> >     On how to make NAT work, what I did in PF was this:
> >> >> >
> >> >> >     (a) When the port is not locked to a particular number, I
> simply
> >> >> > iterate
> >> >> >         ports until the toepliz hash for the translated
> address/port
> >> >> > pair
> >> >> >         winds up on the same cpu as the toeplez hash of the
> original.
> >> >> >
> >> >> >         This way both sides of the NAT conversation wind up on the
> >> >> > same
> >> >> > cpu
> >> >> >         and no locking is required.
> >> >> >
> >> >> >     (b) If the translated port is locked (which is a feature that
> PF
> >> >> > has,
> >> >> >         for example), it may not be possible to match up the
> toeplez
> >> >> > hash.
> >> >> >
> >> >> >         In this situation the state goes into a global table with a
> >> >> > global
> >> >> >         lock, and the state is individually locked by the filter.
> >> >> >
> >> >>
> >> >> In addition to what Matt has mentioned, I think lockless NAT could be
> >> >> implemented in the following way:
> >> >>
> >> >> - On output path install state for the current netisr.  And rehash
> the
> >> >> packet then send to the target netisr, and install 'sibling state' in
> >> >> the target netisr; do the real output there.
> >> >> - Same applies to the input path; but do the protocol input in the
> >> >> target netisr.
> >> >>
> >> >> However, the result may not be better than or as good as
> >> >> per-cpu+global lock Matt implemented for the PF, since my way
> requires
> >> >> additional dispatch.
> >> >>
> >> >> Best Regards,
> >> >> sephe
> >> >>
> >> >> --
> >> >> Tomorrow Will Never Die
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Tomorrow Will Never Die
> >
> >
>
>
>
> --
> Tomorrow Will Never Die
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20141209/95040e76/attachment-0003.htm>