[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZJROrq1c4eO7cLUB@nanopsycho>
Date: Thu, 22 Jun 2023 15:37:50 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Piotr Gardocki <piotrx.gardocki@...el.com>
Cc: netdev@...r.kernel.org, intel-wired-lan@...ts.osuosl.org,
przemyslaw.kitszel@...el.com, michal.swiatkowski@...ux.intel.com,
pmenzel@...gen.mpg.de, kuba@...nel.org,
maciej.fijalkowski@...el.com, anthony.l.nguyen@...el.com,
simon.horman@...igine.com, aleksander.lobakin@...el.com,
gal@...dia.com
Subject: Re: [PATCH net-next] net: fix net device address assign type
Thu, Jun 22, 2023 at 02:42:53PM CEST, piotrx.gardocki@...el.com wrote:
>On 22.06.2023 10:22, Jiri Pirko wrote:
>> Wed, Jun 21, 2023 at 03:21:06PM CEST, piotrx.gardocki@...el.com wrote:
>>> Commit ad72c4a06acc introduced optimization to return from function
>>
>> Out of curiosity, what impact does this optimization have? Is it worth
>> it to have such optimization at all? Wouldn't simple revert of the fixes
>> commit do the trick? If not, see below.
>
>Thanks for review. My main goal originally was to skip call to ndo_set_mac_address.
>The benefit of this depends on how given driver handles such request. Some drivers
>notify their hardware about the "change", iavf for example sends a request to PF
>driver (and awaits for response). i40e and ice already had this check (I removed
>them in previous patch set) and we wanted to also introduce it in iavf. But it
>was suggested to move this check to core to have benefit for all drivers.
Okay. Makes sense.
Powered by blists - more mailing lists