netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Phil Sutter <phil@nwl.cc>,
	Stephen Hemminger <stephen@networkplumber.org>
Cc: netdev@vger.kernel.org
Subject: Re: [iproute PATCH] tc: u32: Fix key folding in sample option
Date: Thu, 4 Feb 2021 08:19:55 -0500	[thread overview]
Message-ID: <6948a2a9-1ed2-ce8d-daeb-601c425e1258@mojatatu.com> (raw)
In-Reply-To: <20210202183051.21022-1-phil@nwl.cc>

Hi Phil,

I couldnt tell by inspection if what used to work before continues to.
In particular the kernel version does consider the divisor when folding.

Two examples that currently work, if you can try them:

Most used scheme:
---
tc filter add dev $DEV parent 999:0  protocol ip prio 10 u32 \
ht 2:: \
sample ip protocol 1 0xff match ip src 1.2.3.4/32 flowid 1:10 \
action ok
----

and this i also found in one of my scripts:
----
tc filter add dev $DEV parent 999:0  protocol ip prio 10 u32 \
ht 2:: \
sample u32 0x00000806 0x0000ffff at 12 \
match u32 0x00000800 0x0000ff00 at 12 flowid 1:10 \
action ok
----

Probably a simple meaning of "working" is:
the values before and after (your changes) are consistent.

If also you will do us a kindness and add maybe a testcase in tdc?
This way next person wanting to fix it can run the tests first before
posting a patch.

cheers,
jamal

On 2021-02-02 1:30 p.m., Phil Sutter wrote:
> In between Linux kernel 2.4 and 2.6, key folding for hash tables changed
> in kernel space. When iproute2 dropped support for the older algorithm,
> the wrong code was removed and kernel 2.4 folding method remained in
> place. To get things functional for recent kernels again, restoring the
> old code alone was not sufficient - additional byteorder fixes were
> needed.
> 
> While being at it, make use of ffs() and thereby align the code with how
> kernel determines the shift width.
> 
> Fixes: 267480f55383c ("Backout the 2.4 utsname hash patch.")
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> Initially I considered changing the kernel's key folding instead as the
> old method didn't just ignore key bits beyond the first byte. Yet I am
> not sure if this would cause problems with hardware offloading. And
> given the fact that this simplified key folding is in place since the
> dawn of 2.6, it is probably not such a big problem anyway.
> ---
>   tc/f_u32.c | 11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/tc/f_u32.c b/tc/f_u32.c
> index 2ed5254a40d5f..a5747f671e1ea 100644
> --- a/tc/f_u32.c
> +++ b/tc/f_u32.c
> @@ -978,6 +978,13 @@ show_k:
>   	goto show_k;
>   }
>   
> +static __u32 u32_hash_fold(struct tc_u32_key *key)
> +{
> +	__u8 fshift = key->mask ? ffs(ntohl(key->mask)) - 1 : 0;
> +
> +	return ntohl(key->val & key->mask) >> fshift;
> +}
> +
>   static int u32_parse_opt(struct filter_util *qu, char *handle,
>   			 int argc, char **argv, struct nlmsghdr *n)
>   {
> @@ -1110,9 +1117,7 @@ static int u32_parse_opt(struct filter_util *qu, char *handle,
>   				}
>   				NEXT_ARG();
>   			}
> -			hash = sel2.keys[0].val & sel2.keys[0].mask;
> -			hash ^= hash >> 16;
> -			hash ^= hash >> 8;
> +			hash = u32_hash_fold(&sel2.keys[0]);
>   			htid = ((hash % divisor) << 12) | (htid & 0xFFF00000);
>   			sample_ok = 1;
>   			continue;
> 


  reply	other threads:[~2021-02-04 13:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02 18:30 [iproute PATCH] tc: u32: Fix key folding in sample option Phil Sutter
2021-02-04 13:19 ` Jamal Hadi Salim [this message]
2021-02-04 14:04   ` Phil Sutter
2021-02-04 14:34     ` Jamal Hadi Salim
2021-02-04 14:36       ` Jamal Hadi Salim
2021-02-04 14:50       ` Phil Sutter
2021-02-04 15:28         ` Jamal Hadi Salim
2021-02-04 16:50           ` Phil Sutter
2021-02-04 18:08             ` Jamal Hadi Salim
2021-07-05 14:17 ` Phil Sutter
2021-07-05 17:25   ` Jamal Hadi Salim
2021-08-03 16:42     ` Phil Sutter

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=6948a2a9-1ed2-ce8d-daeb-601c425e1258@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=netdev@vger.kernel.org \
    --cc=phil@nwl.cc \
    --cc=stephen@networkplumber.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).