[dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Ananyev, Konstantin]

Minutes of Technical Board Meeting, 2021-Oct-27

Members Attending
---------------------------
-Aaron
-Ferruh
-Hemant
-Honnappa
-Jerin
-Kevin
-Konstantin (Chair)
-Maxime
-Stephen
-Thomas

NOTE: The technical board meetings every second Wednesday at
https://meet.jit.si/DPDK at 3 pm UTC.
Meetings are public, and DPDK community members are welcome to attend.

NOTE: Next meeting will be on Wednesday 2021-Nov-03 @3pm UTC, and will
be chaired by Maxime.


GPUDEV library / DWA library inclusion
  http://inbox.dpdk.org/dev/DM6PR12MB41079FAE6B5DA35102B1BBFACDB79@DM6PR12MB4107.namprd12.prod.outlook.com/
  http://mails.dpdk.org/archives/dev/2021-October/226070.html  

  
1. GPU dev
=========

Pros:
- simple and clean API
- address particular needs:
    - external (GPU) memory management within DPDK 
    - provides generic framework for CPU-GPU-NIC interaction
- Not specific to any particular workload
- GPU program creation/upload is out of scope for this framework

Concerns:
-  Framework is specific for just one particular accelerator class (GPU)
   If we go that way, does it mean we'll need a separate library/API for each
   new HW device class (FPGA, etc.)?
   
2. DWA dev
==========

Pros:
- HW neutral abstraction for accelerator communication
- HW neutral abstraction for workload definitions (via profile)
- Ability to chain services provided by HW (chain multiple profiles)
- Sounds like really good approach for SoCs

Concerns:
- Not easy to agree/define mandatory/optional features for each particular profile
- User limited to particular already implemented profiles (longer time to market, etc.)
- Richness of features might cause overcomplication in both internal
  design/implementation and public API

Conclusion
=========

At that stage it is really hard to predict which approach will be more successful.
As both paths can co-exist within DPDK:

1) Go ahead with both approaches as experimental lib/drivers inside DPDK
2) Re-evaluate both approaches in one year time
3) Both should follow usual DPDK policy for new lib/device classes:
    generic framework plus at least one driver implementation
4) Both should be usable with open-source tools
    (no exclusive dependency on third-party proprietary SW).

Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Jerin Jacob]

On Tue, Nov 2, 2021 at 9:35 PM Ananyev, Konstantin
<konstantin.ananyev@intel.com> wrote:
>
> Minutes of Technical Board Meeting, 2021-Oct-27
>
> Members Attending
> ---------------------------
> -Aaron
> -Ferruh
> -Hemant
> -Honnappa
> -Jerin
> -Kevin
> -Konstantin (Chair)
> -Maxime
> -Stephen
> -Thomas
>
> NOTE: The technical board meetings every second Wednesday at
> https://meet.jit.si/DPDK at 3 pm UTC.
> Meetings are public, and DPDK community members are welcome to attend.
>
> NOTE: Next meeting will be on Wednesday 2021-Nov-03 @3pm UTC, and will
> be chaired by Maxime.
>
>
> GPUDEV library / DWA library inclusion
>   http://inbox.dpdk.org/dev/DM6PR12MB41079FAE6B5DA35102B1BBFACDB79@DM6PR12MB4107.namprd12.prod.outlook.com/
>   http://mails.dpdk.org/archives/dev/2021-October/226070.html
>
>
> 1. GPU dev
> =========
>
> Pros:
> - simple and clean API
> - address particular needs:
>     - external (GPU) memory management within DPDK
>     - provides generic framework for CPU-GPU-NIC interaction
> - Not specific to any particular workload
> - GPU program creation/upload is out of scope for this framework
>
> Concerns:
> -  Framework is specific for just one particular accelerator class (GPU)
>    If we go that way, does it mean we'll need a separate library/API for each
>    new HW device class (FPGA, etc.)?
>
> 2. DWA dev
> ==========
>
> Pros:
> - HW neutral abstraction for accelerator communication
> - HW neutral abstraction for workload definitions (via profile)
> - Ability to chain services provided by HW (chain multiple profiles)
> - Sounds like really good approach for SoCs
>
> Concerns:
> - Not easy to agree/define mandatory/optional features for each particular profile
> - User limited to particular already implemented profiles (longer time to market, etc.)
> - Richness of features might cause overcomplication in both internal
>   design/implementation and public API
>
> Conclusion
> =========
>
> At that stage it is really hard to predict which approach will be more successful.
> As both paths can co-exist within DPDK:
>
> 1) Go ahead with both approaches as experimental lib/drivers inside DPDK

Now that there is approval from TB.

I would like to ask, Is anyone planning to review the specification
header file [1]?

There was a comment to remove the TLV length. I will do that next
version with implementation.

Identified the following set of work for this.

