<div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>I think it would be 
of interest in every situation Suricata takes advantages from software 
as well as from hardware solutions in which some kind of flow coalescing 
exists.</div><div>
Also suricata woul<font color="#000000" face="arial, sans-serif"><span style="white-space:nowrap">d benefit of a "cache-friendly" packet dispatcher every time a multicore environment is used. </span></font></div>
<div><font color="#000000" face="arial, sans-serif"><span style="white-space:nowrap">I would suggest a super interesting project that tries to address this kind of aspects: <a href="http://fireless.cs.cornell.edu/netslice">http://fireless.cs.cornell.edu/netslice</a></span></font></div>

<div><font color="#000000" face="arial, sans-serif"><span style="white-space:nowrap"><br></span></font></div><div style><font color="#000000" face="arial, sans-serif"><span style="white-space:nowrap">@chris just realized I've sent the mail just to you... sry for this</span></font></div>
<div><font color="#000000" face="arial, sans-serif"><span style="white-space:nowrap"><br></span></font></div>
<div><font color="#000000" face="arial, sans-serif"><span style="white-space:nowrap">best regards</span></font></div><div><font color="#000000" face="arial, sans-serif"><span style="white-space:nowrap">vito</span></font></div>

</div><div class="gmail_extra"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 3, 2013 at 3:40 PM, Victor Julien <span dir="ltr"><<a href="mailto:victor@inliniac.net" target="_blank">victor@inliniac.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 04/03/2013 10:59 AM, Chris Wakelin wrote:<br>
> On 03/04/13 09:19, Victor Julien wrote:<br>
>> > On 04/03/2013 02:31 AM, Song liu wrote:<br>
>>> >><br>
>>> >> Right now, all workers will share one big flow table, and there will be<br>
>>> >> contention for it.<br>
>>> >> Supposed that the network interface is flow affinity, each worker will<br>
>>> >> handle individual flows.<br>
>>> >> In this way, I think it makes more sense that each worker has its own<br>
>>> >> flow table rather than one big table to reduce contention.<br>
>>> >><br>
>> ><br>
>> > We've been discussing this before and I think it would make sense. It<br>
>> > does require quite a bit of refactoring though, especially since we'd<br>
>> > have to support the current setup as well for the non-workers runmodes.<br>
>> ><br>
> It sounds like a good idea when things like PF_RING are supposed to<br>
> handle the flow affinity onto virtual interfaces for us (PF_RING DNA +<br>
> libzero clusters do, and there's the PF_RING_DNA_SYMMETRIC_RSS flag for<br>
> PF_RING DNA without libzero and interfaces that support RSS).<br>
<br>
</div>Actually, all workers implementations share the same assumption<br>
currently: flow based load balancing in pf_ring, af_packet, nfq, etc. So<br>
I think it makes sense to have a flow engine per worker in all these cases.<br>
<br>
Currently we have a single "FlowManager" thread, which acts as a garbage<br>
collector. It runs outside of the packet paths and deals with things<br>
like timeouts, etc. This will continue to lead to some contention. It's<br>
very non-greedy though, using trylock's it backs away as soon as locks<br>
are busy.<br>
<br>
We'll have to see if we'd want a FlowManager per flow engine, keep the<br>
current single one, or maybe something in between.<br>
<div class="im HOEnZb"><br>
--<br>
---------------------------------------------<br>
Victor Julien<br>
<a href="http://www.inliniac.net/" target="_blank">http://www.inliniac.net/</a><br>
PGP: <a href="http://www.inliniac.net/victorjulien.asc" target="_blank">http://www.inliniac.net/victorjulien.asc</a><br>
---------------------------------------------<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<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" target="_blank">http://suricata-ids.org</a> | Participate: <a href="http://suricata-ids.org/participate/" target="_blank">http://suricata-ids.org/participate/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel</a><br>
Redmine: <a href="https://redmine.openinfosecfoundation.org/" target="_blank">https://redmine.openinfosecfoundation.org/</a><br>
</div></div></blockquote></div><br></div>