<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><i>"lockless state" was there, but any recommendation about the testing in order to know the performance different?</i></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 5, 2014 at 5:25 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"><span class="">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 the<br>
> performance. but IMHO, I think the performance will not be good especially<br>
> when the machines has lots of CPU.<br>
<br>
<br>
</span>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>
<div class="HOEnZb"><div class="h5"><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 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>
</div></div></blockquote></div><br></div>