From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9BAFAA0548; Thu, 11 Aug 2022 17:07:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3D303427F2; Thu, 11 Aug 2022 17:07:54 +0200 (CEST) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by mails.dpdk.org (Postfix) with ESMTP id ADA8E410FC for ; Thu, 11 Aug 2022 17:07:52 +0200 (CEST) Received: by mail-pl1-f177.google.com with SMTP id p8so17115825plq.13 for ; Thu, 11 Aug 2022 08:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc; bh=lnjl+kLt2N701RUZJ45ic/TpbaNIUZGNK/vshCVJXeg=; b=MSulrCyZ3bY2ALdaAqqNTa/6PTMj6/Aev/awV/vRstCltHNyjqImY+C+9M+zm3NQkS BupHLq2TFkkBYfzdrM+1ki1v0kUBDEJy8sv8FkX2PH20zlK0y2MOPc5VNOVkFqcBhfCo v+rDDKYpqXPrDcvwQw1wUy7dBugWyixMyiMgMnnSK0TPuhNKr4bsXvD1I3uSWihnTQIS sdo2G+2C6WyPhMB2H/SB34CtktElV0Q2KtFPjoY1hERmxkE+BRh0ntAf7NkIIh3B6OT8 TzpHRzTG8vuck8v9+z3V/J0tOCiS6ESj24IUDFt477kzA84/Bmi8GrCeLi/n+9HhRKkY DPRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=lnjl+kLt2N701RUZJ45ic/TpbaNIUZGNK/vshCVJXeg=; b=4mijVQzsdLksxHmC7Mh4KrlT/qnQecPHNs6F0LnGA6x1A//hsEuMC41pX6SoZIjWEr VQYaW1Dr0EUDXa0Fbjqub4I440CGNSNV7wb8SSpkkwQd994uDicVeMKh5iJn/yq1X1Pf SoE8O30K8mVPLyZ3bKAO4sGTnimOhd0FF0nKoAZvQAfxDB3USFtT59DpCz6BI50Xjwmr o21lDAPDvORQRBYJaZrhjC8D6XLQbOFsJofgDTCXhzeANJlU7OENRwwMQ679soPA+xPV Ai6mHuYKrOovdzcuQg/kFE3RDX47+j9zE75/xe57QVqw7NU2hY1SBSeUy5Dhn8S1UWQU +emg== X-Gm-Message-State: ACgBeo2KPphf4iIjfceKGeCxjTTU8BKNifOBWmapx08PKWSXLQDJUydO vloPSemDsxK/phh7TVXHBXXa4/b18YOljA== X-Google-Smtp-Source: AA6agR5nNquqrWTMnS9XBSFG+i9ValMEIczh9DkvZI70zU/TyTZ7xagAJmMONTvG1KDs+/GroIuKQw== X-Received: by 2002:a17:902:f650:b0:16d:473b:903b with SMTP id m16-20020a170902f65000b0016d473b903bmr32200607plg.174.1660230471716; Thu, 11 Aug 2022 08:07:51 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id 6-20020a170902c10600b0016b81679c31sm14927645pli.213.2022.08.11.08.07.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Aug 2022 08:07:51 -0700 (PDT) Date: Thu, 11 Aug 2022 08:07:49 -0700 From: Stephen Hemminger To: Chaoyong He Cc: Andrew Rybchenko , Niklas Soderlund , "dev@dpdk.org" Subject: Re: [PATCH v5 07/12] net/nfp: add flower ctrl VNIC related logics Message-ID: <20220811080749.5bdf2c8d@hermes.local> In-Reply-To: References: <1659681155-16525-1-git-send-email-chaoyong.he@corigine.com> <1659681155-16525-8-git-send-email-chaoyong.he@corigine.com> <20220808074542.31b7185c@hermes.local> <20220810123941.0c35df8a@hermes.local> <20220810212451.35f8b0ad@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, 11 Aug 2022 06:31:31 +0000 Chaoyong He wrote: > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Thursday, August 11, 2022 12:25 PM > > To: Chaoyong He > > Cc: Andrew Rybchenko ; Niklas > > Soderlund ; dev@dpdk.org > > Subject: Re: [PATCH v5 07/12] net/nfp: add flower ctrl VNIC related logics > > > > On Thu, 11 Aug 2022 01:26:49 +0000 > > Chaoyong He wrote: > > > > > > > The 'port_id' is the 'Device [external] port identifier', which > > > > > related with the 'rte_ethdev_devices[]' I think. > > > > > Here the ethdev we created is not exposed to the user and is not > > > > > in the > > > > 'rte_ethdev_devices[]' > > > > > array, so it can't be invoked by the user at all. > > > > > And we invoke this ethdev through a pointer in the `struct > > > > > nfp_net_hw`, so I think there should no conflict with other ones > > > > > in the > > > > system. > > > > > > > > DPDK already has a port ownership framework to deal with internal > > > > ethernet device ports. Why was this not used? > > > > > > Sorry I have no knowledge about this framework before. Any document > > > link or logic about this framework will be greatly appreciated. Thanks! > > > > It is part of ethdev https://doc.dpdk.org/api/rte__ethdev_8h.html > > > > See rte_eth_dev_owner_new, rte_eth_dev_owner_set, etc > > https://doc.dpdk.org/api/rte__ethdev_8h.html#ad6817cc801bf0faa566f52d3 > > 82214457 > > Thank you very much! > > If the app uses the rte_eth_dev_owner_* APIs to check the ownership first, it does can > protect the internal ethdev ports. > But right now, the ovs-dpdk seems don't use these APIs at all, and it can use 'port_id' to > get any ethdev port in rte_ethdev_devices[] array. > So maybe it's a good idea to keep our original logic and keep an eye on this area, once > the ovs-dpdk use the rte_eth_dev_owner_* APIs, we'll update the logic here accordingly. > > Thanks again! Once device is owned by something, then it is no longer show in the FOREACH and other iterators; so ovs-dpdk should be ok. This mechanism is how bonding, failsafe, and netvsc drivers handle sub devices. Therefore OVS should be smart enough to handle it.