From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 901894C8F for ; Thu, 22 Mar 2018 11:29:20 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id 139so15126648wmn.2 for ; Thu, 22 Mar 2018 03:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ftjs5dblYEKKZPk0j/VDwtQ8wT0dCXpq3sO0z1RPTgA=; b=e54lR6n83DSvzVjus94G0T/5/12Ee6KfBFRSk1uiF8WUoHX+umnDy5WWNbSdj7jgwK ClysQKInxfwc7DB/JW4RDYkAwuirAS65h6PYdM5eF7GUWQsjXnlxl4sOYXnscD3uy4qw a3CzCj41kP/DAcN5mXSe8xlgR03rv6ex2a+Edjb1jnF0qSwsxp98xv+c7vAdztcvHmg7 VHYuAGEzzpKaxIx00++uembCORCEWEkkyFBBzzoEFea80A1JQr5GtRuP+2FXxEq8RyVf IfiFecQ0ZjRG/UFFk0Izrfbvqr7GuJ5/SbR35eUz5ffOLx73OouB1mkyfRo+uRzSjk5/ /WwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ftjs5dblYEKKZPk0j/VDwtQ8wT0dCXpq3sO0z1RPTgA=; b=HGtMCBVyQg/m4hnHpcJfp0orrtc0R/3drLY3shfSV4zPlRNTkp1mK74bo38IIQmjo2 dQGajqGVjXgNjACGhuz0akLMOI7eOajM2o4/OFOaR3QevTvLvDcSveVKZp4IBzLRfNjj zAlcyM4s+68Q/lJtZHl/DVTnB7J56MjbHUSVtM/hUaUDZIfWYrvKzLRuD+sTl9k+K6Fe RDl6BkOCG+cr9VI3T9x6hrl0jVqWvQ3FvdbBNi2IS4koAnxDH0zcIOkPKZPCIGdFLDbP 5F9FaMKQqupJ8S2GZ8Cdej9AM2AsAs9g97gGXpp1sJHxgWbizswu/uqXU0X1ZxIHDDr2 mBLQ== X-Gm-Message-State: AElRT7E5Ns3AEgusGs/BOHWo2idmuxcXo1LcvHF8qCeZIjHlmRV0v88+ nK3utHWTkCuXGzjjk1+QhHEB X-Google-Smtp-Source: AIpwx48x7po3KMf2e50M008C7SeaaJkqL8kGHwF/e3aqVt3WbVnq5bL+yNprrimHsvS+gElsqxhetg== X-Received: by 10.28.52.83 with SMTP id b80mr2366268wma.90.1521714560253; Thu, 22 Mar 2018 03:29:20 -0700 (PDT) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id r71sm8663990wmd.48.2018.03.22.03.29.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 22 Mar 2018 03:29:19 -0700 (PDT) Date: Thu, 22 Mar 2018 11:28:30 +0100 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Shahaf Shuler Cc: Adrien Mazarguil , Yongseok Koh , "dev@dpdk.org" Message-ID: <20180322102830.x7rdaywq7t3c36ma@laranjeiro-vm.dev.6wind.com> References: <20180322090445.63pcs6jwljdob6pi@laranjeiro-vm.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v3 1/3] net/mlx5: use Netlink to add/remove MAC addresses X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 10:29:20 -0000 On Thu, Mar 22, 2018 at 09:45:16AM +0000, Shahaf Shuler wrote: > Thursday, March 22, 2018 11:05 AM, Nélio Laranjeiro: > > > What if the DPDK process is terminated ungracefully? I think the MAC > > > table will remain with all the MACs which were added. > > > The next run of the process may have un-expected results. > > > > > > Should we flush the neighbor mac table also on probe to make sure only > > > the VF mac exists? > > > > In such situation the sysadmin should make the clean up, the DPDK > > application cannot consider it is the only one using the device as it is not the > > case, Linux still owns the device. > > We have no guarantee the admin did not use another MAC address for a > > service outside of the DPDK application (even if in such case he should > > disable this feature to fully control what happens on the neighbor mac table). > > There should be only one owner for the VF mac tables - either the DPDK or the Linux. > > If the DPDK is the owner, it should do the cleanup. If the sysadmin > wants to be the owner then it should set the proper flag when running > dpdk or alternatively not set the VF in trusted mode. It is a little more complex than what you think, according to the Linux configuration the tables will have entries already present or not e.g. broadcast v6 is present only if the Linux supports the v6 (by compilation or configuration). For such reason the PMD cannot consider it owns the bridge tables when acting as a VF, otherwise it needs to trigger any Linux configuration modification and enable the according functionalities. To answer this: > There should be only one owner for the VF mac tables - either the DPDK or the Linux. That's right, DPDK application or Linux should own the device, the PMD is none of the two. It is just a driver. Thanks, -- Nélio Laranjeiro 6WIND