From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [PATCH iproute2-next 2/3] ip link: Drop cache entry on name changes Date: Mon, 7 Jan 2019 17:26:27 -0700 Message-ID: <4fb7c451-c9bf-4551-e713-e513a44e9efd@gmail.com> References: <20190107225552.8441-1-dsahern@kernel.org> <20190107225552.8441-3-dsahern@kernel.org> <20190107160650.16d956d0@hermes.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org To: Stephen Hemminger , David Ahern Return-path: Received: from mail-pg1-f193.google.com ([209.85.215.193]:36364 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726853AbfAHA0b (ORCPT ); Mon, 7 Jan 2019 19:26:31 -0500 Received: by mail-pg1-f193.google.com with SMTP id n2so892527pgm.3 for ; Mon, 07 Jan 2019 16:26:30 -0800 (PST) In-Reply-To: <20190107160650.16d956d0@hermes.lan> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 1/7/19 5:06 PM, Stephen Hemminger wrote: > On Mon, 7 Jan 2019 14:55:51 -0800 > David Ahern wrote: > >> +int iplink_parse(int argc, char **argv, struct iplink_req *req, char **type, >> + bool *name_change); > > Not a real fan of adding another by reference return value flag. > It makes the logic flow more complex. > > Is there another way? Caching in general is dicey anyway. > The details of the link change are buried inside of the req argument. It does not make sense to decode the message to see if the devices referenced by ifi_index == IFLA_NAME. The alternative is to just negate caching of ifi_index regardless of what the request is doing. If the caching only gained 5 or 10% we would not be having this discussion - I would not have sent patches. The gain here is significant and the caching aligns with the whole intent of batch files.