All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emmett Culley <emmett@webengineer.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Problem deleting tc rules
Date: Tue, 20 Nov 2007 23:47:07 +0000	[thread overview]
Message-ID: <474371FB.60404@webengineer.com> (raw)
In-Reply-To: <200711201843.13299.pragma@omnikron.net>


Szymon Stefanek wrote:
> Hi all! :)
> 
> I see that this is partially covered in the mailing list archive
> but at the moment I can't find a straight & working answer.
> 
> I have an imq device with dynamically attacched classes/qdiscs/filters.
> There is a hashing filter that maps the last octet of an user's IP address
> to a class (and associated qdisc). The "empty" filter looks like this:
> 
> filter parent 1: protocol ip pref 5 u32
> filter parent 1: protocol ip pref 5 u32 fh 2: ht divisor 256
> filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 
> 0 link 2:  (rule hit 0 success 0)
>   match 00000000/00000000 at 12 (success 0 )
>     hash mask 000000ff at 16
> 
> I'm adding the hash entries dynamically, as users get attacched to the system 
> (this is a dynamic PPPoE access concentrator).
> 
> tc filter add dev imq0 protocol ip parent 1:0 prio 5 u32 ht 
> 2:<LASTIPOCTETHEX>: match ip dst <IPADDRESS> flowid 1:<CLASSID>
> 
> <IPADDRESS> is the address of the newly attacched user, <CLASSID> is
> a dynamically assigned unique identifier and <LASTIPOCTETHEX> is the
> last octet of the user's IP address.
> 
> This works and I get a tc tree like this:
> 
> filter parent 1: protocol ip pref 5 u32
> filter parent 1: protocol ip pref 5 u32 fh 2: ht divisor 256
> filter parent 1: protocol ip pref 5 u32 fh 2:1:800 order 2048 key ht 2 bkt 1 
> flowid 1:4098  (rule hit 0 success 0)
>   match 0a050001/ffffffff at 16 (success 0 )
> filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 
> 0 link 2:  (rule hit 0 success 0)
>   match 00000000/00000000 at 12 (success 0 )
>     hash mask 000000ff at 16
> 
> Nice.
> 
> If another user gets added to the same hash bucket I get something like:
> 
> filter parent 1: protocol ip pref 5 u32
> filter parent 1: protocol ip pref 5 u32 fh 2: ht divisor 256
> filter parent 1: protocol ip pref 5 u32 fh 2:1:800 order 2048 key ht 2 bkt 1 
> flowid 1:4098  (rule hit 0 success 0)
>   match 0a050001/ffffffff at 16 (success 0 )
> filter parent 1: protocol ip pref 5 u32 fh 2:1:801 order 2048 key ht 2 bkt 1 
> flowid 1:4099  (rule hit 0 success 0)
>   match 0a060001/ffffffff at 16 (success 0 )
> filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 
> 0 link 2:  (rule hit 0 success 0)
>   match 00000000/00000000 at 12 (success 0 )
>     hash mask 000000ff at 16
> 
> 
> Now when the users go away I want to _programmatically_ remove the associated 
> filter entries. This doesn't work unless I manually specify the filter handle 
> (handle 2:1:801). The problem is that I actually don't know the filter
> handle since its last part is assigned automatically by tc. I would need
> to relaunch tc with the show option, capture its output and parse it...
> this is an overkill. If I try to delete handle 2:1: (just like in the add 
> command) then ALL the rules with handle 2:1:* get deleted (and this is 
> obviously not what I want).
> 
> Trying to add filters with completly specified handle (like fh 2:1:4098)
> doesn't work unless the last part is EXACTLY what tc would set automatically 
> (this is 800, 801 etc...). But since I have multiple unsynchronized processes
> that do the adding job then I don't know which handles have been already
> used and thus can't guess what which handle to add next. Synchronizing
> the processes and sharing a database would be again a very huge overkill.
> 
> Trying to assign an unique filter id by using pref creates a mess since it 
> adds three filters at once for every preference value. And removing doesn't 
> work either with tc complaining about "No such file or directory".
> 
> I have read somewhere that deleting a qdisc will also delete the filters
> attacched to it but this doesn't seem to work: the qdisc is deleted
> but the filter in the hash bucket is not.
> 
> So finally, can I programmatically remove a filter without knowing exactly its 
> handle ? How ? Is there another way to match filters ? Maybe on flowid... ?
> Add/remove by using direct syscalls ?
> 
> 
I resolved this by adding "pref <LASTIPOCTETHEX>" to the filter rule:

tc filter add dev <iface> parent 1:0 protocol ip pref <user_id> u32 match ip dst <user_ip> flowid 1:<user_id (HEX)>

replacing "add" with "del" to remove filter.

In my case I used the last two octets to create a user_id value as I am serving DHCP to subnet 172.16.128.0/17

Note that the pref value has to be in base 10.

Regards,
 Emmett
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  reply	other threads:[~2007-11-20 23:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20 17:43 [LARTC] Problem deleting tc rules Szymon Stefanek
2007-11-20 23:47 ` Emmett Culley [this message]
2007-11-21  1:27 ` Szymon Stefanek
2007-11-21 21:57 ` Emmett Culley

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=474371FB.60404@webengineer.com \
    --to=emmett@webengineer.com \
    --cc=lartc@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.