1) Common code at lib/dwa/
2) Marvell DPU based driver at drivers/dwa/cnxk/
3) Test application at app/test-dwa/
4) It is possible to have an SW driver(To allow non-specialized HW to
use the framework) for this by:
a) Emulate DWA HW as a separate DPDK process
b) Add drivers/dwa/sw/ and use memif driver so to create a
communication channel between emulated DWA HW process and DPDK
application.
c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd profile
using DPDK libraries for SW driver.

I think, Item (4) aka SW drivers as useful(We don't need to implement
for all profiles, I think, just for  l3fwd it make sense to add, to
allow to use of the framework in just SW mode).
Is there any opinion on adding item (4) in DPDK? I saw mixed opinions
earlier on this. I would like to understand, Is there any objection to
doing
item(4) in DPDK as it needs a good amount of work and  I don't want to
do throw it away if the community doesn't like this.
Any opinion?

[1]
http://mails.dpdk.org/archives/dev/2021-October/226070.html


> 2) Re-evaluate both approaches in one year time
> 3) Both should follow usual DPDK policy for new lib/device classes:
>     generic framework plus at least one driver implementation
> 4) Both should be usable with open-source tools
>     (no exclusive dependency on third-party proprietary SW).
>
>

RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Ananyev, Konstantin]

Hi Jerin,

> > Minutes of Technical Board Meeting, 2021-Oct-27
> >
> > Members Attending
> > ---------------------------
> > -Aaron
> > -Ferruh
> > -Hemant
> > -Honnappa
> > -Jerin
> > -Kevin
> > -Konstantin (Chair)
> > -Maxime
> > -Stephen
> > -Thomas
> >
> > NOTE: The technical board meetings every second Wednesday at
> > https://meet.jit.si/DPDK at 3 pm UTC.
> > Meetings are public, and DPDK community members are welcome to attend.
> >
> > NOTE: Next meeting will be on Wednesday 2021-Nov-03 @3pm UTC, and will
> > be chaired by Maxime.
> >
> >
> > GPUDEV library / DWA library inclusion
> >   http://inbox.dpdk.org/dev/DM6PR12MB41079FAE6B5DA35102B1BBFACDB79@DM6PR12MB4107.namprd12.prod.outlook.com/
> >   http://mails.dpdk.org/archives/dev/2021-October/226070.html
> >
> >
> > 1. GPU dev
> > =========
> >
> > Pros:
> > - simple and clean API
> > - address particular needs:
> >     - external (GPU) memory management within DPDK
> >     - provides generic framework for CPU-GPU-NIC interaction
> > - Not specific to any particular workload
> > - GPU program creation/upload is out of scope for this framework
> >
> > Concerns:
> > -  Framework is specific for just one particular accelerator class (GPU)
> >    If we go that way, does it mean we'll need a separate library/API for each
> >    new HW device class (FPGA, etc.)?
> >
> > 2. DWA dev
> > ==========
> >
> > Pros:
> > - HW neutral abstraction for accelerator communication
> > - HW neutral abstraction for workload definitions (via profile)
> > - Ability to chain services provided by HW (chain multiple profiles)
> > - Sounds like really good approach for SoCs
> >
> > Concerns:
> > - Not easy to agree/define mandatory/optional features for each particular profile
> > - User limited to particular already implemented profiles (longer time to market, etc.)
> > - Richness of features might cause overcomplication in both internal
> >   design/implementation and public API
> >
> > Conclusion
> > =========
> >
> > At that stage it is really hard to predict which approach will be more successful.
> > As both paths can co-exist within DPDK:
> >
> > 1) Go ahead with both approaches as experimental lib/drivers inside DPDK
> 
> Now that there is approval from TB.
> 
> I would like to ask, Is anyone planning to review the specification
> header file [1]?
> 
> There was a comment to remove the TLV length. I will do that next
> version with implementation.
> 
> Identified the following set of work for this.
> 
> 1) Common code at lib/dwa/
> 2) Marvell DPU based driver at drivers/dwa/cnxk/
> 3) Test application at app/test-dwa/
> 4) It is possible to have an SW driver(To allow non-specialized HW to
> use the framework) for this by:
> a) Emulate DWA HW as a separate DPDK process
> b) Add drivers/dwa/sw/ and use memif driver so to create a
> communication channel between emulated DWA HW process and DPDK
> application.
> c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd profile
> using DPDK libraries for SW driver.
> 
> I think, Item (4) aka SW drivers as useful(We don't need to implement
> for all profiles, I think, just for  l3fwd it make sense to add, to
> allow to use of the framework in just SW mode).
> Is there any opinion on adding item (4) in DPDK? I saw mixed opinions
> earlier on this. I would like to understand, Is there any objection to
> doing
> item(4) in DPDK as it needs a good amount of work and  I don't want to
> do throw it away if the community doesn't like this.
> Any opinion?

I'd say (4) is a good thing to have.
Will allow people to try/test DWA approach and framework itself
without access to specific HW.
 
