Support hardware stats for tc actions

[William Tu]

Support hardware stats for tc actions

* Explain the bug(s)

tc hardware stats are not offloaded from some offloaded actions (pedit, sample, skbedit)

* brief explanation of fixes

Implement the necessary callbacks to report back stats for these actions.

* How to test

Configure two mlx5 rep devices and VFs.
Add tc offloaded tc rules with pedit action, and hit that rule with traffic

e.g:

mac1=`cat /sys/class/net/$VF/address`
mac2=`cat /sys/class/net/$VF2/address`
fake_mac="20:22:33:44:55:66"
IP1="7.7.7.1"
IP2="7.7.7.2"

function config_vf() {
    local ns=$1
    local vf=$2
    local rep=$3
    local ip=$4 # optional
    local mac=$5 # optional
    local prefix=24

    if [[ "$ip" == *":"* ]]; then
        # ipv6
        prefix=64
    fi

    echo "[$ns] VF $vf (${mac:+$mac/}$ip) -> REP $rep"
    ip address flush dev $rep
    ip link set dev $rep up
    ip netns add $ns
    ${mac:+ip link set $vf address $mac}
    ip link set $vf netns $ns
    ${ip:+ip -netns $ns address replace dev $vf $ip/$prefix}
    ip -netns $ns link set $vf up
}

tc qdisc add dev $REP ingress
tc qdisc add dev $REP2 ingress

config_vf ns0 $VF $REP $IP1
config_vf ns1 $VF2 $REP2 $IP2

tc filter add dev $REP ingress protocol arp prio 1 flower \
      action mirred egress redirect dev $REP2

tc filter add dev $REP2 ingress protocol arp prio 1 flower \
      action mirred egress redirect dev $REP

echo "add ct rules"
# req
tc filter add dev $REP ingress protocol ip prio 2 flower \
      dst_mac $fake_mac ct_state -trk \
      action ct action goto chain 1

tc filter add dev $REP ingress protocol ip chain 1 prio 2 flower \
      dst_mac $fake_mac ct_state +trk+new \
      action ct commit \
      action pedit ex munge eth dst set $mac2 pipe \
      action mirred egress redirect dev $REP2

tc filter add dev $REP ingress protocol ip chain 1 prio 2 flower \
      dst_mac $fake_mac ct_state +trk+est \
      action pedit ex munge eth dst set $mac2 pipe \
      action mirred egress redirect dev $REP2

# reply chain0,ct -> chain1,fwd
tc filter add dev $REP2 ingress protocol ip prio 2 flower \
      dst_mac $mac1 \
      action ct action goto chain 1

tc filter add dev $REP2 ingress protocol ip prio 2 chain 1 flower \
      dst_mac $mac1 ct_state +trk+est \
      action mirred egress redirect dev $REP

echo "run traffic"
ip netns exec ns1 timeout 13 iperf -s &
sleep 0.5
ip netns exec ns0 ip n r $IP2 dev $VF lladdr $fake_mac
ip netns exec ns0 timeout 13 iperf -t 12 -c $IP2 &

tc -s filter show dev $REP ingress

see pedit hw counters are advancing (or not if patches not applied):
filter pref 2 flower
filter pref 2 flower handle 0x1
  dst_mac 20:22:33:44:55:66
  eth_type ipv4
  ct_state -trk
  in_hw in_hw_count 1
        action order 1: ct zone 0 pipe
         index 1 ref 1 bind 1 installed 2 sec used 0 sec firstused 2 sec
        Action statistics:
        Sent 6521850590 bytes 4307703 pkt (dropped 0, overlimits 0 requeues 0)
        Sent software 112 bytes 2 pkt
        Sent hardware 6521850478 bytes 4307701 pkt
        backlog 0b 0p requeues 0

        action order 2: gact action goto chain 1
         random type none pass val 0
         index 1 ref 1 bind 1 installed 2 sec used 0 sec firstused 2 sec
        Action statistics:
        Sent 6521850590 bytes 4307703 pkt (dropped 0, overlimits 0 requeues 0)
        Sent software 112 bytes 2 pkt
        Sent hardware 6521850478 bytes 4307701 pkt
        backlog 0b 0p requeues 0

* What it could break.

Hardware counters of tc pedit, sample, and skbedit actions.