From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4833C3A5A1 for ; Sun, 25 Aug 2019 17:52:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AA5E02082F for ; Sun, 25 Aug 2019 17:52:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="t6Tq+Wdv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728791AbfHYRwj (ORCPT ); Sun, 25 Aug 2019 13:52:39 -0400 Received: from mail-pf1-f179.google.com ([209.85.210.179]:33135 "EHLO mail-pf1-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727835AbfHYRwj (ORCPT ); Sun, 25 Aug 2019 13:52:39 -0400 Received: by mail-pf1-f179.google.com with SMTP id g2so10087460pfq.0; Sun, 25 Aug 2019 10:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tRdy6DBgNd6uaPx/aa/9AFdmyvouH4INH60SDvCM99U=; b=t6Tq+Wdvgxv62t/0yoGN2Ernd7b25qDBYgMm8mzTDcUOob1BEedzcHcnOQe+yFcTnH TCzew7gxk+wRzNDUyfO5UcrlOahiaKKWMLFq0oXeeZxCsOZOhkjL0s66HutLB/U2y7pv hwlkQOrO2z8r6177R9mBUUDxfUxbTuuwGywlxU5o2yVgVCEX7Pi5C89igxPrGOXFJUwQ +VMyA3ImZFccy0wS+w62rElFHkhiHsOxVFGvG45SfzIPViBtPwn8Bxgh1q9cX2B8BJcB eJIZKvwNHuJKGaCWvXCEUWTQAcohsK3PYuMzHdyrMO3J5spsyEttONopHQ4w15Ne9dlC h0wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tRdy6DBgNd6uaPx/aa/9AFdmyvouH4INH60SDvCM99U=; b=CpMX9eIX7PQ8id9VdHJq5AHF7ixOlbNYk4AfYPP8mn2nqt3Hc2KBNBLU+cbZEDjruq 8ht6L/PfNk9MAyyneil4qzQk5n6SeBHFLrRXAoEIhCFurMuzEUf6Ac75PE6PkyEZDaRZ aGUbwSZIX6yLewFeNdhtwrufL4199kBuqBKYue82okUmp0JC/xSO0E5f53CqdaloVF8w OTUHAkoLH7Br5+sD/F2bGLh5ULnEiBDo5nBK1GtNWys/87IpUPhHCZ7le/2MZo5XVWg+ 6/KdYqqg00GzI7RCyKw6GQvB3bkwyw4mte+KsB5Z6AXZwBJ4T3IGSWCGcJYA79w2FXF2 Opig== X-Gm-Message-State: APjAAAUhmJOxGQgw7xvHs+6HWfNz9X7ieXPsECukk0Jr7z3lJ+hwYBic Xy0rs+pYjnh5A2TKzvbqyRCrlCT5JMjbUBHhf8bnq5kI X-Google-Smtp-Source: APXvYqzUBAdViNre6pTAcceEcq8yiQ0SRL0lMKzFdjSQo1Zdrub61iSHHApDF7DHdd/mE2hCSVdEWrZGmOq6td3Xyew= X-Received: by 2002:a62:2ac4:: with SMTP id q187mr15778717pfq.242.1566755558563; Sun, 25 Aug 2019 10:52:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Cong Wang Date: Sun, 25 Aug 2019 10:52:27 -0700 Message-ID: Subject: Re: Unable to create htb tc classes more than 64K To: Akshat Kakkar Cc: Anton Danilov , NetFilter , lartc , netdev Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Aug 21, 2019 at 11:00 PM Akshat Kakkar wrote: > > On Thu, Aug 22, 2019 at 3:37 AM Cong Wang wrote: > > > I am using ipset + iptables to classify and not filters. Besides, if > > > tc is allowing me to define qdisc -> classes -> qdsic -> classes > > > (1,2,3 ...) sort of structure (ie like the one shown in ascii tree) > > > then how can those lowest child classes be actually used or consumed? > > > > Just install tc filters on the lower level too. > > If I understand correctly, you are saying, > instead of : > tc filter add dev eno2 parent 100: protocol ip prio 1 handle > 0x00000001 fw flowid 1:10 > tc filter add dev eno2 parent 100: protocol ip prio 1 handle > 0x00000002 fw flowid 1:20 > tc filter add dev eno2 parent 100: protocol ip prio 1 handle > 0x00000003 fw flowid 2:10 > tc filter add dev eno2 parent 100: protocol ip prio 1 handle > 0x00000004 fw flowid 2:20 > > > I should do this: (i.e. changing parent to just immediate qdisc) > tc filter add dev eno2 parent 1: protocol ip prio 1 handle 0x00000001 > fw flowid 1:10 > tc filter add dev eno2 parent 1: protocol ip prio 1 handle 0x00000002 > fw flowid 1:20 > tc filter add dev eno2 parent 2: protocol ip prio 1 handle 0x00000003 > fw flowid 2:10 > tc filter add dev eno2 parent 2: protocol ip prio 1 handle 0x00000004 > fw flowid 2:20 Yes, this is what I meant. > > I tried this previously. But there is not change in the result. > Behaviour is exactly same, i.e. I am still getting 100Mbps and not > 100kbps or 300kbps > > Besides, as I mentioned previously I am using ipset + skbprio and not > filters stuff. Filters I used just to test. > > ipset -N foo hash:ip,mark skbinfo > > ipset -A foo 10.10.10.10, 0x0x00000001 skbprio 1:10 > ipset -A foo 10.10.10.20, 0x0x00000002 skbprio 1:20 > ipset -A foo 10.10.10.30, 0x0x00000003 skbprio 2:10 > ipset -A foo 10.10.10.40, 0x0x00000004 skbprio 2:20 > > iptables -A POSTROUTING -j SET --map-set foo dst,dst --map-prio Hmm.. I am not familiar with ipset, but it seems to save the skbprio into skb->priority, so it doesn't need TC filter to classify it again. I guess your packets might go to the direct queue of HTB, which bypasses the token bucket. Can you dump the stats and check? Thanks.