> [1]
> http://mails.dpdk.org/archives/dev/2021-October/226070.html
> 
> 
> > 2) Re-evaluate both approaches in one year time
> > 3) Both should follow usual DPDK policy for new lib/device classes:
> >     generic framework plus at least one driver implementation
> > 4) Both should be usable with open-source tools
> >     (no exclusive dependency on third-party proprietary SW).
> >
> >

RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Honnappa Nagarahalli]

<snip>

> 
> 
> 
> Hi Jerin,
> 
> > > Minutes of Technical Board Meeting, 2021-Oct-27
> > >
> > > Members Attending
> > > ---------------------------
> > > -Aaron
> > > -Ferruh
> > > -Hemant
> > > -Honnappa
> > > -Jerin
> > > -Kevin
> > > -Konstantin (Chair)
> > > -Maxime
> > > -Stephen
> > > -Thomas
> > >
> > > NOTE: The technical board meetings every second Wednesday at
> > > https://meet.jit.si/DPDK at 3 pm UTC.
> > > Meetings are public, and DPDK community members are welcome to
> attend.
> > >
> > > NOTE: Next meeting will be on Wednesday 2021-Nov-03 @3pm UTC, and
> > > will be chaired by Maxime.
> > >
> > >
> > > GPUDEV library / DWA library inclusion
> > >
> http://inbox.dpdk.org/dev/DM6PR12MB41079FAE6B5DA35102B1BBFACDB7
> 9@DM6PR12MB4107.namprd12.prod.outlook.com/
> > >   http://mails.dpdk.org/archives/dev/2021-October/226070.html
> > >
> > >
> > > 1. GPU dev
> > > =========
> > >
> > > Pros:
> > > - simple and clean API
> > > - address particular needs:
> > >     - external (GPU) memory management within DPDK
> > >     - provides generic framework for CPU-GPU-NIC interaction
> > > - Not specific to any particular workload
> > > - GPU program creation/upload is out of scope for this framework
> > >
> > > Concerns:
> > > -  Framework is specific for just one particular accelerator class (GPU)
> > >    If we go that way, does it mean we'll need a separate library/API for
> each
> > >    new HW device class (FPGA, etc.)?
> > >
> > > 2. DWA dev
> > > ==========
> > >
> > > Pros:
> > > - HW neutral abstraction for accelerator communication
> > > - HW neutral abstraction for workload definitions (via profile)
> > > - Ability to chain services provided by HW (chain multiple profiles)
> > > - Sounds like really good approach for SoCs
> > >
> > > Concerns:
> > > - Not easy to agree/define mandatory/optional features for each
> > > particular profile
> > > - User limited to particular already implemented profiles (longer
> > > time to market, etc.)
> > > - Richness of features might cause overcomplication in both internal
> > >   design/implementation and public API
> > >
> > > Conclusion
> > > =========
> > >
> > > At that stage it is really hard to predict which approach will be more
> successful.
> > > As both paths can co-exist within DPDK:
> > >
> > > 1) Go ahead with both approaches as experimental lib/drivers inside
> > > DPDK
> >
> > Now that there is approval from TB.
> >
> > I would like to ask, Is anyone planning to review the specification
> > header file [1]?
> >
> > There was a comment to remove the TLV length. I will do that next
> > version with implementation.
> >
> > Identified the following set of work for this.
> >
> > 1) Common code at lib/dwa/
> > 2) Marvell DPU based driver at drivers/dwa/cnxk/
> > 3) Test application at app/test-dwa/
> > 4) It is possible to have an SW driver(To allow non-specialized HW to
> > use the framework) for this by:
> > a) Emulate DWA HW as a separate DPDK process
> > b) Add drivers/dwa/sw/ and use memif driver so to create a
> > communication channel between emulated DWA HW process and DPDK
> > application.
> > c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd profile
> > using DPDK libraries for SW driver.
> >
> > I think, Item (4) aka SW drivers as useful(We don't need to implement
> > for all profiles, I think, just for  l3fwd it make sense to add, to
> > allow to use of the framework in just SW mode).
> > Is there any opinion on adding item (4) in DPDK? I saw mixed opinions
> > earlier on this. I would like to understand, Is there any objection to
> > doing
> > item(4) in DPDK as it needs a good amount of work and  I don't want to
> > do throw it away if the community doesn't like this.
> > Any opinion?
> 
> I'd say (4) is a good thing to have.
> Will allow people to try/test DWA approach and framework itself without
> access to specific HW.
Agree in general it is good as a standard of the expected behavior. But, it might be difficult/complex to implement all the profiles. For ex: L1 processing for 5G.

> 
> > [1]
> > http://mails.dpdk.org/archives/dev/2021-October/226070.html
> >
> >
> > > 2) Re-evaluate both approaches in one year time
> > > 3) Both should follow usual DPDK policy for new lib/device classes:
> > >     generic framework plus at least one driver implementation
> > > 4) Both should be usable with open-source tools
> > >     (no exclusive dependency on third-party proprietary SW).
> > >
> > >

RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Ananyev, Konstantin]

