*thanks* On Tue, Dec 9, 2014 at 4:48 PM, Sepherosa Ziehau <[email protected]> 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 <[email protected]> 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 <[email protected]> > > wrote: > >> > >> On Fri, Dec 5, 2014 at 3:39 PM, bycn82 <[email protected]> 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 <[email protected] > > > >> > wrote: > >> >> > >> >> On Fri, Dec 5, 2014 at 2:38 AM, Matthew Dillon > >> >> <[email protected]> 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 >
