[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1432217045.4060.91.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Thu, 21 May 2015 07:04:05 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
Cc: Cong Wang <cwang@...pensource.com>,
netdev <netdev@...r.kernel.org>,
Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: ingress policying for realtime protocol
On Thu, 2015-05-21 at 09:07 +0200, 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
Thats a very aggressive policer.
You cannot really prevent 'other traffic' from consuming wire time.
Dropping them at receiver might be too late, as they had already blocked
your realtime traffic.
>
> . So Cong interpreted my question right and probably I just used the
> wrong keywords to make you understand the same. I try again to put my
> idea in words to make it explicit:
>
> I imagine that it could help in my case if I could assert that MRP
> packets are handled priorized over other traffic without throwing away
> so many unrelated packets. For egress that works by e.g. using a prio
> qdisc. For ingress however only shaping is available.
Your script actually implements policing.
If you want shaping, then you need to add IFB to get queues and
scheduling of these queues.
>
> So the question essentially is: Why doesn't this work for ingress? Cong
> wrote "there is no queue at all [for ingress]". Is this by design? Or is
> it just not implemented because noone spend the effort to work on that?
> Do you think it would help me?
Use IFB, and install TBF on top of it.
(But bypass it for your realtime packets)
Adapt following script for example.
ETH=eth0
IFB=ifb0
modprobe ifb
ip link set dev $IFB up
tc qdisc del dev $ETH ingress 2>/dev/null
tc qdisc add dev $ETH ingress 2>/dev/null
tc filter add dev $ETH parent ffff: \
protocol all prio 10 u32 match ether dst 01:15:4E:00:00:01 police pass
tc filter add dev $ETH parent ffff: \
protocol ip u32 match u32 0 0 action mirred egress \
redirect dev $IFB
ethtool -K $ETH gro off lro off 2>/dev/null
ifconfig $IFB txqueuelen 1000
tc qdisc del dev $IFB root 2>/dev/null
tc qdisc add dev $IFB root \
tbf limit 1000 burst 64000 rate 100kbit
--
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
Powered by blists - more mailing lists