> 
> >
> >
> >
> > Hi Jerin,
> >
> > > > Minutes of Technical Board Meeting, 2021-Oct-27
> > > >
> > > > Members Attending
> > > > ---------------------------
> > > > -Aaron
> > > > -Ferruh
> > > > -Hemant
> > > > -Honnappa
> > > > -Jerin
> > > > -Kevin
> > > > -Konstantin (Chair)
> > > > -Maxime
> > > > -Stephen
> > > > -Thomas
> > > >
> > > > NOTE: The technical board meetings every second Wednesday at
> > > > https://meet.jit.si/DPDK at 3 pm UTC.
> > > > Meetings are public, and DPDK community members are welcome to
> > attend.
> > > >
> > > > NOTE: Next meeting will be on Wednesday 2021-Nov-03 @3pm UTC, and
> > > > will be chaired by Maxime.
> > > >
> > > >
> > > > GPUDEV library / DWA library inclusion
> > > >
> > http://inbox.dpdk.org/dev/DM6PR12MB41079FAE6B5DA35102B1BBFACDB7
> > 9@DM6PR12MB4107.namprd12.prod.outlook.com/
> > > >   http://mails.dpdk.org/archives/dev/2021-October/226070.html
> > > >
> > > >
> > > > 1. GPU dev
> > > > =========
> > > >
> > > > Pros:
> > > > - simple and clean API
> > > > - address particular needs:
> > > >     - external (GPU) memory management within DPDK
> > > >     - provides generic framework for CPU-GPU-NIC interaction
> > > > - Not specific to any particular workload
> > > > - GPU program creation/upload is out of scope for this framework
> > > >
> > > > Concerns:
> > > > -  Framework is specific for just one particular accelerator class (GPU)
> > > >    If we go that way, does it mean we'll need a separate library/API for
> > each
> > > >    new HW device class (FPGA, etc.)?
> > > >
> > > > 2. DWA dev
> > > > ==========
> > > >
> > > > Pros:
> > > > - HW neutral abstraction for accelerator communication
> > > > - HW neutral abstraction for workload definitions (via profile)
> > > > - Ability to chain services provided by HW (chain multiple profiles)
> > > > - Sounds like really good approach for SoCs
> > > >
> > > > Concerns:
> > > > - Not easy to agree/define mandatory/optional features for each
> > > > particular profile
> > > > - User limited to particular already implemented profiles (longer
> > > > time to market, etc.)
> > > > - Richness of features might cause overcomplication in both internal
> > > >   design/implementation and public API
> > > >
> > > > Conclusion
> > > > =========
> > > >
> > > > At that stage it is really hard to predict which approach will be more
> > successful.
> > > > As both paths can co-exist within DPDK:
> > > >
> > > > 1) Go ahead with both approaches as experimental lib/drivers inside
> > > > DPDK
> > >
> > > Now that there is approval from TB.
> > >
> > > I would like to ask, Is anyone planning to review the specification
> > > header file [1]?
> > >
> > > There was a comment to remove the TLV length. I will do that next
> > > version with implementation.
> > >
> > > Identified the following set of work for this.
> > >
> > > 1) Common code at lib/dwa/
> > > 2) Marvell DPU based driver at drivers/dwa/cnxk/
> > > 3) Test application at app/test-dwa/
> > > 4) It is possible to have an SW driver(To allow non-specialized HW to
> > > use the framework) for this by:
> > > a) Emulate DWA HW as a separate DPDK process
> > > b) Add drivers/dwa/sw/ and use memif driver so to create a
> > > communication channel between emulated DWA HW process and DPDK
> > > application.
> > > c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd profile
> > > using DPDK libraries for SW driver.
> > >
> > > I think, Item (4) aka SW drivers as useful(We don't need to implement
> > > for all profiles, I think, just for  l3fwd it make sense to add, to
> > > allow to use of the framework in just SW mode).
> > > Is there any opinion on adding item (4) in DPDK? I saw mixed opinions
> > > earlier on this. I would like to understand, Is there any objection to
> > > doing
> > > item(4) in DPDK as it needs a good amount of work and  I don't want to
> > > do throw it away if the community doesn't like this.
> > > Any opinion?
> >
> > I'd say (4) is a good thing to have.
> > Will allow people to try/test DWA approach and framework itself without
> > access to specific HW.
> Agree in general it is good as a standard of the expected behavior. But, it might be difficult/complex to implement all the profiles. For ex: L1
> processing for 5G.

From my understanding, Jerin talks about
SW implementation for only one profile for now (L3FWD).

> 
> >
> > > [1]
> > > http://mails.dpdk.org/archives/dev/2021-October/226070.html
> > >
> > >
> > > > 2) Re-evaluate both approaches in one year time
> > > > 3) Both should follow usual DPDK policy for new lib/device classes:
> > > >     generic framework plus at least one driver implementation
> > > > 4) Both should be usable with open-source tools
> > > >     (no exclusive dependency on third-party proprietary SW).
> > > >
> > > >

RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Honnappa Nagarahalli]

<snip>

