netdev - Re: ingress policying for realtime protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <555DDF5C.8080503@mojatatu.com>
Date:	Thu, 21 May 2015 09:36:28 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Eric Dumazet <eric.dumazet@...il.com>
CC:	Cong Wang <cwang@...pensource.com>, netdev <netdev@...r.kernel.org>
Subject: Re: ingress policying for realtime protocol

On 05/21/15 03:07, Uwe Kleine-König wrote:
> On Wed, May 20, 2015 at 05:30:40PM -0700, Eric Dumazet wrote:
>> On Wed, 2015-05-20 at 16:46 -0700, Cong Wang wrote:
>>
>>> There is very little to do on ingress side since there is no queue at all,
>>> not to mention priority, you could try ifb to see if it fits your need.
>>
>> Note that if the need is to police traffic, ifb is not really needed :
>>
>> TC="tc"
>> DEV="dev eth0"
>> IP=10.246.11.51/32
>> $TC qdisc del $DEV ingress 2>/dev/null
>> $TC qdisc add $DEV ingress
>> $TC filter add $DEV parent ffff: protocol ip u32 match ip src $IP \
>> 	police rate 1Mbit burst 10Mbit mtu 66000 action drop/continue
>>
>> $TC -s filter ls $DEV parent ffff: protocol ip
> I have something like that (matching on dst mac addresses instead of src ip):
>
> 	tc qdisc add dev eth0 handle ffff: ingress
> 	tc filter add dev eth0 parent ffff: protocol all prio 10 u32 match ether dst 01:15:4E:00:00:01 police pass
> 	tc filter add dev eth0 parent ffff: protocol all prio 50 u32 match u32 0 0 at 0 police rate 100kbit burst 10k drop
>
> So Cong interpreted my question right and probably I just used the
> wrong keywords to make you understand the same.

I think both Cong and Eric are right.
You wanted to priotize something thats _realtime_ by using queues, so
Cong answered your question with ifb which will provide you a queue on
ingress.
OTOH, You should really avoid queues of any sort if latency is
important to you - hence what Eric said is correct. Jitter will occur
when it matters the most for you i.e when congestion kicks in; otherwise
it will work (when there is no congestion;->)

So your requirements are conflicting and the result is two talented
people are intepretting things differently;->

So some questions to you:
Why is there a 100Kbps limit for everything else? If it has to be at
100Kbps, what is wrong with the policy you have?

 From my quick reading is it seems this thing has a state machine infact
where sometimes you have to drop all other packets and when the state
machine transitions to a stable state then you just want to accept all
packets but prioritize its protocol packets. Also the state machine
seems to involve more than one port (for path redundancy reasons).
So where is this rate control coming from?

cheers,
jamal

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html