Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1773171imj; Fri, 8 Feb 2019 07:09:19 -0800 (PST) X-Google-Smtp-Source: AHgI3IZLqfBmGCHppAGtyVJORkKSkw7oGro16wMXvmp6R4ELOaoJyYi1C7Gp0o4Bg3ZM4a/91oC3 X-Received: by 2002:a17:902:aa8c:: with SMTP id d12mr23500931plr.25.1549638559386; Fri, 08 Feb 2019 07:09:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549638559; cv=none; d=google.com; s=arc-20160816; b=BuNdIo6lfnNcwVB7ukYSmROlh9hSDFy9AhAU3aQebxXdwF949lim/Rgo4O1wLvjI8m KFLswOwoFuL88qe7AjeJvSmrHzZDHa5WLuTo+pk5YV6igT+e7YhdLuiptraL38s0R2Yd LJLre4M430BcUkXXtSLACp+SAdyppnR40fuhhcDEPxdskmVuzHcg29F7YTQmzjPi7j1V q612x4/Mp0iHq4pYQjoUP4MW96hK9epmSvf43M9+JD7EnLkjippkafoj5t24yKw7RjaU a1ilt7I7lAypf+KdK61mxqIBsIchLoikXqNUnrCPNp5mB+KBTifKKs3NkLbldbXTEWH2 Ci0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:to:subject:reply-to :dkim-signature; bh=MdwmXtBvXwxENwVSPhAmdv3MbAQ3fWK3xZrpSPz9OTw=; b=EYQfPVKk3VOvRbTjkd6iQ3vvuGy3bj3cKxYXTFcRJDfHc/CWSHC8inRrxgHFJPC0vt k0q62X6YQCYG+Zq+s0DjoBDVkiycqYLq6rbW42TJmVVPRmI3xAZMGWYPA6KCezMuYXZo BxOz5y6rRTEnj1H+qlWi49dsm3PqwInf3h/9m5EAkFRGua5OZGpJILZekyvt3ELog+Zs NmNkaTWKExoboQ0C7g9z9YGwBioKNkxWSvENnJeAsGP8YwGV+Aqa23lAmqVpBBe2VDBe 77HtVnxoVUdFUWvF/gy2HMONUVgtUfTpaFvu2YUz0tWeSPvNMJ9zBppG9goDJA6jdqVB EkGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@6wind-com.20150623.gappssmtp.com header.s=20150623 header.b=F+hh66Xs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i8si2324124pgo.273.2019.02.08.07.09.03; Fri, 08 Feb 2019 07:09:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@6wind-com.20150623.gappssmtp.com header.s=20150623 header.b=F+hh66Xs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727934AbfBHPIq (ORCPT + 99 others); Fri, 8 Feb 2019 10:08:46 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:34575 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727479AbfBHPIp (ORCPT ); Fri, 8 Feb 2019 10:08:45 -0500 Received: by mail-wm1-f67.google.com with SMTP id y185so7014411wmd.1 for ; Fri, 08 Feb 2019 07:08:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=reply-to:subject:to:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MdwmXtBvXwxENwVSPhAmdv3MbAQ3fWK3xZrpSPz9OTw=; b=F+hh66XsBOVJmvqUjgH+KVTQ3SgEanf1/sUXqYrvSymMIrEW3gRpENXFjJheIHqjb4 mW8zgKHf5lNNMINzAxCFY/0MBlvzIiVFZngD5Dby72Yho71FZ8lur0AvRFq5wK2phhU1 uL1v/A5Ow95TY0YcTK7AdY3ERF2va2P1gsh6HFVf+eao6s0UwQjAqCUfw3JmNCqTiS81 wlxm3qmPMUcxyRte3X4rrvgMMTV7oHpYNQQu2hfP+uI2FJjz19ZQvD3EzeEQkkqB9qd1 yGthxAAGLel69LceWAy0MuamCtHeEcmkNz68GSBiegvsgHF9/0MyDCKGjWiiLQgFLMVh ZNtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=MdwmXtBvXwxENwVSPhAmdv3MbAQ3fWK3xZrpSPz9OTw=; b=Y0zLqWiPx2YeYyYx91XGXojFG3snHr1pRgTUxtBwzoj1I4J7uvpJoclrqQK3lU7w2+ iHrCcNI4/GuCEAv/9rTDXZmaTOj16rFBHFxyg6ONd2iJpQl4rb0l7VxDnTdefXCnyUVJ aon2IluNBZTlHoxDA+3Ztb4X3qgOe1nEw8DsHJshLqOFjSREFY7eDm0AkKT3oVRWPLYl F6uiNVRGa+l69lwQSTFLLjrvGIJPky/TwMmBqOUH0L1wFE1tXygeLWcNolbL52dFs5Dl UYPnM2TqygvOzS3RoMCUWVaZ/oFMB1u59w23CdkQkTJ37kbbsLdaZcn1CGSCK9tVN49b 2Y5g== X-Gm-Message-State: AHQUAuYSSxbom2iIcMIAKHd+3NP4lZ1NghZeOtp7J7TDYtoZ0jVQeBeD MyzIQZ1Q/45Wqsx6pNeVZcdT4Qwh3AU= X-Received: by 2002:a1c:f218:: with SMTP id s24mr12617777wmc.6.1549638523652; Fri, 08 Feb 2019 07:08:43 -0800 (PST) Received: from ?IPv6:2a01:e35:8b63:dc30:a891:eeb0:d9a7:6bd2? ([2a01:e35:8b63:dc30:a891:eeb0:d9a7:6bd2]) by smtp.gmail.com with ESMTPSA id t199sm39832132wmt.1.2019.02.08.07.08.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 07:08:42 -0800 (PST) Reply-To: nicolas.dichtel@6wind.com Subject: Re: [PATCH net-next] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs To: Nikolay Aleksandrov , Callum Sinclair , davem@davemloft.net, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20190208041103.31299-1-callum.sinclair@alliedtelesis.co.nz> <20190208041103.31299-2-callum.sinclair@alliedtelesis.co.nz> <5597e8bc-c23e-1f59-0442-260a7b4ca83d@cumulusnetworks.com> From: Nicolas Dichtel Organization: 6WIND Message-ID: <31a5155c-ce6e-4c0f-61c0-35a5472549aa@6wind.com> Date: Fri, 8 Feb 2019 16:08:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <5597e8bc-c23e-1f59-0442-260a7b4ca83d@cumulusnetworks.com> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 08/02/2019 à 15:43, Nikolay Aleksandrov a écrit : > On 08/02/2019 16:18, Nicolas Dichtel wrote: >> Le 08/02/2019 à 05:11, Callum Sinclair a écrit : >>> Currently the only way to clear the mfc cache was to delete the entries >> mfc stands for 'multicast forwarding cache', so 'mfc cache' is a bit strange. >> >>> one by one using the MRT_DEL_MFC socket option or to destroy and >>> recreate the socket. >> Note that if entries were added with MRT_ADD_MFC_PROXY, they will survive to the >> socket destruction. This is not the case with your new cmd. Is it intended? > > I think you're referring to MFC_STATIC entries (sk != mroute_sk). It > doesn't matter how you add an entry - they all get cleaned up if added > through the mroute socket. Yes, right. MRT_FLUSH_MFC_STATIC ?