[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1275743224.3490.44.camel@bigi>
Date: Sat, 05 Jun 2010 09:07:04 -0400
From: jamal <hadi@...erus.ca>
To: Changli Gao <xiaosuo@...il.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Tom Herbert <therbert@...gle.com>,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [RFC] act_cpu: redirect skb receiving to a special CPU.
Changli,
I like the idea..
My preference would be to not change ingress qdisc to have queues.
The cpuid should be sufficient to map to a remote cpu queue, no?
Now, if you could represent each cpu as a netdevice, then we wouldnt
need any change;-> And we could have multiple types of ways to redirect
to cpus instead of just doing IPIs - example, ive always thought of
sending over something like HT (I think it would be a lot cheaper).
I didnt queit understand the map OFFSET part. is this part of rfs?
cheers,
jamal
On Sat, 2010-06-05 at 18:56 +0800, Changli Gao wrote:
> I am going to implement a CPU action, which can be used with ingress
> qdisc to redirect skb receiving to a special cpu. It is much like RPS,
> but more flexible:
>
> * choose the hash function with the help of cls_flow.c
> * pin special traffic to a dedicate CPU
> * weighted packets distributing
>
> act_cpu will use the function enqueue_to_backlog() supplied by RPS to
> redirect skb receiving, and have two kind paramter:
>
> * cpu CPUID - the ID of CPU, which handles this traffic
> * map OFFSET - map the mirror class ID to CPUID: CPUID = mirror class ID + CPUID
>
> sch_ingress will be enhanced to support class tree.
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists