I think there is a bug in net/sched/cls_flower.c:fl_init_dissector(), where it reads
FL_KEY_SET_IF_MASKED(mask, keys, cnt, FLOW_DISSECTOR_KEY_IPV4_ADDRS, ipv4); FL_KEY_SET_IF_MASKED(mask, keys, cnt, FLOW_DISSECTOR_KEY_IPV6_ADDRS, ipv6); (and correspondingly further down for enc IP addrs), in that fl_flow_key stores ipv4 and ipv6 in a union, meaning that if a tc flower filter sets, for instance, a destination IPv4 address (and an ethertype of IPv4), the mask for this will also show up in the middle of the source ipv6 address, and lead to the ipv6 key being marked as used. Thus subsequently a call to dissector_uses_key(..., FLOW_DISSECTOR_KEY_IPV6_ADDRS) will return true. While this can be disambiguated by examining key->control.addr_type, this seems like it ought not to be necessary. I apologise if this has been asked before, but is there a reason why the core code cannot fix this up and prevent drivers from seeing it in their tc offload routines? -Ed