From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2A364A00C5; Mon, 6 Jul 2020 16:05:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 005661D990; Mon, 6 Jul 2020 16:05:05 +0200 (CEST) Received: from mail-vs1-f65.google.com (mail-vs1-f65.google.com [209.85.217.65]) by dpdk.org (Postfix) with ESMTP id 8E8831D5CD for ; Mon, 6 Jul 2020 16:05:04 +0200 (CEST) Received: by mail-vs1-f65.google.com with SMTP id k7so19293124vso.2 for ; Mon, 06 Jul 2020 07:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K2Uq0avXdZEvOHWtB9XE6t028Km9l3FbHUF3O07ZCRQ=; b=cFJAPRI5V+6BeDfc2vKrO1NKkiadhKRnZL7sg45K9gb/gU78JqUks6o1Yg5jKC9dBx 6HiHxBGvmL/9cwcMMpLn2osCE/x9IjpfnTXr8hzB0tpkf6mj3zSTNoFtgk2wxbyD5lFm Nx1WLAzhb7hd4xVVcWvhEJthg7gg3bMTTOV7w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K2Uq0avXdZEvOHWtB9XE6t028Km9l3FbHUF3O07ZCRQ=; b=NYYm0h2DsNQ2zve2GrgU4lhE6bEYFDZYKpCZqQkufICniwoHFhUFRDRjrnUvjabhrI oioNi+/lh3r+vBiPaFd3wclWjW0SL67iYLGq7XZ6OQpGqKPem+Be41Mq1D1ZTdSmLyio gs0VufDl1FEQeVKoBHIVdvrFZNjhLrLBa/ac9YjGsMCON879cwqTzwhnbm4PO4XjFgIW s3rbHM5Vbio3Yp0obglwToxTbXhM+vdhN2HSTMvgfUG13RVwKbJmNLNUkJvobnE42N6H DdayFsCRw6ay1Wu24pumsMjly6RQz7j5ZNLVUNzrny3D2Xb2d47Ka56VpkwcWwE2ZO8q bQqA== X-Gm-Message-State: AOAM532E7F0jy8ok51GEJsb+Ffv6CNXXAXeCGtnGMfJ3kdg0WPEZ/KUL m73w45zQLgWYK+rFHy/eGmDhMqtJMEXXnlQJD1mHbA== X-Google-Smtp-Source: ABdhPJx1bwvZ5UYu7YIAClwnf9olhkM9nHGkO9AxlcgZzGj6RJ9Sb9EeCt0q7LcYmM/QyvdDOEbCyWJu6YJrROXfKj8= X-Received: by 2002:a67:fd53:: with SMTP id g19mr20828972vsr.187.1594044303809; Mon, 06 Jul 2020 07:05:03 -0700 (PDT) MIME-Version: 1.0 References: <1f5421dc-0453-6dc8-09c2-ddfff6eb4888@intel.com> <20200703210210.40568-1-ajit.khaparde@broadcom.com> <20200703210210.40568-2-ajit.khaparde@broadcom.com> <6b41ef2b-4203-78f6-dcd9-013f770c7d88@intel.com> In-Reply-To: <6b41ef2b-4203-78f6-dcd9-013f770c7d88@intel.com> From: Somnath Kotur Date: Mon, 6 Jul 2020 19:34:52 +0530 Message-ID: To: Ferruh Yigit Cc: Ajit Khaparde , dev , Venkat Duvvuru , Kalesh AP Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v5 01/51] net/bnxt: add basic infrastructure for VF reps 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Jul 6, 2020 at 3:37 PM Ferruh Yigit wrote: > > On 7/3/2020 10:01 PM, Ajit Khaparde wrote: > > From: Somnath Kotur > > > > Defines data structures and code to init/uninit > > VF representors during pci_probe and pci_remove > > respectively. > > Most of the dev_ops for the VF representor are just > > stubs for now and will be will be filled out in next patch. > > > > To create a representor using testpmd: > > testpmd -c 0xff -wB:D.F,representor=1 -- -i > > testpmd -c 0xff -w05:02.0,representor=[1] -- -i > > > > To create a representor using ovs-dpdk: > > 1. Firt add the trusted VF port to a bridge > > ovs-vsctl add-port ovsbr0 vf_rep1 -- set Interface vf_rep1 type=dpdk > > options:dpdk-devargs=0000:06:02.0 > > 2. Add the representor port to the bridge > > ovs-vsctl add-port ovsbr0 vf_rep1 -- set Interface vf_rep1 type=dpdk > > options:dpdk-devargs=0000:06:02.0,representor=1 > > > > Signed-off-by: Somnath Kotur > > Signed-off-by: Venkat Duvvuru > > Reviewed-by: Kalesh AP > > Reviewed-by: Ajit Khaparde > > <...> > > > static int bnxt_pci_remove(struct rte_pci_device *pci_dev) > > { > > - if (rte_eal_process_type() == RTE_PROC_PRIMARY) > > - return rte_eth_dev_pci_generic_remove(pci_dev, > > - bnxt_dev_uninit); > > - else > > + struct rte_eth_dev *eth_dev; > > + > > + eth_dev = rte_eth_dev_allocated(pci_dev->device.name); > > + if (!eth_dev) > > + return ENODEV; /* Invoked typically only by OVS-DPDK, by the > > + * time it comes here the eth_dev is already > > + * deleted by rte_eth_dev_close(), so returning > > + * +ve value will atleast help in proper cleanup > > + */ > > Why returning a positive error value? It hides the error since the caller of the > function does a "< 0" check. > Better to be more explicit and return '0' if an error is not intendent in this case. > Sure, makes sense Ferruh