[Oisf-users] Benchmark testing with Trex

Peter Manev petermanev at gmail.com
Fri Dec 7 08:14:49 UTC 2018


On Thu, Dec 6, 2018 at 6:55 PM Nidhi V Singhai <nidhivar at gmail.com> wrote:
>
> Hello Victor
>
> Apologies for the delay in response. I did not have access to my setup till now. Please find the requested data below
>
> DUT -
> Distro: CentOS
> Kernel : 4.14.62-2.v7.x86_64
> This is Intel I350 4-port Gigabit NIC and I am using 2 ports for my testing connected to two ports of the box running TRex.
>
> This is a gen7 CPU and I have used RPS:
> echo 4 > /sys/class/net/enp1s0f2/queues/rx-0/rps_cpus
> echo 2 > /sys/class/net/enp1s0f3/queues/rx-0/rps_cpus
>

Sorry it may be obvious but just wanted to confirm  - Is this on the
Suricata system or on the replay machine ?

> I have disabled NIC offloading as per the Septun doc, stopped irqbalance, and pinned interrupts to different cores. I can see that the right queues are being used for my packets in /proc/interrupts.
>
> My AF-Packet config is below:
> - interface: enp1s0f2
>    cluster-id: 99
>     cluster-type: cluster_flow
>     defrag: yes
>     use-mmap: yes
>     tpacket-v3: yes
>     ring-size: 400000
>     block-size: 393216
>
> On Trex, currently I am using the configuration in the package (avl/sfr_delay_10_1g_asa_nat.yaml). I have modified this file to generate a traffic of 150Mbps by using only a couple of pcaps from this file and adjusting their cps. I have 255 clients and 10 servers.
>
> Few stats from my last run. Please note that I do have other services running as well on the system which are using the CPU which would explain the kernel_drops.
> capture.kernel_packets                     | Total                     | 75591077
> capture.kernel_drops                       | Total                     | 4410661
> tcp.pkt_on_wrong_thread                    | Total                     | 29509415
>

Could you please upload a stats.log here please  -
https://redmine.openinfosecfoundation.org/issues/2725  with your set
up info?
I am trying to trace down  "wrong_thread"  occurrences and to find the
reason for it.

> Kindly let me know if you need any more details.
>

I think you may also consider increasing "max-pending-packets" in
suricata.yaml if you haven't done it already.

> Many thanks
> Nidhi.
>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 23 Nov 2018 16:14:40 +0100
>> From: Victor Julien <lists at inliniac.net>
>> To: oisf-users at lists.openinfosecfoundation.org
>> Subject: Re: [Oisf-users] Benchmark testing with Trex
>> Message-ID: <e30943f3-1955-803f-1546-df9b3be31a05 at inliniac.net>
>> Content-Type: text/plain; charset=utf-8
>>
>> Hi Nidhi,
>>
>> On 15-11-18 18:28, Nidhi V Singhai wrote:
>> > I am collecting some suricata performance figures for my setup and am
>> > using Trex for traffic replay. I am using standard trex profiles with
>> > mostly http/https traffic currently. With suricata 4.1, I am observing
>> > around 50% of the packets on wrong thread. I have a dual core system
>> > with HT. I have disabled NIC offloading and set single rx/tx queues for
>> > my interfaces. There are no capture drops registered. Has anyone else
>> > tried suricata with trex? Can someone please suggest what might be the
>> > cause of packets on wrong thread and how to avoid it?
>>
>> At Suricon18 Joe's talk dealt with trex testing, however he did not test
>> 4.1 yet. So the 'wrong thread' counters weren't yet available. He is
>> planning to repeat the testing, so we maybe we will learn whether he
>> will run into the same.
>>
>> Can you give some more details on your setup? Distro, kernel, ethtool
>> output, hardware, afpacket section of your yaml, etc?
>>
>> Also things like trex setup would be useful.
>>
>> Thanks!
>> Victor
>


More information about the Oisf-users mailing list