From mboxrd@z Thu Jan  1 00:00:00 1970
From: Cong Wang <xiyou.wangcong@gmail.com>
Subject: Re: Fwd: u32 ht filters
Date: Sat, 10 Feb 2018 12:41:57 -0800
Message-ID: <CAM_iQpXwKmuuDaHWuJ+E60P2pr00tsVr2+p_hY++D7Vi8Hbavw@mail.gmail.com>
References: <9c8f997d-339c-5088-0bb5-124e9f55f02d@itcare.pl>
 <CAM_iQpX_CG9casEeFiXtnBNUg15ZWrdskp3JbFnXd=zXBeb7cg@mail.gmail.com>
 <20180207070148.GA2149@nanopsycho.orion> <CAM_iQpXkmSPGXfbOyLH-BMT+_u4MfEG+y78H5JNr9x1i=nNTJw@mail.gmail.com>
 <20180208073846.GA2041@nanopsycho>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Jiri Pirko <jiri@mellanox.com>,
        Linux Kernel Network Developers <netdev@vger.kernel.org>,
        =?UTF-8?Q?Pawe=C5=82_Staszewski?= <pstaszewski@itcare.pl>
To: Jiri Pirko <jiri@resnulli.us>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pg0-f41.google.com ([74.125.83.41]:39659 "EHLO
        mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751182AbeBJUmS (ORCPT
        <rfc822;netdev@vger.kernel.org>); Sat, 10 Feb 2018 15:42:18 -0500
Received: by mail-pg0-f41.google.com with SMTP id w17so5410122pgv.6
        for <netdev@vger.kernel.org>; Sat, 10 Feb 2018 12:42:18 -0800 (PST)
In-Reply-To: <20180208073846.GA2041@nanopsycho>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Wed, Feb 7, 2018 at 11:38 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Thu, Feb 08, 2018 at 12:08:36AM CET, xiyou.wangcong@gmail.com wrote:
>>On Tue, Feb 6, 2018 at 11:01 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Wed, Feb 07, 2018 at 06:09:15AM CET, xiyou.wangcong@gmail.com wrote:
>>>>Hi, Jiri
>>>>
>>>>Your  commit 7fa9d974f3c2a016b9accb18f4ee2ed2a738585c
>>>>breaks the tc script by Pawe=C5=82. Please find below for details.
>>>
>>> Did you do the bisection?
>>> The commit just uses block struct instead of q, but since they
>>> are in 1:1 relation, that should be equvivalent. So basically you still
>>> have per-qdisc hashtables for u32.
>>
>>Well, at least the following fixes the problem here. But I am not sure
>>if it is expected too for shared block among multiple qdiscs.
>
> For shared block, block->q is null.

According to this comment:
/* block_index not 0 means the shared block is requested */

and the code,

        if (!block) {
                block =3D tcf_block_create(net, q, extack);

block->q is set to q, and q is always non-NULL AFAIU.

Also, I don't know if it is intended, but block->q always points to
the parent qdisc rather than the qdisc attached to a class.


>>
>>
>>@@ -338,7 +330,7 @@ static struct hlist_head *tc_u_common_hash;
>>
>> static unsigned int tc_u_hash(const struct tcf_proto *tp)
>> {
>>-       return hash_ptr(tp->chain->block, U32_HASH_SHIFT);
>>+       return hash_ptr(tp->chain->block->q, U32_HASH_SHIFT);
>> }
>>
>> static struct tc_u_common *tc_u_common_find(const struct tcf_proto *tp)
>>@@ -348,7 +340,7 @@ static struct tc_u_common *tc_u_common_find(const
>>struct tcf_proto *tp)
>>
>>        h =3D tc_u_hash(tp);
>>        hlist_for_each_entry(tc, &tc_u_common_hash[h], hnode) {
>>-               if (tc->block =3D=3D tp->chain->block)
>>+               if (tc->block->q =3D=3D tp->chain->block->q)
>
> :O I don't get it. tc->block is pointer, tc->block->q is pointer. And
> they are different at the same time for non-shared block.

If you look into Pawel's script, a new block is created for each class
therefore a different tc_u_common is created which causes the
ht 9:22 can't be found.