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 0D37EA0524; Wed, 6 Jan 2021 19:13:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 83772140E1C; Wed, 6 Jan 2021 19:13:42 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id C51CF40FA7 for ; Wed, 6 Jan 2021 19:13:40 +0100 (CET) IronPort-SDR: dParL/lvAZT5KrLFFaKBHGtqQnQgsfBHzEY1TIjdZBPs0I1q8AVCzZGo7WvJW9V3MvyAt+QhIZ AgIrnNzKG5MA== X-IronPort-AV: E=McAfee;i="6000,8403,9856"; a="165014788" X-IronPort-AV: E=Sophos;i="5.79,327,1602572400"; d="scan'208";a="165014788" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 10:13:39 -0800 IronPort-SDR: xdaKWMpJpc0bReb/qSIidEm4vsh9pTlRXBbbxEBEcTl0PL9g41VS3w9aGdLtt0zkRfstCdi+nc 9AttTyAcHATw== X-IronPort-AV: E=Sophos;i="5.79,327,1602572400"; d="scan'208";a="422255338" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.251.93.217]) ([10.251.93.217]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 10:13:38 -0800 To: Jerin Jacob Cc: Pradeep Kumar Nalla , 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> <7b6ad3ec-f2c9-978f-9551-323b8d523fdc@intel.com> From: Ferruh Yigit Message-ID: <18eb65b0-61eb-9ec9-de93-64fb40bafb76@intel.com> Date: Wed, 6 Jan 2021 18:13:34 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 2:43 PM, Jerin Jacob wrote: > On Wed, Jan 6, 2021 at 7:54 PM Ferruh Yigit wrote: >> >> 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? > > > No one of the HW devices that is managed by net/octeontx2 is available > to PCI RC HOST. > > The architecture is like below: It is for smart NIC kind of use case where > 1) octeontx2 is in PCIe form factor(connected to x86) > 2) net/octeontx2 driver runs on arm64 > 3) There will be a DPDK application that's using net/octeontx2 on > ARM64 and it includes a message server(we call it FW) > 4) New PMD(net/octeontx_ep) run on x86, send messages over PCI interface. > 5) FW Receives the msg and DPDK app(FW) on ARM64 process it using net/octeonxt2. > These messages are very high level abstracted. > 6) FW Transmites back message to x86 > 7) Step 5 and 6 is the ethdev dev ops for net/octeontx_ep > Thanks Jerin for the clarification. > >> 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. > > Good point. underlaying HW for raw dev and net/octeontx_ep is the > same. Just that new PMD has a handle for > custom message(with help FW in arm64) to act as ethdev device. We will > see what is the best > method to resolve PCI ID conflit. >