From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 241A0395AE4 for ; Mon, 6 Jul 2026 10:07:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783332464; cv=none; b=ZYQ09veHeB318Q8cBCVb5DiF5NTpkasg9y/6hbGtNu3M32HZdD6DxKV7YRrkqYQo0LNxdaToHcILor6NY4JUI5KFRSYSjtPN4O48hm4QqrAAdmuXfQCl540z9p22ce8Xr0KQClJYmBL2CCa5dZm2Ccu8WEXPD4eTgSbPx+ZS7ec= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783332464; c=relaxed/simple; bh=JJUqDu2+dqGsrDoXsty0EwVEEsRe1/5oiBAXNjpKIlU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N3BWG1rkBSAWdGQOBi6o143+sZgHtabrm62EL1jv0pn1HQI+4h1iLJYHLSqcaoneT3lv6xlVLbfqBxMN03T8xWBmdWXfsosaFNx59KoXMwZ89wUsQ5ThQluEDrjN9Fhfn1RNHN++OYRuJsYAE0BG5ayT1G9TJ51DBCUKzkqXdPE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BS5Loq7h; arc=none smtp.client-ip=209.85.215.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BS5Loq7h" Received: by mail-pg1-f172.google.com with SMTP id 41be03b00d2f7-c89636920a3so1283002a12.1 for ; Mon, 06 Jul 2026 03:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783332462; x=1783937262; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=a1tEp0DM60rJuaNUtw2bTl3r+XcwQp5b/KdfASU4AAM=; b=BS5Loq7h02CqGhrydSsTzhjDnXe5gfxmnB0blHXNlkWH9Wx/6/U+mqO+jeIoi6MJgi osJtQAf6D0FTX1DI5bFTCTRd+cxKNhL0oJfIBLPu8cSN9WFfFFDgkrYbP2C2Cq0khtIu tMUuW8Fr4Fgvm7CDzbDw45DbTphfGOB/ucB8CTeHGTjWCH/4luYJgi73QAt9o1pjcSbV +pgKWVGi7siDOJu6MNy2ylapo/bMlY2v9WLn+SfwJVH3+pWx/9P/cKg6M/BnvFPu7UZ+ Ib40l1L1F17hwfTo5NpxP4TmCL5hRkdBXTTT/kTMCce7TTrtlkFaSEcGprtxj1fpEXy/ zzUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783332462; x=1783937262; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=a1tEp0DM60rJuaNUtw2bTl3r+XcwQp5b/KdfASU4AAM=; b=pwZhzqpAGiqrJu8tFmACX+yQF43Nt7rgjvxTWqwK2W6wkJN0Onge44gN4jDbxu9Xsc 4ElgZo4EZg1tx/uIbEddSSmz6cdpbqFEQVL6P4QQESjQQDH4kQZUdonu/xp6gzpI2f41 NFuC/i55FooHA9e5tE7p3mYp7vn9wKPgZQgsN4aHWTu54GhPFt7ff4BBJtQwmeHjkz5K gaw+WOsYUajlI+cgNFfDrPBXNY9DxI+soS/HjndQcte4aQ+33Fw6EbH8+gEfLnc7pgI+ 8c3fRVVzctkoJ37V32MQ54NIu/+7DU4lZGzF/V6a5QTetXUIafux4LqEzVB/ILNB4pqm gElg== X-Forwarded-Encrypted: i=1; AHgh+RqAQkGa28Y3miALuit3dgP+W1TINKPABNV8YZncGJdeRO2yXN9YgBivjnGHilolNEtXpcjGHDKy9o0zB/0=@vger.kernel.org X-Gm-Message-State: AOJu0YxZABDt6m2Z27qMfcbPj5T5kKw/pdbhYdkmEtZJxJvPrWowL6cI /vjng170fn2l/LXezr7p1FlzWH4zp01dG2xuZZi/4i3CQ8IEsTyzzj/R X-Gm-Gg: AfdE7cn78SZ/Zz8B4bUNL2StKpYcIZ736+kcgNsKknElceN502EJZs+Fi92rv9QwBSb FLbUJFfs9QLSWgHDIvmTwVoUjxWsMdTFpEatjkxxlz2DdWOhZ9UWc/CJDw/jgJdrTaE5i9cPZAP ChT7/z5fCyk1FA/lOQGpApq27KXNa8XJhu2FWs0jgQYgwvgvMF3+eMumagrLDDV+AURnTlHE/dH +LybiHU3CLnSEav0ogqHPwyAahyy5Ct7kkL+Aa7xMqdyK498TZYWyJCBb6nKgchkX/Wpy/Oipeh 1n494perUyYdyB0PyENZg57F5DN0Gf4Ak2YTxZ2JmGEWBQ63dSjQsnIZzFOllnHuHxX7nKgb+kq cZ2gwsoI357jTLWLgXUhsALYjedEMFyTTh6FVXz4xZf7v20GcxeyIpgnr+M1ABTJY+iSRkqj+rB gQTsA5yELcKqDCR6ax X-Received: by 2002:a05:6a20:2444:b0:3b5:489c:7bb5 with SMTP id adf61e73a8af0-3c03e50a96bmr9977640637.28.1783332462454; Mon, 06 Jul 2026 03:07:42 -0700 (PDT) Received: from amd.com ([165.204.156.251]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13b3c7fa33asm53276468c88.5.2026.07.06.03.07.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jul 2026 03:07:41 -0700 (PDT) From: Paritosh Potukuchi X-Google-Original-From: Paritosh Potukuchi To: Kuniyuki Iwashima Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kuba@kernel.org, edumazet@google.com, andrew+netdev@lunn.ch, jv@jvosburgh.net, davem@davemloft.net, pabeni@redhat.com, paritosh.potukuchi@amd.com Subject: Re: [PATCH v2 2/2] bonding: reuse neigh_setup from slave neigh_parms Date: Mon, 6 Jul 2026 10:07:35 +0000 Message-ID: <20260706100735.1852213-1-paritosh.potukuchi@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Kuniyuki, >The real user is qeth_l3_main.c only and it's not compiled >on 99% host. >We usually bail out at if (!slave_ops->ndo_neigh_setup), >which is called after your neigh_parms_lookup_dev(), and >there is no need to do O(n) traversal. >With 2K netns, it could incur unnecessary 4K traversal (lo >+ another dev) for each neigh creation, which is done under >RTNL or from interrupt context. >So, it will be a problem. That makes sense. Thanks for the insight. >It does not help. Just populating fields does not change the >loop detection logic. True. Just populating fields would not suffice. Do you think it would a good solution to modify the ndo_neigh_setup function? Currently it takes a (netdev, parms) pair as an argument. The way the ndo_neigh_setup is being used , both in stacked/ virtual devices and slave devices, is to expose the underlying netdev's local neigh_setup function, through the parms argument. There is a TODO in the bond_main.c file that suggests the following: /* TODO: find another way [1] to implement this. * Passing a zeroed structure is fragile, * but at least we do not pass garbage. * * [1] One way would be that ndo_neigh_setup() never touch * struct neigh_parms, but propagate the new neigh_setup() * back to ___neigh_create() / neigh_parms_alloc() */ As the TODO suggests, would it be a good idea to modify the ndo_neigh_setup function to be able to return the netdev's local neigh_setup function. This would solve the problem of passing a dummy parms structure. typedef int (*neigh_setup_fn_t)(struct neighbour *); static neigh_setup_fn_t ndo_neigh_setup(struct net_device *dev) { return qeth_l3_neigh_setup_noarp; } Though the problem with this approach is that ndo_neigh_setup loses the flexibility to modify other fields in the parms structure. What is your opinion on this?