> >
> > 1) Go ahead with both approaches as experimental lib/drivers inside
> > DPDK
> 
> Now that there is approval from TB.
> 
> I would like to ask, Is anyone planning to review the specification header file
> [1]?
I plan to, but need some time. With the holiday approaching, things are busy.

> 
> There was a comment to remove the TLV length. I will do that next version with
> implementation.
> 
> Identified the following set of work for this.
> 
> 1) Common code at lib/dwa/
> 2) Marvell DPU based driver at drivers/dwa/cnxk/
> 3) Test application at app/test-dwa/
> 4) It is possible to have an SW driver(To allow non-specialized HW to use the
> framework) for this by:
> a) Emulate DWA HW as a separate DPDK process
> b) Add drivers/dwa/sw/ and use memif driver so to create a communication
> channel between emulated DWA HW process and DPDK application.
Why use memif driver? Why not ring-pmd?

> c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd profile using DPDK
> libraries for SW driver.
> 
> I think, Item (4) aka SW drivers as useful(We don't need to implement for all
> profiles, I think, just for  l3fwd it make sense to add, to allow to use of the
> framework in just SW mode).
> Is there any opinion on adding item (4) in DPDK? I saw mixed opinions earlier on
> this. I would like to understand, Is there any objection to doing
> item(4) in DPDK as it needs a good amount of work and  I don't want to do
> throw it away if the community doesn't like this.
> Any opinion?
> 
> [1]
> http://mails.dpdk.org/archives/dev/2021-October/226070.html
> 
<snip>

Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Jerin Jacob]

On Fri, Nov 12, 2021 at 7:17 AM Ananyev, Konstantin
<konstantin.ananyev@intel.com> wrote:
>
>
> >
> > >
> > >
> > >
> > > Hi Jerin,
> > >
> > > > > Minutes of Technical Board Meeting, 2021-Oct-27
> > > > >
> > > > > Members Attending
> > > > > ---------------------------
> > > > > -Aaron
> > > > > -Ferruh
> > > > > -Hemant
> > > > > -Honnappa
> > > > > -Jerin
> > > > > -Kevin
> > > > > -Konstantin (Chair)
> > > > > -Maxime
> > > > > -Stephen
> > > > > -Thomas
> > > > >
> > > > > NOTE: The technical board meetings every second Wednesday at
> > > > > https://meet.jit.si/DPDK at 3 pm UTC.
> > > > > Meetings are public, and DPDK community members are welcome to
> > > attend.
> > > > >
> > > > > NOTE: Next meeting will be on Wednesday 2021-Nov-03 @3pm UTC, and
> > > > > will be chaired by Maxime.
> > > > >
> > > > >
> > > > > GPUDEV library / DWA library inclusion
> > > > >
> > > http://inbox.dpdk.org/dev/DM6PR12MB41079FAE6B5DA35102B1BBFACDB7
> > > 9@DM6PR12MB4107.namprd12.prod.outlook.com/
> > > > >   http://mails.dpdk.org/archives/dev/2021-October/226070.html
> > > > >
> > > > >
> > > > > 1. GPU dev
> > > > > =========
> > > > >
> > > > > Pros:
> > > > > - simple and clean API
> > > > > - address particular needs:
> > > > >     - external (GPU) memory management within DPDK
> > > > >     - provides generic framework for CPU-GPU-NIC interaction
> > > > > - Not specific to any particular workload
> > > > > - GPU program creation/upload is out of scope for this framework
> > > > >
> > > > > Concerns:
> > > > > -  Framework is specific for just one particular accelerator class (GPU)
> > > > >    If we go that way, does it mean we'll need a separate library/API for
> > > each
> > > > >    new HW device class (FPGA, etc.)?
> > > > >
> > > > > 2. DWA dev
> > > > > ==========
> > > > >
> > > > > Pros:
> > > > > - HW neutral abstraction for accelerator communication
> > > > > - HW neutral abstraction for workload definitions (via profile)
> > > > > - Ability to chain services provided by HW (chain multiple profiles)
> > > > > - Sounds like really good approach for SoCs
> > > > >
> > > > > Concerns:
> > > > > - Not easy to agree/define mandatory/optional features for each
> > > > > particular profile
> > > > > - User limited to particular already implemented profiles (longer
> > > > > time to market, etc.)
> > > > > - Richness of features might cause overcomplication in both internal
> > > > >   design/implementation and public API
> > > > >
> > > > > Conclusion
> > > > > =========
> > > > >
> > > > > At that stage it is really hard to predict which approach will be more
> > > successful.
> > > > > As both paths can co-exist within DPDK:
> > > > >
> > > > > 1) Go ahead with both approaches as experimental lib/drivers inside
> > > > > DPDK
> > > >
> > > > Now that there is approval from TB.
> > > >
> > > > I would like to ask, Is anyone planning to review the specification
> > > > header file [1]?
> > > >
> > > > There was a comment to remove the TLV length. I will do that next
> > > > version with implementation.
> > > >
> > > > Identified the following set of work for this.
> > > >
> > > > 1) Common code at lib/dwa/
> > > > 2) Marvell DPU based driver at drivers/dwa/cnxk/
> > > > 3) Test application at app/test-dwa/
> > > > 4) It is possible to have an SW driver(To allow non-specialized HW to
> > > > use the framework) for this by:
> > > > a) Emulate DWA HW as a separate DPDK process
> > > > b) Add drivers/dwa/sw/ and use memif driver so to create a
> > > > communication channel between emulated DWA HW process and DPDK
> > > > application.
> > > > c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd profile
> > > > using DPDK libraries for SW driver.
> > > >
> > > > I think, Item (4) aka SW drivers as useful(We don't need to implement
> > > > for all profiles, I think, just for  l3fwd it make sense to add, to
> > > > allow to use of the framework in just SW mode).
> > > > Is there any opinion on adding item (4) in DPDK? I saw mixed opinions
> > > > earlier on this. I would like to understand, Is there any objection to
> > > > doing
> > > > item(4) in DPDK as it needs a good amount of work and  I don't want to
> > > > do throw it away if the community doesn't like this.
> > > > Any opinion?
> > >
> > > I'd say (4) is a good thing to have.
> > > Will allow people to try/test DWA approach and framework itself without
> > > access to specific HW.
> > Agree in general it is good as a standard of the expected behavior. But, it might be difficult/complex to implement all the profiles. For ex: L1
> > processing for 5G.
>
> From my understanding, Jerin talks about
> SW implementation for only one profile for now (L3FWD).

