From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Sat, 17 Dec 2016 22:43:38 +0000 Subject: Re: How to classify a port range? Message-Id: <5855BF9A.9020504@gmail.com> List-Id: References: <2cc58282-00cf-0fb5-9583-3ebc86f7eedd@itlabs.bg> In-Reply-To: <2cc58282-00cf-0fb5-9583-3ebc86f7eedd@itlabs.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Yassen Damyanov wrote: > Hi again LARTC list, > > Andy helped recently to spot a bug in an ematch filter definition that > classifies a range of ports (thanks again!) > > Now I again have a problem with that same classifier, this time on an > ifb device which is "connected" to an eth device to allow for richer > ingress control: > > # ip link set dev ifb0 up > # tc qdisc add dev eth0 handle ffff: ingress > # tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 > action mirred egress redirect dev ifb0 > > # tc qdisc add dev ifb0 root handle 1:0 htb > # tc class add dev ifb0 parent 1:0 classid 1:1 htb rate 30gbit > # tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 match ip > protocol 6 0xff flowid 1:1 > # tc qdisc add dev ifb0 parent 1:1 handle 2:0 htb > # tc class add dev ifb0 parent 2:0 classid 2:1 htb rate 2mbit > # tc filter add dev ifb0 parent 2:0 protocol ip prio 1 basic match > "cmp(u16 at 2 layer transport gt 8079) and cmp(u16 at 2 layer transport > lt 8089)" flowid 2:1 > > When doing measurements, the speed within the shaped range is way below > what would be if no shaping is done, but substantially higher than the > htb rate specified (2mbit). It also differs significantly from test to > test. > > If I just put a u32 filter like this: > > # tc filter add dev ifb0 parent 2:0 protocol ip prio 1 u32 match ip > dport 8080 0xffff flowid 2:1 > > -- this works as expected. > > I see this in the ematch man page and I guess it might be related, but I > am not sure how: > > """ > When using the ipset ematch with the "ifb" device, the outgoing device > will be the ifb device itself, e.g. "ifb0". The original interface > (i.e. the device the packet arrived on) is treated as the incoming > interface. > """ > > Does anyone see what am I missing and how to get that ematch working on > the ifb? Thanks! Seems to work for me with a quick test on lan. Random thoughts - Putting htb qdisc under htb is allowed, but not normal and gets in dmesg "htb: htb qdisc 2: is non-work-conserving?" 30 gig is really high and I see htb sets burst and cburst to 0. Your qlens will be picked up from ifb, default 32 which may be too low for the high bandwidth/htb direct traffic. Nics may be doing hardware/driver software offloads, causing giant packets to hit the qdisc - you can disable with ethtool.