Re: [PATCH v7] rps: Receive Packet Steering

[Stephen Hemminger <shemminger@vyatta.com>]

On Thu, 18 Mar 2010 21:37:01 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Le jeudi 18 mars 2010 à 14:48 +0800, Changli Gao a écrit :
> > sigh! How about adding file for each cpu weight setting.
> > 
> > .../rx-0/rps_cpu0...n
> > 
> > BTW: I think exporting the hook of hash function will help in some
> > case. So users can choose which hash to use depend on their
> > applications. I know FreeBSD supports hash based on flow, source or
> > CPU. Some network application have multiple instances for taking full
> > advantage of the SMP/C hardware, and each instance binds to a special
> > CPU/Core, so they need some kind of load distributing algorithm for
> > load balancing.
> > 
> 
> exporting skb->rxhash would not be that interesting, but the cpu number
> of last cpu handling the skb and queuing it on socket might be usefull.
> 
> > For example, memcached uses hash based on key, and its developer may
> > implement a hash function for RPS. Then it apply the following
> > iptables rule:
> > 
> > iptables -A PREROUTING -t nat -m cpu --cpuid 0 -m tcp --dport 1234
> > --REDIRECT 8081
> > iptables -A PREROUTING -t nat -m cpu --cpuid 0 -m tcp --dport 1234
> > --REDIRECT 8082
> 
> Well, this would work only if load is evenly distributed to all cpus.
> But you understand this kind of setup has nothing to do with RPS.
> Going through REDIRECT (and conntrack) would kill performance, and would
> not work for unpriviledged users (iptables changes forbidden).
> It wont scale for future machines with 64 or 128 cores.
> 
> maybe some extension of REDIRECT target, being able to add cpu number to
> destination port :
> 
> iptables -A PREROUTING -t nat -m tcp --dport 1234 --REDIRECT 1234+cpu
> 
> 
> > ...
> > 
> > No other things to change, it can take full advantage of the
> > underlying hardware transparently.
> > 
> 
> Coming to mind would be a new socket operation, "bind to cpu", like the
> "bind to device" operation.
> 
> This would work without need for netfilter (and permission to change its
> rules)
> 
> But it would require changes to applications, to fully exploit SMP
> capabilities of machine.

Let's not make a useful feature (RPS) unusable by making it so complex
that mortals can't understand it.


--