Re: [Intel-wired-lan] [RFC net-next 2/2] ice: make use of DECLARE_FLEX() in ice_switch.c

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Date: Tue, 1 Aug 2023 16:36:57 +0200

> On 8/1/23 15:48, Alexander Lobakin wrote:
>> From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>> Date: Tue, 1 Aug 2023 13:19:23 +0200

[...]

>>> -        status = -EINVAL;
>>> -        goto ice_aq_alloc_free_vsi_list_exit;
>>> +        return -EINVAL;
>>>       }
>>>         if (opc == ice_aqc_opc_free_res)
>>
>> bloat-o-meter results would be nice to have in the commitmsg.
> 
> I will do next time, perhaps you could tell me if I get the results
> right here:
> 
> ./scripts/bloat-o-meter ice_switch.o{ld,}
> add/remove: 2/2 grow/shrink: 3/5 up/down: 560/-483 (77)
> Function                                     old     new   delta
> ice_create_vsi_list_rule                       -     241    +241
> ice_remove_vsi_list_rule                     139     270    +131
> ice_add_adv_rule                            6047    6139     +92
> ice_add_sw_recipe                           2892    2972     +80
> __pfx_ice_create_vsi_list_rule                 -      16     +16
> ice_alloc_recipe                             124     113     -11
> __pfx_ice_aq_alloc_free_vsi_list              16       -     -16
> ice_free_res_cntr                            185     155     -30
> ice_alloc_res_cntr                           154     124     -30
> ice_add_update_vsi_list                     1037     994     -43
> ice_add_vlan_internal                       1027     953     -74
> ice_aq_alloc_free_vsi_list                   279       -    -279
> Total: Before=42183, After=42260, chg +0.18%
> 
> My guess here is that compiler did different decisions about what to
> inline where, what is biggest difference.

77 bytes is very good result, because see below.

> And biggest gain here is avoidance of heap allocs, perhaps that enables
> gcc to shuffle things a bit too.

Exactly, having the stack grown only by 77 bytes after avoiding -- how
many? -- a lot of heap allocations sounds great.

> Another guess is that b-o-m ignores heap bloat, so slight growth is
> expected.

BOM can't calculate any heap usage, it simply compares symbol sizes in
object files.

(BTW, passing /dev/null as the first "object file" is legit, in case you
 just want to see sorted symbol sizes in your module or vmlinux)

> 
> Values reported for ice.ko are the same, with bigger base to compute the
> percent off.
> 
>> [...]
>>
>> Thanks,
>> Olek
> 
> Thank you too, also for our initial talk about on the topic.

No problem, I really feel like this macro would be very useful.

Thanks,
Olek
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan