<div dir="ltr">Peter, did you have any opportunity to look at this? Just curious to hear what, if anything, you may have found.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 3, 2017 at 8:07 AM, Peter Manev <span dir="ltr"><<a href="mailto:petermanev@gmail.com" target="_blank">petermanev@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 Thu, Dec 29, 2016 at 1:27 PM, erik clark <<a href="mailto:philosnef@gmail.com">philosnef@gmail.com</a>> wrote:<br>
> Sorry, I missed the bottom there. I am using<br>
> <a href="https://github.com/JustinAzoff/can-i-use-afpacket-fanout" rel="noreferrer" target="_blank">https://github.com/<wbr>JustinAzoff/can-i-use-<wbr>afpacket-fanout</a> to confirm that<br>
> flows are properly being assigned.<br>
><br>
> Be aware, this does NOT work with ESP traffic. I had seen reverse udp/tcp<br>
> failures and couldn't figure out why, so I pulled pcap for the events (these<br>
> are marked with source/dest information from the afpacket go script), and<br>
> saw that 99.7ish% of the events posted with reverse failures were ESP<br>
> traffic. Since I can't do anything with ESP content anyway, I could not care<br>
> less that these are failing, as there is no way to do inspection on it.<br>
><br>
> To get udp6/tcp6, you just set them with -N as in the example, specifying<br>
> tcp6 instead of tcp4 and so on.<br>
><br>
<br>
</span>Ok. Thank you.<br>
I will take a look and do some runs and will feedback the findings.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Thu, Dec 29, 2016 at 6:20 AM, erik clark <<a href="mailto:philosnef@gmail.com">philosnef@gmail.com</a>> wrote:<br>
>><br>
>> Yes, thats the patch at <a href="http://marc.info" rel="noreferrer" target="_blank">marc.info</a> in the previous email. Please note the<br>
>> submitter of that patch. :)<br>
>><br>
>> On Thu, Dec 29, 2016 at 4:10 AM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On 28 Dec 2016, at 15:00, erik clark <<a href="mailto:philosnef@gmail.com">philosnef@gmail.com</a>> wrote:<br>
>>><br>
>>> (patch for ixgbe)<br>
>>> <a href="http://marc.info/?l=linux-netdev&m=148181173415107&w=2" rel="noreferrer" target="_blank">http://marc.info/?l=linux-<wbr>netdev&m=148181173415107&w=2</a><br>
>>><br>
>>> (patch to ixgbe/src/kompat.h since it wont compile on rhel7.3 due to<br>
>>> kernel version issues. None of this is pf_ring specific)<br>
>>><br>
>>> <a href="https://raw.githubusercontent.com/ntop/PF_RING/41b6eb733e295c91375b135d2816dbdd09b4b548/drivers/intel/ixgbe/ixgbe-4.1.5-zc/src/kcompat.h" rel="noreferrer" target="_blank">https://raw.githubusercontent.<wbr>com/ntop/PF_RING/<wbr>41b6eb733e295c91375b135d2816db<wbr>dd09b4b548/drivers/intel/<wbr>ixgbe/ixgbe-4.1.5-zc/src/<wbr>kcompat.h</a><br>
>>><br>
>>><br>
>>> In a different mail you mentioned that there is also a patch from Red Hat<br>
>>> with regards to at-packet not working on this kernel version - is this<br>
>>> fixed/working now?<br>
>>><br>
>>><br>
>>> (ethtool arguments and irq setting)<br>
>>><br>
>>> ethtool -C em1 rx-usecs 1 adaptive-rx off<br>
>>> ethtool -G em1 rx 4096 tx 4096<br>
>>> for x in tso gro lro gso rx tx sg; do ethtool -K em1 $x off; done<br>
>>> /opt/src/ixgbe-4.4.6/scripts/<wbr>set_irq_affinity em1<br>
>>> ethtool -X em1 hkey<br>
>>> 6d:5a:6d:5a:6d:5a:6d:5a:6d:5a:<wbr>6d:5a:6d:5a:6d:5a:6d:5a:6d:5a:<wbr>6d:5a:6d:5a:6d:5a:6d:5a:6d:5a:<wbr>6d:5a:6d:5a:6d:5a:6d:5a:6d:5a<br>
>>> ethtool -N em1 rx-flow-hash tcp4 sdfn<br>
>>> ethtool -N em1 rx-flow-hash udp4 sdfn<br>
>>><br>
>>><br>
>>> Can you confirm all flows are good for tcp/udp/4/6?<br>
>>> (And how do you confirm it?)<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> I have 64 cores, and set_irq_affinity pulls a full set of 63 rss queues.<br>
>>> Thanks!<br>
>>><br>
>>> On Sat, Dec 24, 2016 at 1:28 PM, erik clark <<a href="mailto:philosnef@gmail.com">philosnef@gmail.com</a>> wrote:<br>
>>>><br>
>>>> I will post that on Wednesday when I get back to work. Its 6? ethtool<br>
>>>> statements, and 2 ixgbe patches (for rhel7 at least). Anything else should<br>
>>>> be just 1 patch. This is running the 4.4.6 ixgbe released from intel<br>
>>>> directly. This has worked for the most recent 3 kernels under RHEL7.<br>
>>>><br>
>>>> On Sat, Dec 24, 2016 at 12:51 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> > On 24 Dec 2016, at 18:22, erik clark <<a href="mailto:philosnef@gmail.com">philosnef@gmail.com</a>> wrote:<br>
>>>>> ><br>
>>>>> > I have seen several places commenting that you should set the RSS<br>
>>>>> > queue to 1. However, when examining af_packet with Bro, a patch released<br>
>>>>> > from Redhat for the ixgbe kernel module, and some ethtool tweaking, we have<br>
>>>>> > found that (for Bro at least) running a full 63 (we have 54 cores) RSS<br>
>>>>> > queues vastly improves performance, and keeps state intact across sessions.<br>
>>>>> ><br>
>>>>> > Based on this update, which fixes the broken implementation of<br>
>>>>> > setting a symmetric hash in the hardware of the card<br>
>>>>><br>
>>>>> Can you please share a bit in a bit more detail-<br>
>>>>> Which ixgbe/kernel version that is ?<br>
>>>>> Which patch is it ?<br>
>>>>> What is the ethtool tweaking procedure?<br>
>>>>><br>
>>>>> Thanks<br>
>>>>><br>
>>>>> > (again ixgbe, not tested with i40e), is it still necessary to run one<br>
>>>>> > queue? If so, you can't run Bro and Suri on the same box with af_packet and<br>
>>>>> > get equivalent performance out of both tools. Having run Suri with 63 queues<br>
>>>>> > for a week now, it seems performance is considerably better than with<br>
>>>>> > pf_ring, and I can not find any unusual behavior in my alerts...<br>
>>>>> ><br>
>>>>> > ______________________________<wbr>_________________<br>
>>>>> > Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@<wbr>openinfosecfoundation.org</a><br>
>>>>> > Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support:<br>
>>>>> > <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/<wbr>support/</a><br>
>>>>> > List:<br>
>>>>> > <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.<wbr>openinfosecfoundation.org/<wbr>mailman/listinfo/oisf-users</a><br>
>>>><br>
>>>><br>
>>><br>
>><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Regards,<br>
Peter Manev<br>
</font></span></blockquote></div><br></div>