Yes. Only for one profile for now(L3FWD).
We don't have plan for emulating complex profiles like L1 Processing
for 5G.(I believe it is not even possible with the required quality)

>
> >
> > >
> > > > [1]
> > > > http://mails.dpdk.org/archives/dev/2021-October/226070.html
> > > >
> > > >
> > > > > 2) Re-evaluate both approaches in one year time
> > > > > 3) Both should follow usual DPDK policy for new lib/device classes:
> > > > >     generic framework plus at least one driver implementation
> > > > > 4) Both should be usable with open-source tools
> > > > >     (no exclusive dependency on third-party proprietary SW).
> > > > >
> > > > >

Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Jerin Jacob]

On Fri, Nov 12, 2021 at 7:55 AM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:
>
> <snip>
>
> > >
> > > 1) Go ahead with both approaches as experimental lib/drivers inside
> > > DPDK
> >
> > Now that there is approval from TB.
> >
> > I would like to ask, Is anyone planning to review the specification header file
> > [1]?
> I plan to, but need some time. With the holiday approaching, things are busy.

Thanks. I request to check top-level semantics in specification header
files as the first step.
Other next-level details, we can change at any time.
If you planning for any time frame, do let me know, so that we can
decide when to start
the implementation.

>
> >
> > There was a comment to remove the TLV length. I will do that next version with
> > implementation.
> >
> > Identified the following set of work for this.
> >
> > 1) Common code at lib/dwa/
> > 2) Marvell DPU based driver at drivers/dwa/cnxk/
> > 3) Test application at app/test-dwa/
> > 4) It is possible to have an SW driver(To allow non-specialized HW to use the
> > framework) for this by:
> > a) Emulate DWA HW as a separate DPDK process
> > b) Add drivers/dwa/sw/ and use memif driver so to create a communication
> > channel between emulated DWA HW process and DPDK application.
> Why use memif driver? Why not ring-pmd?

Planning to emulation DWA accelerator functional model as a separate
DPDK process in SW case.
Therefore memif is the ideal choice as it supports zero-copy of the
data as well.
https://doc.dpdk.org/guides/nics/memif.html

>
> > c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd profile using DPDK
> > libraries for SW driver.
> >
> > I think, Item (4) aka SW drivers as useful(We don't need to implement for all
> > profiles, I think, just for  l3fwd it make sense to add, to allow to use of the
> > framework in just SW mode).
> > Is there any opinion on adding item (4) in DPDK? I saw mixed opinions earlier on
> > this. I would like to understand, Is there any objection to doing
> > item(4) in DPDK as it needs a good amount of work and  I don't want to do
> > throw it away if the community doesn't like this.
> > Any opinion?
> >
> > [1]
> > http://mails.dpdk.org/archives/dev/2021-October/226070.html
> >
> <snip>

RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Honnappa Nagarahalli]

<snip>

> > > There was a comment to remove the TLV length. I will do that next
> > > version with implementation.
> > >
> > > Identified the following set of work for this.
> > >
> > > 1) Common code at lib/dwa/
> > > 2) Marvell DPU based driver at drivers/dwa/cnxk/
> > > 3) Test application at app/test-dwa/
> > > 4) It is possible to have an SW driver(To allow non-specialized HW
> > > to use the
> > > framework) for this by:
> > > a) Emulate DWA HW as a separate DPDK process
> > > b) Add drivers/dwa/sw/ and use memif driver so to create a
> > > communication channel between emulated DWA HW process and DPDK
> application.
> > Why use memif driver? Why not ring-pmd?
> 
> Planning to emulation DWA accelerator functional model as a separate DPDK
> process in SW case.
You mean the primary and secondary processes correct?

