[Oisf-users] Benchmark testing with Trex

[Nidhi V Singhai]

Hello Peter

On Fri, Dec 7, 2018 at 8:15 AM Peter Manev <petermanev at gmail.com> wrote:

> 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 ?
>
> Yes, this is the DUT running suricata.


> > 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.
>
> I'll add the details to this link. I'll be able to do that next week once
I have access to it again.


> > 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.
>

I haven't changed max-pending-packets. Will change this value and monitor
the behavior.

>
> > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20181207/b02faf2b/attachment.html>