* Re: [Bugme-new] [Bug 14875] New: iproute2: problems with "tc filter replace" and u32 hashing filters
[not found] <bug-14875-10286@http.bugzilla.kernel.org/>
@ 2010-01-04 20:33 ` Andrew Morton
2010-01-05 4:46 ` Patrick McHardy
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2010-01-04 20:33 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, stas
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Fri, 25 Dec 2009 02:24:00 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14875
>
> Summary: iproute2: problems with "tc filter replace" and u32
> hashing filters
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.32
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: low
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: stas@crypt.org.ru
> Regression: No
>
>
> I'm using u32 hashing filters and have some issues with "tc filter replace"
> command.
>
> Issue 1: "tc filter replace" command does not replace filters inside u32 hash
> tables and works like "tc filter add" command.
>
> Consider the following scenario:
>
> 1. Create qdisc and hashing filters for 10.0.0.0/24 network
>
> tc qdisc add dev eth1 root handle 1: htb
> tc filter add dev eth1 parent 1:0 pref 10 protocol ip u32
> tc filter add dev eth1 parent 1:0 pref 10 handle 100: protocol ip \
> u32 divisor 256
> tc filter add dev eth1 parent 1:0 pref 10 protocol ip u32 ht 800:: \
> match ip src 10.0.0.0/24 hashkey mask 0x000000ff at 12 link 100:
> tc filter add dev eth1 parent 1:0 protocol ip pref 30 u32 \
> match u32 0x0 0x0 at 0 police mtu 1 action drop
>
> 2. Add filter for IP-address 10.0.0.1
>
> tc class add dev eth1 parent 1: classid 1:3 htb rate 256kibit ceil 256kibit
> tc qdisc add dev eth1 parent 1:3 handle 3:0 pfifo limit 50
> tc filter add dev eth1 parent 1: pref 20 u32 ht 100:1: \
> match ip src 10.0.0.1 flowid 1:3
>
> 3. Try to replace filter for 10.0.0.1 with a new one for 10.0.0.2
>
> tc filter replace dev eth1 parent 1: pref 20 u32 ht 100:1: \
> match ip src 10.0.0.2 flowid 1:3
>
> I expect that filter for 10.0.0.1 in hash table 100:1: have been replaced by
> new
> rule for 10.0.0.2. But "tc -p filter show dev eth1" outputs two filters for
> both 10.0.0.1 and 10.0.0.2:
>
> filter parent 1: protocol ip pref 10 u32 fh 100:1:800 order 2048 key ht 100
> bkt 1 flowid 1:3
> match IP src 10.0.0.1/32
> filter parent 1: protocol ip pref 10 u32 fh 100:1:801 order 2049 key ht 100
> bkt 1 flowid 1:3
> match IP dst 10.0.0.2/32
>
> It means that "tc filter replace" command did not delete the filter 100:1:800,
> but attached a new one with handle 100:1:801, just like the "tc filter add"
> command. I think it is a wrong behaviour for "replace" command.
>
>
> Issue 2: It seems that tc does not provide any syntax to replace a single
> filter
> inside the hash table. The command with explicit handle number
>
> tc filter replace dev eth1 parent 1: pref 20 u32 ht 100:1:800 \
> match ip dst 10.0.0.3 flowid 1:3
>
> gives the error message: "ht" must be a hash table.
>
> The similar command with "handle 100:1:800" prints "What is "handle"?" and
> usage information.
>
> The following sequence of "del" and "add" commands works:
>
> tc filter del dev eth1 parent 1: pref 10 handle 100:1:800 u32
> tc filter add dev eth1 parent 1: pref 20 u32 ht 100:1: \
> match ip src 10.0.0.1 flowid 1:3
>
> Note, that "del" command works only when I use "pref 10" (preference value
> for hashing filter 100:), but in "add" command I specified "pref 20"
> (preference for 100:1:800 filter). This is little counterintuitive, but not
> very important.
>
>
> My suggestions about fixing of "tc filter replace" behaviour.
>
> 1. The "replace" command with "ht" argument
>
> tc filter replace dev eth1 parent 1: pref 20 u32 ht 100:1: match ...
>
> should empty the whole table 100:1: and add a new filter with handle 100:1:800.
>
> 2. The command with "handle" argument
>
> tc filter replace dev eth1 parent 1: pref 20 u32 handle 100:1:800 match ...
>
> should replace only one filter with handle 100:1:800.
>
> Thanks for attention.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bugme-new] [Bug 14875] New: iproute2: problems with "tc filter replace" and u32 hashing filters
2010-01-04 20:33 ` [Bugme-new] [Bug 14875] New: iproute2: problems with "tc filter replace" and u32 hashing filters Andrew Morton
@ 2010-01-05 4:46 ` Patrick McHardy
2010-01-05 16:00 ` Stanislav Kruchinin
0 siblings, 1 reply; 3+ messages in thread
From: Patrick McHardy @ 2010-01-05 4:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon, stas
Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=14875
>>
>> I'm using u32 hashing filters and have some issues with "tc filter replace"
>> command.
>>
>> Issue 1: "tc filter replace" command does not replace filters inside u32 hash
>> tables and works like "tc filter add" command.
>>
>> Consider the following scenario:
>>
>> ...
>> 2. Add filter for IP-address 10.0.0.1
>>
>> tc class add dev eth1 parent 1: classid 1:3 htb rate 256kibit ceil 256kibit
>> tc qdisc add dev eth1 parent 1:3 handle 3:0 pfifo limit 50
>> tc filter add dev eth1 parent 1: pref 20 u32 ht 100:1: \
>> match ip src 10.0.0.1 flowid 1:3
>>
>> 3. Try to replace filter for 10.0.0.1 with a new one for 10.0.0.2
>>
>> tc filter replace dev eth1 parent 1: pref 20 u32 ht 100:1: \
>> match ip src 10.0.0.2 flowid 1:3
>>
>> I expect that filter for 10.0.0.1 in hash table 100:1: have been replaced by
>> new
>> rule for 10.0.0.2. But "tc -p filter show dev eth1" outputs two filters for
>> both 10.0.0.1 and 10.0.0.2:
>>
>> filter parent 1: protocol ip pref 10 u32 fh 100:1:800 order 2048 key ht 100
>> bkt 1 flowid 1:3
>> match IP src 10.0.0.1/32
>> filter parent 1: protocol ip pref 10 u32 fh 100:1:801 order 2049 key ht 100
>> bkt 1 flowid 1:3
>> match IP dst 10.0.0.2/32
>>
>> It means that "tc filter replace" command did not delete the filter 100:1:800,
>> but attached a new one with handle 100:1:801, just like the "tc filter add"
>> command. I think it is a wrong behaviour for "replace" command.
You need to specify a handle for the filters to get replaced.
tc filter add dev eth1 parent 1: pref 20 handle 100:1 u32 ht 100:1: \
match ip src 10.0.0.1 flowid 1:3
tc filter replace dev eth1 parent 1: pref 20 handle 100:1 u32 ht 100:1: \
match ip src 10.0.0.2 flowid 1:3
works fine.
>> Issue 2: It seems that tc does not provide any syntax to replace a single
>> filter
>> inside the hash table. The command with explicit handle number
>>
>> tc filter replace dev eth1 parent 1: pref 20 u32 ht 100:1:800 \
>> match ip dst 10.0.0.3 flowid 1:3
>>
>> gives the error message: "ht" must be a hash table.
>>
>> The similar command with "handle 100:1:800" prints "What is "handle"?" and
>> usage information.
Handles consist of a major and minor number, not three numbers,
see above.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bugme-new] [Bug 14875] New: iproute2: problems with "tc filter replace" and u32 hashing filters
2010-01-05 4:46 ` Patrick McHardy
@ 2010-01-05 16:00 ` Stanislav Kruchinin
0 siblings, 0 replies; 3+ messages in thread
From: Stanislav Kruchinin @ 2010-01-05 16:00 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
On 05.01.2010 7:46, Patrick McHardy wrote:
>>> Issue 1: "tc filter replace" command does not replace filters inside u32 hash
>>> tables and works like "tc filter add" command.
>
> You need to specify a handle for the filters to get replaced.
>
> tc filter add dev eth1 parent 1: pref 20 handle 100:1 u32 ht 100:1: \
> match ip src 10.0.0.1 flowid 1:3
>
> tc filter replace dev eth1 parent 1: pref 20 handle 100:1 u32 ht 100:1: \
> match ip src 10.0.0.2 flowid 1:3
>
> works fine.
Thank you, this solves the first issue, but it's little odd that "replace"
command require both "handle" and "ht" parameters, whereas "tc filter del"
command takes only a "handle" parameter.
Me and some of my colleagues are going to write a "tc-u32" and "tc-flow"
manpages to document the tc syntax for u32 filter and for new "flow" filter.
These documents could be useful for other people, and I might want to publish
them. May I ask you, who is the current maintainer of iproute2 manpages?
>>> Issue 2: It seems that tc does not provide any syntax to replace a single
>>> filter inside the hash table. The command with explicit handle number
>
> Handles consist of a major and minor number, not three numbers,
> see above.
Yes, but in case of u32 filters one can add a number of rules to a single hash
bucket. These filters will be numbered as follows: 100:1:800, 100:1:801, etc.
And "tc filter ..." commands accept a handles like 100:1:800 without any errors.
The problem is that there is no way to address these filters using "replace"
command, whereas "del/add" commands perform well.
After execution of the following commands
tc filter add dev eth1 parent 1: pref 20 handle 100:1 u32 ht 100:1: \
match ip src 10.0.0.1 flowid 1:3
tc filter add dev eth1 parent 1: pref 20 handle 100:1 u32 ht 100:1: \
match ip src 10.0.0.2 flowid 1:3
we will have 100:1:800 filter that matches 10.0.0.1, and 100:1:801 that matches
10.0.0.2.
The following command
tc filter replace dev eth1 parent 1: pref 20 handle 100:1:801 u32 ht 100:1: \
match ip src 10.0.0.3 flowid 1:3
gives no error messages but does not replace the IP address in the filter
100:1:801, and adds one more filter with number 100:1:801 for IP 10.0.0.3. As I
wrote before, the sequence of "del" and "add" commands works OK with
three-number handles.
tc filter del dev eth1 parent 1: pref 20 handle 100:1:801 u32
tc filter add dev eth1 parent 1: pref 20 u32 ht 100:1: \
match ip src 10.0.0.3 flowid 1:3
Once again, thanks for a quick reply.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-01-05 16:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <bug-14875-10286@http.bugzilla.kernel.org/>
2010-01-04 20:33 ` [Bugme-new] [Bug 14875] New: iproute2: problems with "tc filter replace" and u32 hashing filters Andrew Morton
2010-01-05 4:46 ` Patrick McHardy
2010-01-05 16:00 ` Stanislav Kruchinin
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).