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.
