<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><i>Hi,</i></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><i>You are right, I got your point already,</i></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><i>No need to sync the state table because if the state is not existing in CPU A's context, the traffic still can continue , it will automatically create,</i></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><i><br></i></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><i>But the NAT is different. because when the traffic return back, it has to see the NAT record. if we have NAT record per-CPU, then that means we need to sync the record to all CPU. that will cause more resource, so NAT will be shared by call CPUs, so cannot be "lockless"</i></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 9:48 AM, 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">The code of lockless ipfw2 static rule is there for ages<br>
(sys/net/ipfw) and I currently don't find enough time to make in-base<br>
ipfw2 state table lockless.  But it could be as simple as:<br>
- Make state table per-cpu.<br>
- Make the state table GC callout per-cpu.<br>
- Remove the state table lock.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Nov 19, 2014 at 9:26 AM, bycn82 <<a href="mailto:bycn82@gmail.com">bycn82@gmail.com</a>> wrote:<br>
> why not share more information, for example write a internal document for<br>
> developers like NetBSD in order to help newcomers.<br>
><br>
> <a href="https://www.netbsd.org/docs/internals/en/index.html" target="_blank">https://www.netbsd.org/docs/internals/en/index.html</a><br>
><br>
><br>
> On Tue, Nov 18, 2014 at 6:45 AM, Sepherosa Ziehau <<a href="mailto:sepherosa@gmail.com">sepherosa@gmail.com</a>><br>
> wrote:<br>
>><br>
>> For static rules, ipfw2 in the base is already lockless MPSAFE.  I<br>
>> want to change the states lockless MPSAFE (it was not doable back to<br>
>> the time I made ipfw2 static rules lockless MPSAFE; but now since we<br>
>> dispatch udp outputs to the proper netisr, it is doable).<br>
>><br>
>> On Mon, Nov 17, 2014 at 6:13 PM, Zachary Crownover<br>
>> <<a href="mailto:zachary.crownover@gmail.com">zachary.crownover@gmail.com</a>> wrote:<br>
>> > I would say follow in the steps that were taken for the pf code that was<br>
>> > touched recently for SMP support and prevention of locking for you<br>
>> > application of the same into ipfw.<br>
>> ><br>
>> > On Sun, Nov 16, 2014 at 10:04 PM, bycn82 <<a href="mailto:bycn82@gmail.com">bycn82@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hi ,<br>
>> >> I am re-writing the ipfw for dragonflybsd. and once I cleanup the code,<br>
>> >> I<br>
>> >> will continue port some useful features like NAT and policy routing.(<br>
>> >> NAT<br>
>> >> will be the next one)<br>
>> >><br>
>> >> And here is a simple wiki page for it,<br>
>> >> <a href="http://www.dragonflybsd.org/docs/ipfw2/" target="_blank">http://www.dragonflybsd.org/docs/ipfw2/</a><br>
>> >><br>
>> >> any comment? Sure I need people's help in testing of it. thanks in<br>
>> >> advanced.<br>
>> >><br>
>> >> Regards,<br>
>> >> bycn82<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Sincerely,<br>
>> ><br>
>> > Zachary Crownover<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>