From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by dpdk.org (Postfix) with ESMTP id 1F507293B for ; Thu, 23 Aug 2018 11:22:59 +0200 (CEST) Received: by mail-ed1-f54.google.com with SMTP id b10-v6so3157983eds.4 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=aVQ4CLPipYPlBVqPo5T+rpjGAp/xgq3vTrWtPluBgsOmF/+LWq1WnfNoWDBkI5hmOs IyXHl49qHOis0QTsnFY+aMs2UPJXZVuWBZIB60DsZy9jt+HHVPdpjzhbaxqln4sswQvO emxi5nn1aMggLW5KRN1poIpQn0siKWs+xLYP9QbXrfFBvZiDiwMLIAtWAIQKScQ70FYU qrej0b+PkLeuw94V4YDmieciW5RPPxdHok0NgjRdyTkIff+FxsHVACOzi/L/k0bwDP45 mXNBtFjCOmXb3z9zcNxnBJRzcENeVe/3x8XiZRY74zCnqcZMhQjhOw3097fHrtGF4phk EJ7g== X-Gm-Message-State: AOUpUlGIGHMKXvhLpesdrrMLnR+5eKCxkUFGUI56sy1/ctRSC4aqQNIh 8FCOjcNnu9jEE6QOw2mcm5RjfrdqadTS2z9XlrK1Rw== 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-stable] [dpdk-dev] [PATCH 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: 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 > > > >