Re: [PATCH v4] rfs: Receive Flow Steering

[Tom Herbert <therbert@google.com>]

> There are two sometimes conflicting models:
>
> One model is to have the flow's be dispersed and let the scheduler
> be smarter about running the applications on the right CPU's where
> the packets arrive.
>
> The other is to have the flows redirected to the CPU where the application
> previously ran which is what RFS does.
>
> For benchmarks and private fixed configuration systems it is tempting
> to just nail everything down: i.e. use hard SMP affinity, for hardware, processes,
> and flows.  But this is the wrong solution for general purpose systems with
> varying workloads and requirements.  How well does RFS really work when
> applications, processes, and sockets come and go or get migrated among
> CPU's by the scheduler? My concern is this is overlapping scheduler
> design and might be a step backwards.
>
This is true.  There is a fundamental question of whether scheduler
should lead networking or vice versa.  The advantages of networking
following scheduler seem to become more apparent on heavily loaded
systems or with threads that handle more than one flow.

I'm not sure these two models have to be mutually exclusive, we are
looking at some ways to make a hybrid model.

The statement about pinning down resources is also true, we are
actively try to squash any instances this in our applications!

Tom

>
> --
>