netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Julian Anastasov <ja@ssi.bg>
Cc: lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	netdev@vger.kernel.org, Dust Li <dust.li@linux.alibaba.com>,
	Jiejian Wu <jiejian@linux.alibaba.com>,
	Jiri Wiesner <jwiesner@suse.de>
Subject: Re: [PATCHv2 RFC net-next 08/14] ipvs: use resizable hash table for services
Date: Wed, 17 Jan 2024 09:54:14 +0000	[thread overview]
Message-ID: <20240117095414.GL588419@kernel.org> (raw)
In-Reply-To: <20231212162444.93801-9-ja@ssi.bg>

On Tue, Dec 12, 2023 at 06:24:38PM +0200, Julian Anastasov wrote:
> Make the hash table for services resizable in the bit range of 4-20.
> Table is attached only while services are present. Resizing is done
> by delayed work based on load (the number of hashed services).
> Table grows when load increases 2+ times (above 12.5% with factor=3)
> and shrinks 8+ times when load decreases 16+ times (below 0.78%).
> 
> Switch to jhash hashing to reduce the collisions for multiple
> services.
> 
> Add a hash_key field into the service that includes table ID and
> bucket ID. This helps the lookup and delete operations.
> 
> Signed-off-by: Julian Anastasov <ja@ssi.bg>

...

> @@ -391,18 +440,29 @@ static inline struct ip_vs_service *
>  __ip_vs_service_find(struct netns_ipvs *ipvs, int af, __u16 protocol,
>  		     const union nf_inet_addr *vaddr, __be16 vport)
>  {
> -	unsigned int hash;
> +	DECLARE_IP_VS_RHT_WALK_BUCKET_RCU();
> +	struct hlist_bl_head *head;
>  	struct ip_vs_service *svc;
> -
> -	/* Check for "full" addressed entries */
> -	hash = ip_vs_svc_hashkey(ipvs, af, protocol, vaddr, vport);
> -
> -	hlist_for_each_entry_rcu(svc, &ipvs->svc_table[hash], s_list) {
> -		if (svc->af == af && ip_vs_addr_equal(af, &svc->addr, vaddr) &&
> -		    svc->port == vport && svc->protocol == protocol &&
> -		    !svc->fwmark) {
> -			/* HIT */
> -			return svc;
> +	struct ip_vs_rht *t, *p;
> +	struct hlist_bl_node *e;
> +	u32 hash, hash_key;
> +
> +	ip_vs_rht_for_each_table_rcu(ipvs->svc_table, t, p) {
> +		/* Check for "full" addressed entries */
> +		hash = ip_vs_svc_hashval(t, af, protocol, vaddr, vport);
> +
> +		hash_key = ip_vs_rht_build_hash_key(t, hash);
> +		ip_vs_rht_walk_bucket_rcu(t, hash_key, head) {
> +			hlist_bl_for_each_entry_rcu(svc, e, head, s_list) {

Hi Julian,

Smatch thinks that head is used uninitialised here.
This does seem to be the case to me too.

> +				if (READ_ONCE(svc->hash_key) == hash_key &&
> +				    svc->af == af &&
> +				    ip_vs_addr_equal(af, &svc->addr, vaddr) &&
> +				    svc->port == vport &&
> +				    svc->protocol == protocol && !svc->fwmark) {
> +					/* HIT */
> +					return svc;
> +				}
> +			}
>  		}
>  	}
>  
> @@ -416,16 +476,26 @@ __ip_vs_service_find(struct netns_ipvs *ipvs, int af, __u16 protocol,
>  static inline struct ip_vs_service *
>  __ip_vs_svc_fwm_find(struct netns_ipvs *ipvs, int af, __u32 fwmark)
>  {
> -	unsigned int hash;
> +	DECLARE_IP_VS_RHT_WALK_BUCKET_RCU();
> +	struct hlist_bl_head *head;
>  	struct ip_vs_service *svc;
> -
> -	/* Check for fwmark addressed entries */
> -	hash = ip_vs_svc_fwm_hashkey(ipvs, fwmark);
> -
> -	hlist_for_each_entry_rcu(svc, &ipvs->svc_table[hash], s_list) {
> -		if (svc->fwmark == fwmark && svc->af == af) {
> -			/* HIT */
> -			return svc;
> +	struct ip_vs_rht *t, *p;
> +	struct hlist_bl_node *e;
> +	u32 hash, hash_key;
> +
> +	ip_vs_rht_for_each_table_rcu(ipvs->svc_table, t, p) {
> +		/* Check for fwmark addressed entries */
> +		hash = ip_vs_svc_fwm_hashval(t, af, fwmark);
> +
> +		hash_key = ip_vs_rht_build_hash_key(t, hash);
> +		ip_vs_rht_walk_bucket_rcu(t, hash_key, head) {
> +			hlist_bl_for_each_entry_rcu(svc, e, head, s_list) {

Ditto.

> +				if (READ_ONCE(svc->hash_key) == hash_key &&
> +				    svc->fwmark == fwmark && svc->af == af) {
> +					/* HIT */
> +					return svc;
> +				}
> +			}
>  		}
>  	}
>  

...

  reply	other threads:[~2024-01-17  9:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-12 16:24 [PATCHv2 RFC net-next 00/14] ipvs: per-net tables and optimizations Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 01/14] rculist_bl: add hlist_bl_for_each_entry_continue_rcu Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 02/14] ipvs: make ip_vs_svc_table and ip_vs_svc_fwm_table per netns Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 03/14] ipvs: some service readers can use RCU Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 04/14] ipvs: use single svc table Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 05/14] ipvs: do not keep dest_dst after dest is removed Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 06/14] ipvs: use more counters to avoid service lookups Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 07/14] ipvs: add resizable hash tables Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 08/14] ipvs: use resizable hash table for services Julian Anastasov
2024-01-17  9:54   ` Simon Horman [this message]
2024-01-17 13:09     ` Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 09/14] ipvs: switch to per-net connection table Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 10/14] ipvs: show the current conn_tab size to users Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 11/14] ipvs: no_cport and dropentry counters can be per-net Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 12/14] ipvs: use more keys for connection hashing Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 13/14] ipvs: add ip_vs_status info Julian Anastasov
2023-12-12 16:24 ` [PATCHv2 RFC net-next 14/14] ipvs: add conn_lfactor and svc_lfactor sysctl vars Julian Anastasov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240117095414.GL588419@kernel.org \
    --to=horms@kernel.org \
    --cc=dust.li@linux.alibaba.com \
    --cc=ja@ssi.bg \
    --cc=jiejian@linux.alibaba.com \
    --cc=jwiesner@suse.de \
    --cc=lvs-devel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).