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 <byc...@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 <sepher...@gmail.com> > wrote: >> >> On Fri, Dec 5, 2014 at 3:39 PM, bycn82 <byc...@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 <sepher...@gmail.com> >> > wrote: >> >> >> >> On Fri, Dec 5, 2014 at 2:38 AM, Matthew Dillon >> >> <dil...@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