-----Original Message----- From: Jerin Jacob <jerinjac...@gmail.com> Sent: Wednesday, January 6, 2021 8:14 PM To: Ferruh Yigit <ferruh.yi...@intel.com> Cc: Pradeep Kumar Nalla <pna...@marvell.com>; Jerin Jacob Kollanukkaran <jer...@marvell.com>; Satananda Burla <sbu...@marvell.com>; dev@dpdk.org Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/15] Octeon Tx/Tx2 Endpoint pmd
On Wed, Jan 6, 2021 at 7:54 PM Ferruh Yigit <ferruh.yi...@intel.com> wrote: > > On 1/6/2021 11:58 AM, Jerin Jacob wrote: > > On Wed, Jan 6, 2021 at 5:06 PM Pradeep Kumar Nalla <pna...@marvell.com> > > wrote: > >> > >> > >> > >> -----Original Message----- > >> From: Ferruh Yigit <ferruh.yi...@intel.com> > >> Sent: Tuesday, January 5, 2021 8:59 PM > >> To: Pradeep Kumar Nalla <pna...@marvell.com> > >> Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; Satananda Burla > >> <sbu...@marvell.com>; 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 <ferruh.yi...@intel.com> > >>> Sent: Monday, January 4, 2021 5:22 PM > >>> To: Pradeep Kumar Nalla <pna...@marvell.com> > >>> Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; Satananda > >>> Burla <sbu...@marvell.com>; 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" <pna...@marvell.com> > >>>> > >>>> 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. Device id of (raw/octeontx2_ep) i.e., PCI_DEVID_OCTEONTX2_EP_VF will be changed to 0xB204 whereas net/octeon_tx2 will continue to have 0xB203
