On February 23, 2018 5:20:35 PM PST, Vinicius Costa Gomes 
<vinicius.go...@intel.com> wrote:
>This allows filters added by tc-flower and specifying MAC addresses,
>Ethernet types, and the VLAN priority field, to be offloaded to the
>This reuses most of the infrastructure used by ethtool, ethtool can be
>used to read these filters, but modification and deletion can only be
>done via tc-flower.

You would want to check what other drivers supporting both ethtool::rxnfc and 
cls_flower do, but this can be seriously confusing to an user. As an user I 
would be more comfortable with seeing only rules added through ethtool via 
ethtool and those added by cls_flower via cls_flower. They will both access a 
shared set of resources but it seems easier for me to dump rules with both 
tools to figure out why -ENOSPC was returned rather than seeing something I did 
not add. Others might see it entirely differently.

If you added the ability for cls_flower to indicate a queue number and either a 
fixed rule index or auto-placement (RX_CLS_LOC_ANY), could that eliminate 
entirely the need for adding MAC address steering in earlier patches?


Reply via email to