Re: How to classify a port range?

[Andy Furniss <adf.lists@gmail.com>]

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.