<p dir="ltr"><br>
On 10 Mar 2014 17:22, "Victor Julien" <<a href="mailto:victor@inliniac.net">victor@inliniac.net</a>> wrote:<br>
><br>
> On 03/10/2014 09:27 AM, Victor Julien wrote:<br>
> > On 03/08/2014 06:13 PM, Victor Julien wrote:<br>
> >> In the context of Duartes report of #1011, I've been playing with some<br>
> >> validation code for the clustering.<br>
> >><br>
> >> There is some debug code in<br>
> >> <a href="https://github.com/inliniac/suricata/pull/880">https://github.com/inliniac/suricata/pull/880</a>, esp.<br>
> >> <a href="https://github.com/inliniac/suricata/commit/939e3e3fd9550916361e3f5ff4c54590d3949bbb">https://github.com/inliniac/suricata/commit/939e3e3fd9550916361e3f5ff4c54590d3949bbb</a><br>
> >><br>
> >> If I run this in workers mode with anything above 1 thread, it fails<br>
> >> almost immediately:<br>
> >><br>
> >> suricata: stream-tcp.c:4180: StreamTcpPacket: Assertion<br>
> >> `!(p->flow->thread_id != tv->thread_id)' failed.<br>
> >> Aborted (core dumped)<br>
> >> # gdb ./src/suricata core<br>
> >> ...<br>
> >> Reading symbols from /usr/src/oisf/src/suricata...done.<br>
> >><br>
> >> warning: core file may not match specified executable file.<br>
> >> [New LWP 3711]<br>
> >> [New LWP 3712]<br>
> >> [New LWP 3714]<br>
> >> [New LWP 3713]<br>
> >> [New LWP 3710]<br>
> >> [New LWP 3709]<br>
> >><br>
> >> warning: Can't read pathname for load map: Input/output error.<br>
> >> [Thread debugging using libthread_db enabled]<br>
> >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".<br>
> >> Core was generated by `./src/suricata -c copy-of-suricata-pfring.yaml<br>
> >> --af-packet=eth2 -S /dev/null -v'.<br>
> >> Program terminated with signal 6, Aborted.<br>
> >> #0  0x00007f82f353e425 in __GI_raise (sig=<optimized out>) at<br>
> >> ../nptl/sysdeps/unix/sysv/linux/raise.c:64<br>
> >> 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.<br>
> >> (gdb) f 4<br>
> >> #4  0x0000000000518ec3 in StreamTcpPacket (tv=0x226c33f0, p=0x2deae00,<br>
> >> stt=0x7f82e00138c0, pq=0x226c37a0) at stream-tcp.c:4180<br>
> >> 4180                BUG_ON(p->flow->thread_id != tv->thread_id);<br>
> >> (gdb) print p->flow->thread_id<br>
> >> $1 = 3710<br>
> >> (gdb) print tv->thread_id<br>
> >> $2 = 3711<br>
> >> (gdb)<br>
> >><br>
> >> AF_PACKET is set to do cluster_flow. None of the AF_PACKET options seem<br>
> >> to affect it.<br>
> >><br>
> >> # ethtool -k eth2<br>
> >> Offload parameters for eth2:<br>
> >> rx-checksumming: off<br>
> >> tx-checksumming: off<br>
> >> scatter-gather: off<br>
> >> tcp-segmentation-offload: off<br>
> >> udp-fragmentation-offload: off<br>
> >> generic-segmentation-offload: off<br>
> >> generic-receive-offload: off<br>
> >> large-receive-offload: off<br>
> >> rx-vlan-offload: off<br>
> >> tx-vlan-offload: off<br>
> >> ntuple-filters: off<br>
> >> receive-hashing: off<br>
> >><br>
> >> In autofp mode it does work correctly. There we have our own flow<br>
> >> distribution logic instead of relying on the nic/driver/capture method...<br>
> >><br>
> ><br>
> > I've been working with Alfredo and Luca to understand whats happening on<br>
> > the pfring side of this. It turns out our pfring setup logic isn't correct.<br>
> ><br>
> > The patch at PR 881 [1] fixes the start up for pfring by moving<br>
> > pfring_enable_ring to the start of ReceivePfringLoop() so that we don't<br>
> > enable the ring before all threads have registered to it with<br>
> > pfring_set_cluster.<br>
> ><br>
> ><br>
> > I suspect a similar issue in the AF_PACKET, although there is a<br>
> > difference with pfring. In pfring, the problem would self-correct<br>
> > quickly after startup. After a few minutes all packets would be on the<br>
> > correct threads. In AF_PACKET this isn't the case.<br>
> ><br>
> > AF_PACKET doesn't do most of the setup logic in the ThreadInit function,<br>
> > but in the Loop function by calling AFPCreateSocket. This means that<br>
> > multiple threads may execute this logic concurrently. I wonder if that<br>
> > perhaps leads to some race condition. Eric, any ideas there?<br>
><br>
> I've been moving around the init code a bit, but I don't see any<br>
> difference. It seems that the cluster flow setting enabled a fanout mode<br>
> 'skb rxhash'. Any idea what factors influence that?</p>
<p dir="ltr">I don't know for sure if I got your question right, but here it goes. In Suricata, when in cluster_flow, the af-packet fanout mode is explicitly set to PACKET_FANOUT_HASH (plus defrag mode if active). What influences the fanout mode in af-packet is the destination, source and ports. It use the combination of those three keys to calculate the hash.</p>

<p dir="ltr">><br>
> --<br>
> ---------------------------------------------<br>
> Victor Julien<br>
> <a href="http://www.inliniac.net/">http://www.inliniac.net/</a><br>
> PGP: <a href="http://www.inliniac.net/victorjulien.asc">http://www.inliniac.net/victorjulien.asc</a><br>
> ---------------------------------------------<br>
><br>
> _______________________________________________<br>
> Suricata IDS Devel mailing list: <a href="mailto:oisf-devel@openinfosecfoundation.org">oisf-devel@openinfosecfoundation.org</a><br>
> Site: <a href="http://suricata-ids.org">http://suricata-ids.org</a> | Participate: <a href="http://suricata-ids.org/participate/">http://suricata-ids.org/participate/</a><br>
> List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel</a><br>
> Redmine: <a href="https://redmine.openinfosecfoundation.org/">https://redmine.openinfosecfoundation.org/</a><br>
</p>