Re: [dpdk-dev] [EXT] Re: [PATCH 00/15] Octeon Tx/Tx2 Endpoint pmd

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 1/6/2021 2:43 PM, Jerin Jacob wrote:
> On Wed, Jan 6, 2021 at 7:54 PM Ferruh Yigit <ferruh.yigit@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 <pnalla@marvell.com> wrote:
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>>> Sent: Tuesday, January 5, 2021 8:59 PM
>>>> To: Pradeep Kumar Nalla <pnalla@marvell.com>
>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Satananda Burla <sburla@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.yigit@intel.com>
>>>>> Sent: Monday, January 4, 2021 5:22 PM
>>>>> To: Pradeep Kumar Nalla <pnalla@marvell.com>
>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Satananda Burla
>>>>> <sburla@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" <pnalla@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
> 

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.
>