From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F690C433EF for ; Wed, 25 May 2022 15:19:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241850AbiEYPTj (ORCPT ); Wed, 25 May 2022 11:19:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236085AbiEYPTi (ORCPT ); Wed, 25 May 2022 11:19:38 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 440881403E for ; Wed, 25 May 2022 08:19:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CE4A0B81DDA for ; Wed, 25 May 2022 15:19:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A67CC385B8; Wed, 25 May 2022 15:19:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653491974; bh=I0GBiumw6VdUPgUOGLUA+7POQ46FYz4nedxE8B5qmhQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lqoOLivuf+0elic3aynjRTGxhOoE1V9PZUI6SSYFMMQVpavWvUD+6r7tBRmYHi0gf b/k5sECKgxuDsMlZMIO580M8k28iuo6rAtMIt2m03j1m9hg8/wVenqx3yTy9NGS2GI gSSJr08ALFqWDYabJE0dupwKq5O8YmidgP8lU/W7jFM/W/nhpTBmdc6KZHcM26jybl rHS5wZkii3Cn3SrFhSHVipk2txXvGY6GAADvBvQqcL5W8gfKPkYIyNK0DMUzwjkR/r 9O11YN+fZgmTQ6qATCSl9eaTzxqHDCE5MWQUD5F2ntgeBIiKiLXfiTuyeQ/lZsRVOJ KleK5dTyc+ewA== Message-ID: Date: Wed, 25 May 2022 09:19:33 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH v2 net-next] net: neigh: add netlink filtering based on LLADDR for dump Content-Language: en-US To: Florent Fourcot , netdev@vger.kernel.org Cc: Eric Dumazet , Daniel Borkmann References: <20220509205646.20814-1-florent.fourcot@wifirst.fr> <8653ac99-4c5a-b596-7109-7622c125088a@wifirst.fr> From: David Ahern In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 5/24/22 2:49 PM, Florent Fourcot wrote: > Hello David, > > This patch has been marked as rejected after your comment. > Could you perhaps have a second look on it? And on my response above? I > still think that my patch is relevant and add a currently not available > feature. > > I can work on alternative approach if necessary. Since neighbour tables > are sometimes huge, performance overhead of userspace filtering for a > simple MAC address lookup is currently high. And GET does not provide > same feature. > Kernel side filtering has always been kept to simple, coarse grained checks - like a device index or upper device index. It's a fine line managing kernel cycles holding the rtnl vs cycles shipping the data to userspace. e.g., a memcmp has a higher cost than a dev->index comparison. I see the point about GET only - potential for many matches and a lookup of the ll address is basically a filtered dump. Mixed thoughts on whether this should be merged.