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 78783A09FF; Wed, 6 Jan 2021 15:44:04 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5F78C160989; Wed, 6 Jan 2021 15:44:04 +0100 (CET) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by mails.dpdk.org (Postfix) with ESMTP id 274EB160983 for ; Wed, 6 Jan 2021 15:44:03 +0100 (CET) Received: by mail-il1-f172.google.com with SMTP id v3so3407130ilo.5 for ; Wed, 06 Jan 2021 06:44:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TxKl30w64AuiFuy3YA70d6NQ//1xDnv80s0DxrTVxMQ=; b=C1eCkRjcbic4MOrBhbssvIQ/jdQ15N8J/c5VESG2XU0piz505hOYYnOY16w53RgV7X KWnvTlBrLNn/ffj7V7k8M7MPS2TyZidYoVtQWMJkSstB6tCl5c5DMHvbWqebazqmnre1 l4Y26OoQCximzK108r8xp8kHx/iEtH1C7Lny4l1MsjHCsH4C62xACzKW5ADuqFtaBoGh pnn8Wo6jcl9Z2tM9IoGCwPhXhfvV7Kbqa7YfA6xH7oV1sR6ilksVzWWompI4f4W5U7vP sh99nq+DxPLalLXLGizZGD3TXnJSGjNTyuM0tmSou6rfbDyt2PkBlI7ehuSea0Cvn4JL I2mg== 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=TxKl30w64AuiFuy3YA70d6NQ//1xDnv80s0DxrTVxMQ=; b=YnFH83OvUtOZyRWWpvayL8xHJbVo8LbtSbzQNhcVTDJCmfpMMHu/GNrBmS5S6kcUHS GadszXG52ePaClbV2yRJviAgi7afSugvJVcFBwPQT+hmHQBzzB2MPdQLKwR4kzrHva2f HvSsp3leSeKZFTJt6FfnRZnaLUGlgBu1evhQpEOakKn68jR4pI3ab4sdhbOvBwPxcI+Z RCUjB2/Cx5y9ARRUNYUvGtbmto9irqPVPiRff18OrBoaufJdHPdFS/V2pj38eZ+5TzUb giyzRgeq1pj561ke4VQ9bfh4WZ3UTQzQzrSmBhY2NzQeSmYdTzMcnphiekNEF6WcMgdR ed6Q== X-Gm-Message-State: AOAM5336hLPYdQg7MqRfMTX+dB2XgDp9Vmw0mQhARCRaEfCgp+kEQcM8 m0AxTc2gYil7JFg7twIVlZaom06HEO32KlVxbOU= X-Google-Smtp-Source: ABdhPJyUHbdwirR1yUBbBfQJ8rlz0uX7Qcpd3CkEi0hz3YuCl9OVCXJV6RiH8s6xeO9yAQmj3U9BpjYHuFAV3+RPvpE= X-Received: by 2002:a05:6e02:e45:: with SMTP id l5mr4392321ilk.294.1609944242537; Wed, 06 Jan 2021 06:44:02 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <7b6ad3ec-f2c9-978f-9551-323b8d523fdc@intel.com> From: Jerin Jacob Date: Wed, 6 Jan 2021 20:13:46 +0530 Message-ID: To: Ferruh Yigit Cc: Pradeep Kumar Nalla , Jerin Jacob Kollanukkaran , Satananda Burla , "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" 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 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 > 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.