<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><i>thanks</i><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 9, 2014 at 4:48 PM, Sepherosa Ziehau <span dir="ltr"><<a href="mailto:sepherosa@gmail.com" target="_blank">sepherosa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You could use tools/tools/netrate/accept_connect/kq_accept_server and<br>
kq_connect_client.  Make sure you have following settings on both end:<br>
net.inet.ip.portrange.last=40000<br>
route change -net YOUR_TEST_SUBNET -msl 10<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Sun, Dec 7, 2014 at 1:06 PM, bycn82 <<a href="mailto:bycn82@gmail.com">bycn82@gmail.com</a>> wrote:<br>
> "lockless state" was there, but any recommendation about the testing in<br>
> order to know the performance different?<br>
><br>
> On Fri, Dec 5, 2014 at 5:25 PM, Sepherosa Ziehau <<a href="mailto:sepherosa@gmail.com">sepherosa@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, Dec 5, 2014 at 3:39 PM, bycn82 <<a href="mailto:bycn82@gmail.com">bycn82@gmail.com</a>> wrote:<br>
>> > It will be good to have a try on this "lock-less NAT" in order to know<br>
>> > the<br>
>> > performance. but IMHO, I think the performance will not be good<br>
>> > especially<br>
>> > when the machines has lots of CPU.<br>
>><br>
>><br>
>> Number of CPUs does not matter that much, since its bwteen at most two<br>
>> CPUs (two netisrs).\<br>
>><br>
>> Best Regards,<br>
>> sephe<br>
>><br>
>><br>
>> ><br>
>> > Anyway , next will be "lockless" for "keep-state". maybe this weekend :)<br>
>> ><br>
>> ><br>
>> > On Fri, Dec 5, 2014 at 3:11 PM, Sepherosa Ziehau <<a href="mailto:sepherosa@gmail.com">sepherosa@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Fri, Dec 5, 2014 at 2:38 AM, Matthew Dillon<br>
>> >> <<a href="mailto:dillon@apollo.backplane.com">dillon@apollo.backplane.com</a>> wrote:<br>
>> >> >     On how to make NAT work, what I did in PF was this:<br>
>> >> ><br>
>> >> >     (a) When the port is not locked to a particular number, I simply<br>
>> >> > iterate<br>
>> >> >         ports until the toepliz hash for the translated address/port<br>
>> >> > pair<br>
>> >> >         winds up on the same cpu as the toeplez hash of the original.<br>
>> >> ><br>
>> >> >         This way both sides of the NAT conversation wind up on the<br>
>> >> > same<br>
>> >> > cpu<br>
>> >> >         and no locking is required.<br>
>> >> ><br>
>> >> >     (b) If the translated port is locked (which is a feature that PF<br>
>> >> > has,<br>
>> >> >         for example), it may not be possible to match up the toeplez<br>
>> >> > hash.<br>
>> >> ><br>
>> >> >         In this situation the state goes into a global table with a<br>
>> >> > global<br>
>> >> >         lock, and the state is individually locked by the filter.<br>
>> >> ><br>
>> >><br>
>> >> In addition to what Matt has mentioned, I think lockless NAT could be<br>
>> >> implemented in the following way:<br>
>> >><br>
>> >> - On output path install state for the current netisr.  And rehash the<br>
>> >> packet then send to the target netisr, and install 'sibling state' in<br>
>> >> the target netisr; do the real output there.<br>
>> >> - Same applies to the input path; but do the protocol input in the<br>
>> >> target netisr.<br>
>> >><br>
>> >> However, the result may not be better than or as good as<br>
>> >> per-cpu+global lock Matt implemented for the PF, since my way requires<br>
>> >> additional dispatch.<br>
>> >><br>
>> >> Best Regards,<br>
>> >> sephe<br>
>> >><br>
>> >> --<br>
>> >> Tomorrow Will Never Die<br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Tomorrow Will Never Die<br>
><br>
><br>
<br>
<br>
<br>
--<br>
Tomorrow Will Never Die<br>
</div></div></blockquote></div><br></div>