> Therefore memif is the ideal choice as it supports zero-copy of the data as
> well.
> https://doc.dpdk.org/guides/nics/memif.html
Zero-copy in memif is nothing but exchanging pointers to shared data.
The rings work across the primary and secondary processes and are always zero-copy.
We are doing some perf comparisons between memif and rings, will let you know once we have the data.

> 
> >
> > > c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd profile
> > > using DPDK libraries for SW driver.
> > >
> > > I think, Item (4) aka SW drivers as useful(We don't need to
> > > implement for all profiles, I think, just for  l3fwd it make sense
> > > to add, to allow to use of the framework in just SW mode).
> > > Is there any opinion on adding item (4) in DPDK? I saw mixed
> > > opinions earlier on this. I would like to understand, Is there any
> > > objection to doing
> > > item(4) in DPDK as it needs a good amount of work and  I don't want
> > > to do throw it away if the community doesn't like this.
> > > Any opinion?
> > >
> > > [1]
> > > http://mails.dpdk.org/archives/dev/2021-October/226070.html
> > >
> > <snip>

Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Jerin Jacob]

On Thu, Nov 18, 2021 at 8:44 PM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:
>
> <snip>
>
> > > > There was a comment to remove the TLV length. I will do that next
> > > > version with implementation.
> > > >
> > > > Identified the following set of work for this.
> > > >
> > > > 1) Common code at lib/dwa/
> > > > 2) Marvell DPU based driver at drivers/dwa/cnxk/
> > > > 3) Test application at app/test-dwa/
> > > > 4) It is possible to have an SW driver(To allow non-specialized HW
> > > > to use the
> > > > framework) for this by:
> > > > a) Emulate DWA HW as a separate DPDK process
> > > > b) Add drivers/dwa/sw/ and use memif driver so to create a
> > > > communication channel between emulated DWA HW process and DPDK
> > application.
> > > Why use memif driver? Why not ring-pmd?
> >
> > Planning to emulation DWA accelerator functional model as a separate DPDK
> > process in SW case.
> You mean the primary and secondary processes correct?

Primary and Primary. (DWA emulation as a separate primary process to
mimic the real-world scenario)

>
> > Therefore memif is the ideal choice as it supports zero-copy of the data as
> > well.
> > https://doc.dpdk.org/guides/nics/memif.html
> Zero-copy in memif is nothing but exchanging pointers to shared data.
> The rings work across the primary and secondary processes and are always zero-copy.
> We are doing some perf comparisons between memif and rings, will let you know once we have the data.

Ok.
I think between primary to primary memif will be required.

>
> >
> > >
> > > > c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd profile
> > > > using DPDK libraries for SW driver.
> > > >
> > > > I think, Item (4) aka SW drivers as useful(We don't need to
> > > > implement for all profiles, I think, just for  l3fwd it make sense
> > > > to add, to allow to use of the framework in just SW mode).
> > > > Is there any opinion on adding item (4) in DPDK? I saw mixed
> > > > opinions earlier on this. I would like to understand, Is there any
> > > > objection to doing
> > > > item(4) in DPDK as it needs a good amount of work and  I don't want
> > > > to do throw it away if the community doesn't like this.
> > > > Any opinion?
> > > >
> > > > [1]
> > > > http://mails.dpdk.org/archives/dev/2021-October/226070.html
> > > >
> > > <snip>

RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Honnappa Nagarahalli]

<snip>
> >
> > > > > There was a comment to remove the TLV length. I will do that
> > > > > next version with implementation.
> > > > >
> > > > > Identified the following set of work for this.
> > > > >
> > > > > 1) Common code at lib/dwa/
> > > > > 2) Marvell DPU based driver at drivers/dwa/cnxk/
> > > > > 3) Test application at app/test-dwa/
> > > > > 4) It is possible to have an SW driver(To allow non-specialized
> > > > > HW to use the
> > > > > framework) for this by:
> > > > > a) Emulate DWA HW as a separate DPDK process
> > > > > b) Add drivers/dwa/sw/ and use memif driver so to create a
> > > > > communication channel between emulated DWA HW process and
> DPDK
> > > application.
> > > > Why use memif driver? Why not ring-pmd?
> > >
> > > Planning to emulation DWA accelerator functional model as a separate
> > > DPDK process in SW case.
> > You mean the primary and secondary processes correct?
> 
> Primary and Primary. (DWA emulation as a separate primary process to mimic
> the real-world scenario)
> 
> >
> > > Therefore memif is the ideal choice as it supports zero-copy of the
> > > data as well.
> > > https://doc.dpdk.org/guides/nics/memif.html
> > Zero-copy in memif is nothing but exchanging pointers to shared data.
> > The rings work across the primary and secondary processes and are always
> zero-copy.
> > We are doing some perf comparisons between memif and rings, will let you
> know once we have the data.
> 
> Ok.
> I think between primary to primary memif will be required.
Agree, memif is easier/required between primary to primary. But, using it with zero-copy would need additional code on the application part in this scenario. The memory being shared needs to be mapped in both the processes.

