netdev - Re: [PATCH] rfs: Receive Flow Steering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <o2j412e6f7f1004020358mf9455fcbqdbb2d762d94a7aa2@mail.gmail.com>
Date:	Fri, 2 Apr 2010 18:58:28 +0800
From:	Changli Gao <xiaosuo@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Tom Herbert <therbert@...gle.com>, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH] rfs: Receive Flow Steering

On Fri, Apr 2, 2010 at 3:29 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le vendredi 02 avril 2010 à 13:04 +0800, Changli Gao a écrit :
>
>
> Your claim of RPS being not good for applications is wrong, our test
> results show an improvement as is. Maybe your applications dont scale,
> because of bad habits, or collidings heuristics, I dont know.
>

I didn't mean RPS isn't good for applications. I mean that the
performance improvement of applications isn't as much as firewalls'.
In the other words, we can do much better than the current RPS,  as
RFS does.

>
> Whole point of Herbert patches is you dont need to change applications
> and put complex logic in them, knowing exact machine topology.
>
> Your suggestion is very complex, because you must bind each thread on a
> particular cpu, and this is pretty bad for many reasons. We should allow
> thread migrations, because scheduler or admin know better than the
> application.
>
> Application writers should rely on standard kernel mechanisms, and
> schedulers, because an application have a limited point of view of what
> really happens on the machine.
>

Yes, it is more complex. Some high performance server use the
event-driven model, such as memcached, nginx and lighttpd. This model
has high performance on UP with no doubt, and on SMP they usually use
one individual epoll fd for each Core/CPU, and the acceptor dispatches
works among these epoll fds. This program model is popular, and  it
bypass the  system scheduler. I think the socket option SO_RPSCPU can
help this kind of applications work better, why not do that?
Compatility with other Unixes isn't a good cause, for high performance
applications, there are always lots of OS special features used. For
example: epoll vs kqueue, tcp defer accept vs accept filter.

-- 
Regards，
Changli Gao(xiaosuo@...il.com)
--
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