From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 734755F0D for ; Fri, 24 Aug 2018 16:46:30 +0200 (CEST) Received: by mail-pl1-f194.google.com with SMTP id s17-v6so1190356plp.7 for ; Fri, 24 Aug 2018 07:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=WmnSHU3HBqq+79oxXffq5oA1L1saZiA1A8zlJchhVDk=; b=0O2+TYFLRj1NL/lfRkm9I1grrCS6cixXcOgxOrCiLRBpWtJFZIl0NktW1Txg1GAfvE NKMPi7iZZhmm7rnSURT2GD5/c7Jkgb/0ZdLb13N0l+aBPdw1uNu/2659SREKUNKmPaDt 2Picj2g8O5u5HF6fBMJBQE8rU5uspDDKrbm0s3fDT2DxvQJWhPmaWR1l0V+B6lblEAX0 ipSRGXFwpyxg22W8/4NC3JlDXZTIXJlEbGkvsBb69FKNvJIgGr98T9g2hj7vr1GUvKZN ADlE/HsdbTbtM1ItzQUZR//cel3eJBypGprkuR32OKJIWfsD6QHZZ8tn5HToG5mkSDr/ Y9IA== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=WmnSHU3HBqq+79oxXffq5oA1L1saZiA1A8zlJchhVDk=; b=qtFJEtYUoGT9uS3ZfAjO/0ZPn5gLULhHB5S3jukuBENqgTG3gmkrMR7z+Ry72btNAW dW5TbWHRmDkvQ25Md1SWqkGgLtvsPelvfWiRl09cMpO+Lk2+DM5kwvPzSii/qHUU0L+9 jGG2JQDS8XghvpaONf5MC3jnLJ1KR/W6GXrV2XaPd4Bmrom0+ORp6jrd81kyLvgXBzBA n4u/ouweJEpCwWF2203NvRVJDPr3X5XWrXnazTbjIULji3LNLQXjKSmpaT2Oa1Yi4/ao z5P7nMNOcFniScIEmLlenWysCkjPBJS1UN6oMgye7e4LPzFxZjmBkzovpcyGZM12U8wr ZeEw== X-Gm-Message-State: APzg51B7TCE24s41uUwLpgP7ETqhe2ph5Ho/PddHY9IYtf3NERO5nc5M wbMlDkpAZbQFf7x5vXhvi+WIalJNt0x5hQ== X-Google-Smtp-Source: ANB0VdbqYa1wvFgcV5T7Yq5WyTkZehn/o1XJq+/KICACv4ZWBtSEvs9UNQsPfXl6uqtWBEXMT7rKWA== X-Received: by 2002:a17:902:934c:: with SMTP id g12-v6mr2012535plp.67.1535121989675; Fri, 24 Aug 2018 07:46:29 -0700 (PDT) Received: from xeon-e3 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id z22-v6sm12500623pgc.67.2018.08.24.07.46.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Aug 2018 07:46:29 -0700 (PDT) Date: Fri, 24 Aug 2018 07:46:27 -0700 From: Stephen Hemminger To: Alejandro Lucero Cc: dev@dpdk.org, stable@dpdk.org, ferruh.yigit@intel.com Message-ID: <20180824074627.3415e05b@xeon-e3> In-Reply-To: <1535120736-785-1-git-send-email-alejandro.lucero@netronome.com> References: <1535120736-785-1-git-send-email-alejandro.lucero@netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3 0/2] support MAC changes when no live changes allowed X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 14:46:30 -0000 On Fri, 24 Aug 2018 15:25:34 +0100 Alejandro Lucero wrote: > The original patch assumes all NICs can safely change or set the MAC > in any case. However, this is not always true. NFP depends on the firmware > capabilities and this is not always supported. There are other NICs with > this same limitation, although, as far as I know, not in DPDK. Linux kernel > has a IFF_LIVE_ADDR_CHANGE flag and two NICs are checking this flag for > allowing or not live MAC changes The semantic in Linux is different than what I think you are trying to do. Some devices can not change MAC address at all because of hardware or hypervisor restrictions. Other devices can not change address while device is up (started in DPDK API). With Linux the policy was to assume by default device could change address while up. And then let a few virtual devices allow it.