> 
> >
> > >
> > > >
> > > > > c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd
> > > > > profile using DPDK libraries for SW driver.
> > > > >
> > > > > I think, Item (4) aka SW drivers as useful(We don't need to
> > > > > implement for all profiles, I think, just for  l3fwd it make
> > > > > sense to add, to allow to use of the framework in just SW mode).
> > > > > Is there any opinion on adding item (4) in DPDK? I saw mixed
> > > > > opinions earlier on this. I would like to understand, Is there
> > > > > any objection to doing
> > > > > item(4) in DPDK as it needs a good amount of work and  I don't
> > > > > want to do throw it away if the community doesn't like this.
> > > > > Any opinion?
> > > > >
> > > > > [1]
> > > > > http://mails.dpdk.org/archives/dev/2021-October/226070.html
> > > > >
> > > > <snip>

Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Jerin Jacob]

On Fri, Nov 19, 2021 at 1:39 AM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:
>
> <snip>
> > >
> > > > > > There was a comment to remove the TLV length. I will do that
> > > > > > next version with implementation.
> > > > > >
> > > > > > Identified the following set of work for this.
> > > > > >
> > > > > > 1) Common code at lib/dwa/
> > > > > > 2) Marvell DPU based driver at drivers/dwa/cnxk/
> > > > > > 3) Test application at app/test-dwa/
> > > > > > 4) It is possible to have an SW driver(To allow non-specialized
> > > > > > HW to use the
> > > > > > framework) for this by:
> > > > > > a) Emulate DWA HW as a separate DPDK process
> > > > > > b) Add drivers/dwa/sw/ and use memif driver so to create a
> > > > > > communication channel between emulated DWA HW process and
> > DPDK
> > > > application.
> > > > > Why use memif driver? Why not ring-pmd?
> > > >
> > > > Planning to emulation DWA accelerator functional model as a separate
> > > > DPDK process in SW case.
> > > You mean the primary and secondary processes correct?
> >
> > Primary and Primary. (DWA emulation as a separate primary process to mimic
> > the real-world scenario)
> >
> > >
> > > > Therefore memif is the ideal choice as it supports zero-copy of the
> > > > data as well.
> > > > https://doc.dpdk.org/guides/nics/memif.html
> > > Zero-copy in memif is nothing but exchanging pointers to shared data.
> > > The rings work across the primary and secondary processes and are always
> > zero-copy.
> > > We are doing some perf comparisons between memif and rings, will let you
> > know once we have the data.
> >
> > Ok.
> > I think between primary to primary memif will be required.
> Agree, memif is easier/required between primary to primary. But, using it with zero-copy would need additional code on the application part in this scenario. The memory being shared needs to be mapped in both the processes.

The existing memif driver does it internally for all memsegs [1]. Even
if it is not, it will be abstracted in profile and driver, to make the
application transparent on transport aspects.

[1]

static int
memif_regions_init(struct rte_eth_dev *dev)
{
        struct pmd_internals *pmd = dev->data->dev_private;
        int ret;

        /*
         * Zero-copy exposes dpdk memory.
         * Each memseg list will be represented by memif region.
         * Zero-copy regions indexing: memseg list idx + 1,
         * as we already have region 0 reserved for descriptors.
         */
        if (pmd->flags & ETH_MEMIF_FLAG_ZERO_COPY) {
                /* create region idx 0 containing descriptors */
                ret = memif_region_init_shm(dev, 0);
                if (ret < 0)
                        return ret;
                ret = rte_memseg_walk(memif_region_init_zc, (void
*)dev->process_private);
                if (ret < 0)
                        return ret;
        } else {
                /* create one memory region contaning rings and buffers */
                ret = memif_region_init_shm(dev, /* has buffers */ 1);
                if (ret < 0)
                        return ret;
        }

        return 0;
}

>
> >
> > >
> > > >
> > > > >
> > > > > > c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd
> > > > > > profile using DPDK libraries for SW driver.
> > > > > >
> > > > > > I think, Item (4) aka SW drivers as useful(We don't need to
> > > > > > implement for all profiles, I think, just for  l3fwd it make
> > > > > > sense to add, to allow to use of the framework in just SW mode).
> > > > > > Is there any opinion on adding item (4) in DPDK? I saw mixed
> > > > > > opinions earlier on this. I would like to understand, Is there
> > > > > > any objection to doing
> > > > > > item(4) in DPDK as it needs a good amount of work and  I don't
> > > > > > want to do throw it away if the community doesn't like this.
> > > > > > Any opinion?
> > > > > >
> > > > > > [1]
> > > > > > http://mails.dpdk.org/archives/dev/2021-October/226070.html
> > > > > >
> > > > > <snip>