Re: [Cake] Ingress classification

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:

>> On 6 Feb 2019, at 13:54, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> 
>> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>> 
>>> 
>>> Thank you John, that has confirmed my understanding that in essence
>>> it’s not possible in linux to mangle/mark the first packet on ingress
>>> and you ideally need the DSCP to be correct.
>> 
>> Not with iptables, but you can do it with tc filters. Either by writing
>> a BPF filter, or by using the pedit action (which actually changes bytes
>> in the packet unlike skbedit).
>> 
>> -Toke
>
> It’s not so much about tweaking DSCP values but more about persuading
> packets to go into different cake tins for bandwidth
> allocation/latency target purposes.  I’m assuming there’s a
> performance advantage in not tweaking the packet if at all necessary.

I very much doubt you would be able to measure any difference between
the two approaches. And actually remarking the packets would keep the
effect when they traverse the network (say, for WiFi links).

> The previously mentioned attempt at getting egress tc filters to work
> *did* actually succeed. Toke may ‘appreciate’ the following hacked
> extract from an sqm-scripts layer_cake.qos
>
>
> egress() {
>     SILENT=1 $TC qdisc del dev $IFACE root
>     $TC qdisc add dev $IFACE root $( get_stab_string ) cake \
>         bandwidth ${UPLINK}kbit $( get_cake_lla_string ) ${EGRESS_CAKE_OPTS} ${EQDISC_OPTS}
>
>     MAJOR=$( tc qdisc show dev $IFACE | head -1 | awk '{print $3}' )
>     $TC filter add dev $IFACE parent $MAJOR protocol ip handle 0x01 fw action skbedit priority ${MAJOR}1
>     $TC filter add dev $IFACE parent $MAJOR protocol ip handle 0x03 fw action skbedit priority ${MAJOR}3
>     $TC filter add dev $IFACE parent $MAJOR protocol ip handle 0x04 fw action skbedit priority ${MAJOR}4
> }
>
> The ingress side being:
>
>     $TC filter add dev $IFACE parent ffff: protocol all prio 10 u32 \
>         match u32 0 0 flowid 1:1 action connmark action mirred egress redirect dev $DEV
>
>     MAJOR=$( tc qdisc show dev $DEV | head -1 | awk '{print $3}' )
>     $TC filter add dev $DEV parent $MAJOR protocol all handle 0x01 fw action skbedit priority ${MAJOR}1
>     $TC filter add dev $DEV parent $MAJOR protocol all handle 0x03 fw action skbedit priority ${MAJOR}3
>     $TC filter add dev $DEV parent $MAJOR protocol all handle 0x04 fw action skbedit priority ${MAJOR}4
>
>     # Configure iptables chain to mark packets
>     ipt -t mangle -N QOS_MARK_${IFACE}
>
> A variety of rules along the lines (to set the packet mark)
>     iptables -t mangle -A QOS_MARK_${IFACE} -p tcp -s 192.168.218.5/255.255.255.255 -m comment \
>         --comment "Skybox DSCP CS1 Bulk" -j MARK --set-mark 0x01/0xff
>
>     # save the packet mark to connmark
>     ipt -t mangle -A QOS_MARK_${IFACE} -j CONNMARK  --save-mark
>
>     # Send unmarked connections to the marking chain
>     ipt -t mangle -A PREROUTING  -i $IFACE -m mark --mark 0x00/0xff -g QOS_MARK_${IFACE}
>     ipt -t mangle -A POSTROUTING -o $IFACE -m mark --mark 0x00/0xff -g QOS_MARK_${IFACE}
>
>
> The vast majority of the egress stuff above being shamelessly stolen
> from a github entry I saw ;-)
>
>
> I do wonder if there’s a more efficient way of doing it though.
> Setting CONNMARK directly instead of setting a packet mark and then
> copying that across to a connmark would appear sensible?

Depending on how many rules you have, my guess would be that the most
inefficient thing is traversing all of them. You could use ipset to
alleviate this, I guess. Or reimplement the whole thing as a single BPF
filter...

Or maybe just re-evaluate whether you really need that convoluted a
ruleset? ;)

-Toke