From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by dpdk.org (Postfix) with ESMTP id 238772C38 for ; Thu, 23 Aug 2018 11:22:59 +0200 (CEST) Received: by mail-ed1-f48.google.com with SMTP id f4-v6so462799edq.3 for ; Thu, 23 Aug 2018 02:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jLdP6TjNAPwxdCU1hJ7ujfSbPIu5g0Rc9POL4qXV0R0=; b=gAbJrO/ExLsj54YMJuBpFN+FzV8VFTgGyyMqwigztzxD9ND98D49qk+wvuj71yetUy d53639LgxcBrhSRIlJu4xdOenahKwQOUXqqoI1i5YCs4ALjn2P3solMmJ0lzYQMvmiNH PfJqNjlj9lDSRa8utpYXrAUInlGiII/jQ4v+m0cavBOAk1OXfc1eOf9OwLv3jACV+cBw p+KchHI16BQRo2Wx4Ynfih423d2bQFWqa73fm2jUrd1Lf3hTLDD9IT2bVUEAnVSY55PJ I/WeR9xBDNUjAZW0jIOBSny2yKlFbPl16DH0wDYv6rj8aum0t1i3AApu1KisxQqB8jKg pp5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jLdP6TjNAPwxdCU1hJ7ujfSbPIu5g0Rc9POL4qXV0R0=; b=FX+i/aPDeUVfEhejrbCMV88Iw8SCihNcqEua04ggQ6InoTIyw58Wf5TUWOtVhM5jDz nW4q7gwHc5WuEXAyI/TuneWjCJQmYF5uoxLfVEPxHCuwTSS331RgmxBrM5pAbWFlaS/G pvwuc4WteLDEmGe0Qjmk1KmBIUZy2yURVdLJTkrnOBkIzVIhQntltujZxbyCfrRsfAaf 0WvXq8G+15mMRYhj9uowh/MiSHLCAgAH20ib5kxb+evao2dVbDTiclI27OMohMm+Ymn1 y+mEuaDatsTcyBuxP+xMHtUMTOGvNrf8x0GtzA1n7hUkEwkAAnBB70TSGiYrR3LAxwQF K2zw== X-Gm-Message-State: AOUpUlEA/Cs1lQK+cVERjaYg/3DFCQXiGpbtIJt/2/dxuhN1L+VGKahB qhIMpEGdGm7mnvAVg/zSP2f5X4XBIXOtGaAEBd/HYA== X-Google-Smtp-Source: AA+uWPySlhTNownmC8sez21HRksnYXSEQywU2BuCH4DXiyO0SrzgnnCgrYF0Ogjuwf+em9JN6xjV7kZc3hfktH2yUdo= X-Received: by 2002:a50:b266:: with SMTP id o93-v6mr70147141edd.173.1535016178752; Thu, 23 Aug 2018 02:22:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:8bcd:0:0:0:0:0 with HTTP; Thu, 23 Aug 2018 02:22:58 -0700 (PDT) In-Reply-To: <6a63d8a4-f51d-b266-9877-73775145b52f@intel.com> References: <1531156496-1702-1-git-send-email-alejandro.lucero@netronome.com> <8ccb1427-34ad-be2b-26e7-11439798fb92@intel.com> <6a63d8a4-f51d-b266-9877-73775145b52f@intel.com> From: Alejandro Lucero Date: Thu, 23 Aug 2018 11:22:58 +0200 Message-ID: To: Ferruh Yigit Cc: dev , dpdk stable Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 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: Thu, 23 Aug 2018 09:22:59 -0000 On Wed, Aug 22, 2018 at 6:00 PM, Ferruh Yigit wrote: > On 7/18/2018 9:58 AM, Ferruh Yigit wrote: > > On 7/9/2018 6:14 PM, Alejandro Lucero wrote: > >> This is a patched to fix a functionality coming with the first public > >> release: changing/setting MAC address. > >> > >> 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 flag proposed in this patch is just the opposite: advertise if live > >> change not supported and assuming it is supported other way. > >> > >> Although most NICs support rte_eth_dev_default_mac_addr_set and this > >> function returns and error when live change is not supported, note that > >> this function is invoked during port start but the value returned is not > >> checked. It is likely this is good enough for most of the cases, but > >> bonding is relying on this start then mac set/change, and a PMD ports is > >> not properly configured for being used as an slave port in some bonding > >> modes. > > > > Hi Alejandro, > > > > Overall looks good to me, only it can be good to update > "rte_eth_dev_start" API > > doc to mention about affect of new flag and perhaps update release notes > "API > > Changes" section to document behavior change of the "rte_eth_dev_start" > API > > based on flag. > > Would you mind sending a new version for this release, v18.11, with above > documentation update? > > Sure. I have been on a large PTO break but I planned to send this asap. Thanks > Thanks, > ferruh > > > > > But, the ethdev library patch was late for this release, I suggest > considering > > the patch for next release, meanwhile it can get more reviews. > > > > Thanks, > > ferruh > > > >