<div dir="ltr">Thanks much Bodireddy again! comment inline.<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 3, 2017 at 5:00 PM, Bodireddy, Bhanuprakash <span dir="ltr">&lt;<a href="mailto:bhanuprakash.bodireddy@intel.com" target="_blank">bhanuprakash.bodireddy@intel.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It’s a long weekend in US and will try answering some of your questions in Darrell&#39;s absence.<br>
<span class=""><br>
&gt;Why do think having more than 64k per PMD would be optimal ?<br>
&gt;I originally thought that the bottleneck in classifier because it is saturated full<br>
&gt;so that look up has to be going to flow table, so I think why not just increase<br>
&gt;the dpcls flows per PMD, but seems I am wrong based on your explanation.<br>
<br>
</span>For few use cases much of the bottleneck moves to Classifier when EMC is saturated. You may have<br>
to add more  PMD threads (again this depends on the availability of cores in your case.)<br>
As your initial investigation proved classifier is bottleneck, just curious about few things.<br>
     -  In the &#39;dpif-netdev/pmd-stats-show&#39; output, what does the &#39; avg. subtable lookups per hit:&#39;  looks like?<br>
     -  In steady state do &#39;dpcls_lookup()&#39; top the list of functions with &#39;perf top&#39;.<br>
<span class=""><br></span></blockquote><div>Those are great advices, I&#39;ll check more. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt;What is your use case(s) ?<br>
&gt;My usecase might be setup a VBRAS VNF with OVS-DPDK as an NFV normal<br>
&gt;case, and it requires a good performance, however, OVS-DPDK seems still not<br>
&gt;reach its needs compared with  hardware offloading, we are evaluating VPP as<br>
&gt;well,<br>
</span>As you mentioned VPP here, It&#39;s worth looking at the benchmarks that were carried comparing<br>
OvS and VPP for L3-VPN use case by Intel, Ericsson and was presented in OvS Fall conference.<br>
The slides can be found @ <a href="http://openvswitch.org/support/ovscon2016/8/1400-gray.pdf" rel="noreferrer" target="_blank">http://openvswitch.org/<wbr>support/ovscon2016/8/1400-<wbr>gray.pdf</a>.<br></blockquote><div>In above pdf page 12, why does classifier showed a constant throughput with increasing concurrent L4 flows? shouldn&#39;t the performance get degradation with more subtable look up as you mentioned.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
basically I am looking to find out what&#39;s the bottleneck so far in OVS-<br>
&gt;DPDK (seems in flow look up), and if there are some solutions being discussed<br>
&gt;or working in progress.<br>
<br>
</span>I personally did some investigation in this area. One of the bottlenecks in classifier is due to sub-table lookup.<br>
Murmur hash is used in OvS and it is  recommended enabling intrinsics with -march=native/CFLAGS=&quot;-msse4.<wbr>2&quot;  if not done.<br>
If you have more subtables, the lookups may be taking significant cycles.  I presume you are using OvS 2.7. Some optimizations<br>
were done to  improve classifier  performance(subtable ranking, hash optimizations).<br>
If emc_lookup()/emc_insert() show up in top 5 functions taking significant cycles, worth disabling EMC as below.<br>
          &#39;ovs-vsctl set Open_vSwitch . other_config:emc-insert-inv-<wbr>prob=0&#39;<br></blockquote><div>Thanks much for your advice. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
&gt;Are you wanting for this number to be larger by default ?<br>
&gt;I am not sure, I need to understand whether it is good or bad to set it larger.<br>
&gt;Are you wanting for this number to be configurable ?<br>
&gt;Probably good.<br>
&gt;<br>
&gt;BTW, after reading part of DPDK document, it strengthens to decrease to copy<br>
&gt;between cache and memory and get cache hit as much as possible to get<br>
&gt;fewer cpu cycles to fetch data, but now I am totally lost on how does OVS-<br>
&gt;DPDK emc and classifier map to the LLC.<br>
<br>
</span>I didn&#39;t get your question here. PMD is like any other thread and has EMC and a classifier per ingress port.<br>
The EMC,  classifier subtables and other data structures will make it to LLC when accessed.<br></blockquote><div>ACK. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As already mentioned using RDT Cache Allocation Technology(CAT), one can assign cache ways to high priority threads<br>
<a href="https://software.intel.com/en-us/articles/introduction-to-cache-allocation-technology" rel="noreferrer" target="_blank">https://software.intel.com/en-<wbr>us/articles/introduction-to-<wbr>cache-allocation-technology</a><br>
<span class="HOEnZb"><font color="#888888"><br>
- Bhanuprakash.<br>
<br>
</font></span></blockquote></div><br></div></div>