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 73B465F17 for ; Fri, 24 Aug 2018 16:46:30 +0200 (CEST) Received: by mail-pl1-f194.google.com with SMTP id d9-v6so1194038plr.2 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=jdBr0bw/suwgWC3yM4J4RyL77SHEM1bLg/lfk1SYo7djX33z5EIF2tkeIsWZkB+cPN wcie9BeT7BZXT/8l8psQY6Lw4tkWT3/jlryvOo/0/KSw0sxVzK9yXol6jV4660QJRgf/ 9K+rE3ALL4lcBV2SbykB/DV7+Z6QcdSYfN3gTouQyfOEsU+tAXu/kMe3PtHVrLvpJeg+ 8G2ixp58vjGJKCRuR/2Cf161F3mv/B8F7XSiwjzDI9DKvlsAISujpZ3SEQnmyEJRKEce DX8R1RXWPluUfdC+n9APBtFjNU0xcrBpLR1vSxsUU6J02q9Q7bNvqxP8SNUfgvx8gqc/ 3SKw== X-Gm-Message-State: APzg51CbKoiqs2oce8HZdtPRy2oAC3BcnyxMNGQpIaqHfx/w8vW2E9xx hRkRbGrY6lh3j6Duyh1clrV1RQ== 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-dev] [PATCH v3 0/2] support MAC changes when no live changes allowed 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: Fri, 24 Aug 2018 14:46:31 -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.