[Oisf-devel] Linux af-packet::mmap enhancement

[Victor Julien]

On 06/23/2011 06:30 PM, chetan loke wrote:
> On Thu, Jun 23, 2011 at 11:59 AM, Victor Julien <victor at inliniac.net> wrote:
>> On 06/23/2011 05:35 PM, chetan loke wrote:
>>
>>> But let's say if we don't implement FANOUT then user-space can infact
>>> achieve both HASH+LB.
>>> If it's not present already, I can export the pre-computed 'rx_hash'
>>> in the libpcap-descriptor/pkt-header.
>>> Once the packet hits suricata, we can steer it an old-thread(who
>>> already is working on this flow)
>>> or round-robin it to the next available thread to achieve load-balance.
>>
>> Suricata can do this. Currently it's internal (and optional) load
>> balancing is just as "blind" the rxhash approach (probably less even
>> balanced even :). Actual load of the threads is not taken into account.
>> But it would be possible it Suricata's architecture to improve this
>> without too much effort I think.
>>
>> The disadvantage is that multiple threads/cpu's/cores will suddenly be
>> handling the same packet, instead of just the one dealing with the
>> FANOUT socket.
>>
> 
> My description wasn't so clear. Actually what I meant was:
> 
> lookup_table : <rx_hash> <thread_id>;
> 
> thread_id = get_worker_th_id (pkt_hdr->rx_hash);
> 
> if (thread_id) {
>   /* This flow is HOT. steer this flow to the same thread */
>   enqueue_pkt_to_thread(thread_id);
> } else {
>  /* This flow is COLD.No thread is handling this flow yet.*/
>  /* So queue it to the next thread */
>     enqueue_pkt_to_thread(GET_NEXT_THREAD(ROUND_ROBIN_POLICY));
>     update lookup_table;
> }
> 
> So no two threads will work on the same flow.

To be clear, this functionality would live in the kernel, right?

Cheers,
Victor

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------