netdev - Re: [PATCH net-next v4] rps: selective flow shedding during softnet overflow

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:	Tue, 23 Apr 2013 16:11:23 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	willemb@...gle.com, netdev@...r.kernel.org,
	stephen@...workplumber.org
Subject: Re: [PATCH net-next v4] rps: selective flow shedding during softnet
 overflow

On Tue, 2013-04-23 at 18:41 -0400, David Miller wrote:
> From: Willem de Bruijn <willemb@...gle.com>
> Date: Tue, 23 Apr 2013 16:31:34 -0400
> 
> > - disable the kconfig option by default, as it is workload specific.
> 
> If this logic only kicks in during overload, I see no reason why we
> shouldn't have this protection enabled unconditionally, all the time.
> 
> Does it hurt performance under normal workloads?
> 
> If the new logic is controlled by overload thresholds then it should
> have no impact whatsoever in non-overload scenerios.

Exact.

I guess we should at least not include this code on !SMP builds

This adds some code, but as long as you don't write into
flow_limit_cpu_bitmap/flow_limit_table_len we wont allocate the memory,
thus this is disabled.

Then, if enabled, it only kicks if the number of queued packets is above
half the max backlog (netdev_max_backlog >> 1)

So on non overload scenario, cost is 0.

On overload scenario, the loaded cpu keeps a 512 bytes array hot in his
cache. (fl->history[])


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