netdev - Re: [PATCH RFC] act_cpu: packet distributing

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]

Date:	Thu, 15 Jul 2010 18:54:57 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	hadi@...erus.ca
Cc:	Changli Gao <xiaosuo@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>,
	Tom Herbert <therbert@...gle.com>, netdev@...r.kernel.org
Subject: Re: [PATCH RFC] act_cpu: packet distributing

Le jeudi 15 juillet 2010 à 08:48 -0400, jamal a écrit :
> On Wed, 2010-07-14 at 12:17 +0800, Changli Gao wrote:
> 
> > Thanks, I'll try. It is a write critical section, and for me it is
> > difficult to convert this lock to RCU. Could you show me some
> > examples?
> 
> RCU maybe a little trickier here Eric. Actions could be shared i.e. 
> example, it is possible to have a policer action restricting rates for a
> group of flows  across multiple netdevices etc. Since action stats get
> written to by different CPUs concurrently. It could be probably done if
> one was to implement per-cpu stats which get summed-up when user space
> asks.

It's certainly tricky, but is act_cpu useful in its current shape, based
on an infrastructure that had to use a lock because of exact
rates/accounting ?

I dont understand how distributing packets to different cpus, if going
through a central lock can be an improvement. Changli patches are most
of the time not documented, and no performance data is provided.

Even if we solve this locking problem, using percpu variables, act_cpu
hits another problem :

The socket refcount, taken by the 'master' cpu, and released by the
consumer cpu.

RFS provides sort of a lazy flow-based distribution without central lock
or cache line ping pongs. Why Changli dont use this, we dont know yet.

--
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