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  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:	Mon, 13 Jul 2009 10:49:50 -0700 (PDT)
From:	David Miller <>
Subject: Re: [PATCH v2] Receive Packet Steering

From: Tom Herbert <>
Date: Sun, 3 May 2009 21:03:01 -0700

> @@ -758,6 +758,8 @@ struct net_device
>  	void			*ax25_ptr;	/* AX.25 specific data */
>  	struct wireless_dev	*ieee80211_ptr;	/* IEEE 802.11 specific data,
>  						   assign before registering */
> +	u16			*rps_map;
> +	int			rps_map_len;
>  /*
>   * Cache line mostly used on receive path (including eth_type_trans())

So essentially this table is a user defined (via sysctl) group of cpus
among which to distribute incoming traffic for a device, right?

Why not take this to it's logical end point, which is to monitor
transmits using a tiny flow lookup table, and map receives of the same
flow to the same cpu?

You can even "cheat" and not store the whole flow key in the small
lookup table, just use the resulting hash value as the key.  Also,
if "best effort" is considered OK you can even do away with hash
chaining as well, further decreasing the space cost of the table.

If your goal is to steer traffic to the cpu on which the receiving
application is operating, that seems to me to be the only way to
reliably and consistently hit that target.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists