From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1E792A09FF; Wed, 6 Jan 2021 15:24:12 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AB8CD160989; Wed, 6 Jan 2021 15:24:11 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 5F31A160983 for ; Wed, 6 Jan 2021 15:24:09 +0100 (CET) IronPort-SDR: qanEm7RORK8gWfDaW3A1LrQVhbowy3KrgBSvyY8SrPaXbAgR0fQ5v1AL5sK5Ydnr3EPifZBYny ir0FoYZT9v9w== X-IronPort-AV: E=McAfee;i="6000,8403,9855"; a="195830378" X-IronPort-AV: E=Sophos;i="5.78,480,1599548400"; d="scan'208";a="195830378" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 06:24:08 -0800 IronPort-SDR: 8kpT/hZNmUaKtlkgzIcTyWOvaxB7o397bVptOJywOxAHDcrRP0AQbxT5/WgblZ76m7CGY8SDVS n7CcdY7a4ruQ== X-IronPort-AV: E=Sophos;i="5.78,480,1599548400"; d="scan'208";a="422180071" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.237.190]) ([10.213.237.190]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 06:24:07 -0800 To: Jerin Jacob , Pradeep Kumar Nalla Cc: Jerin Jacob Kollanukkaran , Satananda Burla , "dev@dpdk.org" References: <20201231072247.5719-1-pnalla@marvell.com> <6e4fdae7-4c60-45fb-cb17-8ef0a853b1c6@intel.com> <708ef98d-7492-be87-6a6f-454e68174da3@intel.com> From: Ferruh Yigit Message-ID: <7b6ad3ec-f2c9-978f-9551-323b8d523fdc@intel.com> Date: Wed, 6 Jan 2021 14:24:03 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/15] Octeon Tx/Tx2 Endpoint pmd 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 Sender: "dev" On 1/6/2021 11:58 AM, Jerin Jacob wrote: > On Wed, Jan 6, 2021 at 5:06 PM Pradeep Kumar Nalla wrote: >> >> >> >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Tuesday, January 5, 2021 8:59 PM >> To: Pradeep Kumar Nalla >> Cc: Jerin Jacob Kollanukkaran ; Satananda Burla ; dev@dpdk.org >> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH 00/15] Octeon Tx/Tx2 Endpoint pmd >> >> On 1/5/2021 2:43 PM, Pradeep Kumar Nalla wrote: >> >> Please do not top post, reply moved below. >> >>> Thanks >>> Pradeep. >>> -----Original Message----- >>> From: Ferruh Yigit >>> Sent: Monday, January 4, 2021 5:22 PM >>> To: Pradeep Kumar Nalla >>> Cc: Jerin Jacob Kollanukkaran ; Satananda Burla >>> ; dev@dpdk.org >>> Subject: [EXT] Re: [dpdk-dev] [PATCH 00/15] Octeon Tx/Tx2 Endpoint pmd >>> >>> External Email >>> >>> ---------------------------------------------------------------------- >>> On 12/31/2020 7:22 AM, Nalla, Pradeep wrote: >>>> From: "Nalla Pradeep" >>>> >>>> This patch set contains PMD with minimal set of operations that can >>>> drive both Octeon Tx and Tx2 in endpoint. >>>> >>> >>> Hi Pradeep, >>> >>> There is already octeontx and octeontx2 net drivers, what is the difference of the 'endpoint' driver, why it is needed, can you please give more information? >>> >>> Hi Ferruh >>> >>> This PMD, while running on a host, drives octeontx/octeontx2 over pci bus, where as "OcteonTx and OcteonTx2 net drivers" run on respective Tx/Tx2 SOCs to make use of h/w blocks present on the SOC. >>> >>> But aren't they same HW block, either in the SoC or external ethernet controller via PCI bus? >> No, this pmd doesn't access any h/w block on the soc. When in ep mode octeontx and octeontx2 present themselves as network devices and this pmd will program that interface and does packet rx/tx. >>> As far as I can see octeontx2 access the device via PCI bus, why updating the existing driver and adding new device IDs is not working? >> OxteonTx2 access H/W blocks on soc which also appear as PCI devices. > > In other words, > - The net/octeontx2 driver has a separate set of HW devices that are > not accessible from x86 host. So is the net/octeontx2 superset of the endpoint driver? > - Even though net/octeontx2 is based on PCI bus, scope of that PCI bus > is internal to SoC. It is an internal bus emulated as PCI to help > standard device probing works. > This shouldn't differ from driver perspective, right, for driver it is configuring device on PCI bus. Just to be able to eliminate any code that can be eliminated, what prevents using 'net/octeontx2'? Like I assume one of the HW block not accessible for EP device is eventdev block, is this making required driver change too big, or is it completely something else? Btw, I can see some end point device PCI IDs are already used, PCI_DEVID_OCTEONTX2_EP_VF, but it is used by a rawdev driver (raw/octeontx2_ep), not sure what it is.