On Thu, Jun 27, 2024 at 04:55:47PM +0200, Marcin Szycik wrote: > Track the number of rules and recipes added to switch. Add a tracepoint to > ice_aq_sw_rules(), which shows both rule and recipe count. This information > can be helpful when designing a set of rules to program to the hardware, as > it shows where the practical limit is. Actual limits are known (64 recipes, > 32k rules), but it's hard to translate these values to how many rules the > *user* can actually create, because of extra metadata being implicitly > added, and recipe/rule chaining. Chaining combines several recipes/rules to > create a larger recipe/rule, so one large rule added by the user might > actually consume multiple rules from hardware perspective. > > Rule counter is simply incremented/decremented in ice_aq_sw_rules(), since > all rules are added or removed via it. > > Counting recipes is harder, as recipes can't be removed (only overwritten). > Recipes added via ice_aq_add_recipe() could end up being unused, when > there is an error in later stages of rule creation. Instead, track the > allocation and freeing of recipes, which should reflect the actual usage of > recipes (if something fails after recipe(s) were created, caller should > free them). Also, a number of recipes are loaded from NVM by default - > initialize the recipe counter with the number of these recipes on switch > initialization. > > Example configuration: > cd /sys/kernel/tracing > echo function > current_tracer > echo ice_aq_sw_rules > set_ftrace_filter > echo ice_aq_sw_rules > set_event > echo 1 > tracing_on > cat trace > > Example output: > tc-4097 [069] ...1. 787.595536: ice_aq_sw_rules <-ice_rem_adv_rule > tc-4097 [069] ..... 787.595705: ice_aq_sw_rules: rules=9 recipes=15 > tc-4098 [057] ...1. 787.652033: ice_aq_sw_rules <-ice_add_adv_rule > tc-4098 [057] ..... 787.652201: ice_aq_sw_rules: rules=10 recipes=16 > > Reviewed-by: Michal Swiatkowski <[email protected]> > Reviewed-by: Przemek Kitszel <[email protected]> > Signed-off-by: Marcin Szycik <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
