<div dir="ltr">Hi all,<div><br></div><div style>IMHO the success key is having a symmetric RSS hash function. Someone already made experiments/studies about this: i.e. <a href="http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf">http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf</a></div>
<div style><br></div><div style>Obviously this could lead to unbalanced flow queue, think about a long standing flows which remain alive for long time</div><div style>period... To take into account this kind of situation one could think to assign a group of processing CPU thread to packets that arrive from the same RSS queue, loosing,  of course, in this case the cache (ant interrupt) affinity benefits. </div>
<div style><br></div><div style>regards</div><div style>vito</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 12:10 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="HOEnZb"><div class="h5">On 04/04/2013 11:53 AM, Eric Leblond wrote:<br>
> On Thu, 2013-04-04 at 11:05 +0200, Victor Julien wrote:<br>
>> On 04/04/2013 10:25 AM, Eric Leblond wrote:<br>
>>> Hello,<br>
>>><br>
>>> On Wed, 2013-04-03 at 15:40 +0200, Victor Julien wrote:<br>
>>>> 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>
>>>> 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>
>>> There may be a special point in the IPS mode. For example, NFQ will soon<br>
>>> provide a cpu fanout mode where the worker will be selected based on<br>
>>> CPU. The idea is to have the NIC do the flow balancing. But this implies<br>
>>> that the return packet may come to a different CPU based on the flow<br>
>>> hash function used by the NIC.<br>
>>> We have the same behavior in af_packet IPS mode...<br>
>><br>
>> I think this can lead to some weird packet order problems. T1 inspects<br>
>> toserver, T2 toclient. If the T1 worker is held up for whatever reason,<br>
>> we may for example process ACKs in T2 for packets we've not processed in<br>
>> T1 yet. I'm pretty sure this won't work correctly.<br>
><br>
> In the case of IPS mode, do inline streaming depends on ACKed packet ?<br>
<br>
</div></div>No, but the stream engine is written with the assumption that what we<br>
see is the order of packets on the wire. TCP packets may still be out of<br>
order of course, but in this case the end-host has to deal with it as well.<br>
<br>
In cases like window checks, sequence validation, SACK checks, etc I can<br>
imagine problems. We'd possibly reject/accept packets in the stream<br>
handling that the end host will treat differently.<br>
<div class="im HOEnZb"><br>
><br>
>> This isn't limited to workers btw, in autofp when using multiple capture<br>
>> threads we can have the same issue. One side of a connection getting<br>
>> ahead of the other.<br>
><br>
> Yes, I've observed this lead to strange behavior...<br>
><br>
>> Don't think we can solve this in Suricata itself, as the OS has a lot of<br>
>> liberty in scheduling threads. A full packet reordering module would<br>
>> maybe work, but it's performance affect would probably completely nix<br>
>> all gains by the said capture methods.<br>
><br>
> Sure<br>
><br>
>>> In this case, we may want to disable the per-worker flow engine which is<br>
>>> a really good idea for other running mode.<br>
>><br>
>> Don't think it would be sufficient. The ordering problem won't be solved<br>
>> by it.<br>
><br>
> Yes, it may be interesting to study a bit the hash function used by NIC<br>
> to see if they behave symetrically. In this case, this should fix the<br>
> issue (at least for NFQ). I will have a look into it.<br>
<br>
</div><div class="im HOEnZb">--<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>