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 DD41BA0545; Wed, 10 Aug 2022 21:39:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CE0B54068E; Wed, 10 Aug 2022 21:39:45 +0200 (CEST) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by mails.dpdk.org (Postfix) with ESMTP id 244984067C for ; Wed, 10 Aug 2022 21:39:44 +0200 (CEST) Received: by mail-pf1-f180.google.com with SMTP id p125so11058376pfp.2 for ; Wed, 10 Aug 2022 12:39:44 -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=LjEG+0ojU5BJOHKRBfaJ4iKZTYXpmh/ir+SOEXfDKVc=; b=pRMCpCbusRXLIEAqcG1H2oqvJbmI8MnOa1TDlkvgy+vp5gPeznWnSXQMTJpsOI/VO5 IIdtIPGhgKwRWA8Q5iwz1HOLMyn2YARDj0vUUvk2zr81d5+TpRpeZwBft1dPwRfLfQGI 2u8OEZHWdh8RmN8DCv8WDpGV1/Zz8HRbpRXGOdqgs3fnyuJ5srvlyl2EqLvZp25/rj6h bjN7q+b660f/Tq35IRb46T8KWSoIaXK/q9FN5hLYp0TUBtjT4IEvGJRq/x6ixF4CLJNQ B8p59LRnSfkpHnd/h5c7JufAYsfh6/pgZinnxYflNGbuhuUxicu7m3Gk8UNtZgsHUYcG nnwQ== 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=LjEG+0ojU5BJOHKRBfaJ4iKZTYXpmh/ir+SOEXfDKVc=; b=TZi1GM5VRwvvTlY+5XiorGQpS1oWwp1UwC4E3g5fCMKumJ3ejynMkshZ2AGcs6Xeaa zmE/2TDEEN2eaIanoOIwXBzMP984uga61l97g0YAozWaE7rK5YXpcilxMk5pPSkmtc7L jNhwEmBgx7CgqpXsPM+T7jDOaWHdd3n/GulYbUD3KBvo8D+JKavesVZCHe5zhPQpoPlB xDlx99W4rhtOXBIKx6ZC1XoNjpPpf7CODuS70bjyrdeNEtVNbVejNRrDCkMWHAvjTzkL sSsqotepiY+UVIS9+NdXmIbiWGhN360DzobzK7vKfXbqU+PBPvDZWnr2DyOvxhkgvCPZ hs9w== X-Gm-Message-State: ACgBeo0fhdaGWJ8wh3jcTAI70BCk6l1IX6Q+X9aFmPFdicK5ttb/K9NW GusgJk33XaUcgnY0X0okODNiDA== X-Google-Smtp-Source: AA6agR5+YJ/Y/0l9Vdo7o6XKCxCPw696TKvK3TxWIE3lZO2WlN3tGIECCH5ndyJkXfBy2wJutXbfXQ== X-Received: by 2002:a05:6a00:2195:b0:52e:6157:904d with SMTP id h21-20020a056a00219500b0052e6157904dmr29006032pfi.44.1660160383318; Wed, 10 Aug 2022 12:39:43 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id l37-20020a635b65000000b0041bcd8f3958sm10135743pgm.44.2022.08.10.12.39.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Aug 2022 12:39:43 -0700 (PDT) Date: Wed, 10 Aug 2022 12:39:41 -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: <20220810123941.0c35df8a@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> 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 Wed, 10 Aug 2022 01:51:55 +0000 Chaoyong He wrote: > > On Mon, 8 Aug 2022 11:32:30 +0000 > > Chaoyong He wrote: > > > > > > > + goto done; > > > > > + > > > > > + /* Allocate memory for the eth_dev of the vNIC */ > > > > > + hw->eth_dev = rte_zmalloc("ctrl_vnic_eth_dev", > > > > > > > > Why not rte_eth_dev_allocate()? Isn't an ethdev? > > > > Why do you bypsss ethdev layer in this case completely and do > > > > everything yourself? > > > > > > Here we created an ethdev locally to nfp PMD, we want the user totally > > won't be aware of it. > > > If we use rte_eth_dev_allocate() to create it, it will be in array > > 'rte_ethdev_devices[]', that's not we want. > > > > Having a floating ethdev does open the code and users up to a number of > > potential bugs. > > What is the value of port_id on that ethdev? What is the mechanism to > > ensure it doesn't conflict with other ones in the system. > > 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?