DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
@ 2021-11-02 15:39 Ananyev, Konstantin
  2021-11-11 11:44 ` Jerin Jacob
  0 siblings, 1 reply; 12+ messages in thread
From: Ananyev, Konstantin @ 2021-11-02 15:39 UTC (permalink / raw)
  To: dev; +Cc: techboard

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-02 15:39 [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27 Ananyev, Konstantin
@ 2021-11-11 11:44 ` Jerin Jacob
  2021-11-11 12:32   ` Ananyev, Konstantin
  2021-11-12  2:24   ` Honnappa Nagarahalli
  0 siblings, 2 replies; 12+ messages in thread
From: Jerin Jacob @ 2021-11-11 11:44 UTC (permalink / raw)
  To: Ananyev, Konstantin, Thomas Monjalon, Ferruh Yigit,
	Ajit Khaparde, Andrew Boyer, Andrew Rybchenko, Beilei Xing,
	Richardson, Bruce, Chas Williams, Xia, Chenbo, Ciara Loftus,
	Devendra Singh Rawat, Ed Czeck, Evgeny Schemeilin, Gaetan Rivet,
	Gagandeep Singh, Guoyang Zhou, Haiyue Wang, Harman Kalra,
	heinrich.kuhn, Hemant Agrawal, Hyong Youb Kim, Igor Chauskin,
	Igor Russkikh, Jakub Grajciar, Jasvinder Singh, Jian Wang,
	Jiawen Wu, Jingjing Wu, John Daley, John Miller,
	John W. Linville, Wiles, Keith, Kiran Kumar K, Lijun Ou,
	Liron Himi, Long Li, Marcin Wojtas, Martin Spinler, Matan Azrad,
	Matt Peters, Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
	Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Rosen Xu, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Xiao Wang,
	Xiaoyun Wang, Yisen Zhuang, Yong Wang, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Anatoly Burakov,
	Cristian Dumitrescu, Honnappa Nagarahalli, Mattias Rönnblom,
	Ruifeng Wang (Arm Technology China),
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini
  Cc: dev, techboard

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-11 11:44 ` Jerin Jacob
@ 2021-11-11 12:32   ` Ananyev, Konstantin
  2021-11-12  0:56     ` Honnappa Nagarahalli
  2021-11-12  2:24   ` Honnappa Nagarahalli
  1 sibling, 1 reply; 12+ messages in thread
From: Ananyev, Konstantin @ 2021-11-11 12:32 UTC (permalink / raw)
  To: Jerin Jacob, Thomas Monjalon, Yigit, Ferruh, Ajit Khaparde,
	Andrew Boyer, Andrew Rybchenko, Xing, Beilei, Richardson, Bruce,
	Chas Williams, Xia, Chenbo, Loftus,  Ciara, Devendra Singh Rawat,
	Ed Czeck, Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh,
	Guoyang Zhou, Wang, Haiyue, Harman Kalra, heinrich.kuhn,
	Hemant Agrawal, Hyong Youb Kim, Igor Chauskin, Igor Russkikh,
	Jakub Grajciar, Singh, Jasvinder, Jian Wang, Jiawen Wu, Wu,
	Jingjing, Daley, John, John Miller, John W. Linville, Wiles,
	Keith, Kiran Kumar K, Lijun Ou, Liron Himi, Long Li,
	Marcin Wojtas, Martin Spinler, Matan Azrad, Peters, Matt,
	Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Yang, Qiming, Zhang,
	Qi Z, Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Xu, Rosen, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Wang, Xiao W,
	Xiaoyun Wang, Yisen Zhuang, Wang, Yong, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Burakov, Anatoly,
	Dumitrescu, Cristian, Honnappa Nagarahalli, mattias.ronnblom,
	Ruifeng Wang (Arm Technology China),
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini
  Cc: dev, techboard



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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-11 12:32   ` Ananyev, Konstantin
@ 2021-11-12  0:56     ` Honnappa Nagarahalli
  2021-11-12  1:46       ` Ananyev, Konstantin
  0 siblings, 1 reply; 12+ messages in thread
From: Honnappa Nagarahalli @ 2021-11-12  0:56 UTC (permalink / raw)
  To: Ananyev, Konstantin, Jerin Jacob, thomas, Yigit,  Ferruh,
	Ajit Khaparde (ajit.khaparde@broadcom.com),
	Andrew Boyer, Andrew Rybchenko, Xing, Beilei, Richardson, Bruce,
	Chas Williams, Xia, Chenbo, Loftus, Ciara, Devendra Singh Rawat,
	Ed Czeck, Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh,
	Guoyang Zhou, Wang, Haiyue, Harman Kalra, heinrich.kuhn,
	hemant.agrawal, Hyong Youb Kim, Igor Chauskin, Igor Russkikh,
	Jakub Grajciar, Singh, Jasvinder, Jian Wang, Jiawen Wu, Wu,
	Jingjing, Daley, John, John Miller, John W. Linville, Wiles,
	Keith, Kiran Kumar K, Lijun Ou, Liron Himi, Long Li,
	Marcin Wojtas, Martin Spinler, Matan Azrad, Peters, Matt,
	Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Yang, Qiming, Zhang,
	Qi Z, Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Xu, Rosen, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Wang, Xiao W,
	Xiaoyun Wang, Yisen Zhuang, Wang, Yong, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Burakov, Anatoly,
	Dumitrescu, Cristian, mattias.ronnblom, Ruifeng Wang,
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini
  Cc: dev, techboard, nd, nd

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-12  0:56     ` Honnappa Nagarahalli
@ 2021-11-12  1:46       ` Ananyev, Konstantin
  2021-11-12  6:19         ` Jerin Jacob
  0 siblings, 1 reply; 12+ messages in thread
From: Ananyev, Konstantin @ 2021-11-12  1:46 UTC (permalink / raw)
  To: Honnappa Nagarahalli, Jerin Jacob, thomas, Yigit,  Ferruh,
	Ajit Khaparde (ajit.khaparde@broadcom.com),
	Andrew Boyer, Andrew Rybchenko, Xing, Beilei, Richardson, Bruce,
	Chas Williams, Xia, Chenbo, Loftus, Ciara, Devendra Singh Rawat,
	Ed Czeck, Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh,
	Guoyang Zhou, Wang, Haiyue, Harman Kalra, heinrich.kuhn,
	hemant.agrawal, Hyong Youb Kim, Igor Chauskin, Igor Russkikh,
	Jakub Grajciar, Singh, Jasvinder, Jian Wang, Jiawen Wu, Wu,
	Jingjing, Daley, John, John Miller, John W. Linville, Wiles,
	Keith, Kiran Kumar K, Lijun Ou, Liron Himi, Long Li,
	Marcin Wojtas, Martin Spinler, Matan Azrad, Peters, Matt,
	Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Yang, Qiming, Zhang,
	Qi Z, Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Xu, Rosen, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Wang, Xiao W,
	Xiaoyun Wang, Yisen Zhuang, Wang, Yong, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Burakov, Anatoly,
	Dumitrescu, Cristian, mattias.ronnblom, Ruifeng Wang,
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini
  Cc: dev, techboard, nd, nd


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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-11 11:44 ` Jerin Jacob
  2021-11-11 12:32   ` Ananyev, Konstantin
@ 2021-11-12  2:24   ` Honnappa Nagarahalli
  2021-11-12  6:26     ` Jerin Jacob
  1 sibling, 1 reply; 12+ messages in thread
From: Honnappa Nagarahalli @ 2021-11-12  2:24 UTC (permalink / raw)
  To: Jerin Jacob, Ananyev, Konstantin, thomas, Ferruh Yigit,
	Ajit Khaparde (ajit.khaparde@broadcom.com),
	Andrew Boyer, Andrew Rybchenko, Beilei Xing, Richardson, Bruce,
	Chas Williams, Xia, Chenbo, Ciara Loftus, Devendra Singh Rawat,
	Ed Czeck, Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh,
	Guoyang Zhou, Haiyue Wang, Harman Kalra, heinrich.kuhn,
	hemant.agrawal, Hyong Youb Kim, Igor Chauskin, Igor Russkikh,
	Jakub Grajciar, Jasvinder Singh, Jian Wang, Jiawen Wu,
	Jingjing Wu, John Daley, John Miller, John W. Linville, Wiles,
	Keith, Kiran Kumar K, Lijun Ou, Liron Himi, Long Li,
	Marcin Wojtas, Martin Spinler, Matan Azrad, Matt Peters,
	Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
	Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Rosen Xu, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Xiao Wang,
	Xiaoyun Wang, Yisen Zhuang, Yong Wang, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Anatoly Burakov,
	Cristian Dumitrescu, Mattias Rönnblom, Ruifeng Wang,
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini
  Cc: dev, techboard, nd, nd

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-12  1:46       ` Ananyev, Konstantin
@ 2021-11-12  6:19         ` Jerin Jacob
  0 siblings, 0 replies; 12+ messages in thread
From: Jerin Jacob @ 2021-11-12  6:19 UTC (permalink / raw)
  To: Ananyev, Konstantin
  Cc: Honnappa Nagarahalli, thomas, Yigit, Ferruh,
	Ajit Khaparde (ajit.khaparde@broadcom.com),
	Andrew Boyer, Andrew Rybchenko, Xing, Beilei, Richardson, Bruce,
	Chas Williams, Xia, Chenbo, Loftus, Ciara, Devendra Singh Rawat,
	Ed Czeck, Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh,
	Guoyang Zhou, Wang, Haiyue, Harman Kalra, heinrich.kuhn,
	hemant.agrawal, Hyong Youb Kim, Igor Chauskin, Igor Russkikh,
	Jakub Grajciar, Singh, Jasvinder, Jian Wang, Jiawen Wu, Wu,
	Jingjing, Daley, John, John Miller, John W. Linville, Wiles,
	Keith, Kiran Kumar K, Lijun Ou, Liron Himi, Long Li,
	Marcin Wojtas, Martin Spinler, Matan Azrad, Peters, Matt,
	Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Yang, Qiming, Zhang,
	Qi Z, Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Xu, Rosen, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Wang, Xiao W,
	Xiaoyun Wang, Yisen Zhuang, Wang, Yong, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Burakov, Anatoly,
	Dumitrescu, Cristian, mattias.ronnblom, Ruifeng Wang,
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini, dev, techboard, nd

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-12  2:24   ` Honnappa Nagarahalli
@ 2021-11-12  6:26     ` Jerin Jacob
  2021-11-18 15:13       ` Honnappa Nagarahalli
  0 siblings, 1 reply; 12+ messages in thread
From: Jerin Jacob @ 2021-11-12  6:26 UTC (permalink / raw)
  To: Honnappa Nagarahalli
  Cc: Ananyev, Konstantin, thomas, Ferruh Yigit,
	Ajit Khaparde (ajit.khaparde@broadcom.com),
	Andrew Boyer, Andrew Rybchenko, Beilei Xing, Richardson, Bruce,
	Chas Williams, Xia, Chenbo, Ciara Loftus, Devendra Singh Rawat,
	Ed Czeck, Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh,
	Guoyang Zhou, Haiyue Wang, Harman Kalra, heinrich.kuhn,
	hemant.agrawal, Hyong Youb Kim, Igor Chauskin, Igor Russkikh,
	Jakub Grajciar, Jasvinder Singh, Jian Wang, Jiawen Wu,
	Jingjing Wu, John Daley, John Miller, John W. Linville, Wiles,
	Keith, Kiran Kumar K, Lijun Ou, Liron Himi, Long Li,
	Marcin Wojtas, Martin Spinler, Matan Azrad, Matt Peters,
	Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
	Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Rosen Xu, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Xiao Wang,
	Xiaoyun Wang, Yisen Zhuang, Yong Wang, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Anatoly Burakov,
	Cristian Dumitrescu, Mattias Rönnblom, Ruifeng Wang,
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini, dev, techboard, nd

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>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-12  6:26     ` Jerin Jacob
@ 2021-11-18 15:13       ` Honnappa Nagarahalli
  2021-11-18 16:27         ` Jerin Jacob
  0 siblings, 1 reply; 12+ messages in thread
From: Honnappa Nagarahalli @ 2021-11-18 15:13 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Ananyev, Konstantin, thomas, Ferruh Yigit,
	Ajit Khaparde (ajit.khaparde@broadcom.com),
	Andrew Boyer, Andrew Rybchenko, Beilei Xing, Richardson, Bruce,
	Chas Williams, Xia, Chenbo, Ciara Loftus, Devendra Singh Rawat,
	Ed Czeck, Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh,
	Guoyang Zhou, Haiyue Wang, Harman Kalra, heinrich.kuhn,
	hemant.agrawal, Hyong Youb Kim, Igor Chauskin, Igor Russkikh,
	Jakub Grajciar, Jasvinder Singh, Jian Wang, Jiawen Wu,
	Jingjing Wu, John Daley, John Miller, John W. Linville, Wiles,
	Keith, Kiran Kumar K, Lijun Ou, Liron Himi, Long Li,
	Marcin Wojtas, Martin Spinler, Matan Azrad, Matt Peters,
	Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
	Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Rosen Xu, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Xiao Wang,
	Xiaoyun Wang, Yisen Zhuang, Yong Wang, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Anatoly Burakov,
	Cristian Dumitrescu, Mattias Rönnblom, Ruifeng Wang,
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini, dev, techboard, nd, nd

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-18 15:13       ` Honnappa Nagarahalli
@ 2021-11-18 16:27         ` Jerin Jacob
  2021-11-18 20:07           ` Honnappa Nagarahalli
  0 siblings, 1 reply; 12+ messages in thread
From: Jerin Jacob @ 2021-11-18 16:27 UTC (permalink / raw)
  To: Honnappa Nagarahalli
  Cc: Ananyev, Konstantin, thomas, Ferruh Yigit,
	Ajit Khaparde (ajit.khaparde@broadcom.com),
	Andrew Boyer, Andrew Rybchenko, Beilei Xing, Richardson, Bruce,
	Chas Williams, Xia, Chenbo, Ciara Loftus, Devendra Singh Rawat,
	Ed Czeck, Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh,
	Guoyang Zhou, Haiyue Wang, Harman Kalra, heinrich.kuhn,
	hemant.agrawal, Hyong Youb Kim, Igor Chauskin, Igor Russkikh,
	Jakub Grajciar, Jasvinder Singh, Jian Wang, Jiawen Wu,
	Jingjing Wu, John Daley, John Miller, John W. Linville, Wiles,
	Keith, Kiran Kumar K, Lijun Ou, Liron Himi, Long Li,
	Marcin Wojtas, Martin Spinler, Matan Azrad, Matt Peters,
	Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
	Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Rosen Xu, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Xiao Wang,
	Xiaoyun Wang, Yisen Zhuang, Yong Wang, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Anatoly Burakov,
	Cristian Dumitrescu, Mattias Rönnblom, Ruifeng Wang,
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini, dev, techboard, nd

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>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-18 16:27         ` Jerin Jacob
@ 2021-11-18 20:07           ` Honnappa Nagarahalli
  2021-11-19  4:34             ` Jerin Jacob
  0 siblings, 1 reply; 12+ messages in thread
From: Honnappa Nagarahalli @ 2021-11-18 20:07 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Ananyev, Konstantin, thomas, Ferruh Yigit,
	Ajit Khaparde (ajit.khaparde@broadcom.com),
	Andrew Boyer, Andrew Rybchenko, Beilei Xing, Richardson, Bruce,
	Chas Williams, Xia, Chenbo, Ciara Loftus, Devendra Singh Rawat,
	Ed Czeck, Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh,
	Guoyang Zhou, Haiyue Wang, Harman Kalra, heinrich.kuhn,
	hemant.agrawal, Hyong Youb Kim, Igor Chauskin, Igor Russkikh,
	Jakub Grajciar, Jasvinder Singh, Jian Wang, Jiawen Wu,
	Jingjing Wu, John Daley, John Miller, John W. Linville, Wiles,
	Keith, Kiran Kumar K, Lijun Ou, Liron Himi, Long Li,
	Marcin Wojtas, Martin Spinler, Matan Azrad, Matt Peters,
	Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
	Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Rosen Xu, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Xiao Wang,
	Xiaoyun Wang, Yisen Zhuang, Yong Wang, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Anatoly Burakov,
	Cristian Dumitrescu, Mattias Rönnblom, Ruifeng Wang,
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini, dev, techboard, nd, nd

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27
  2021-11-18 20:07           ` Honnappa Nagarahalli
@ 2021-11-19  4:34             ` Jerin Jacob
  0 siblings, 0 replies; 12+ messages in thread
From: Jerin Jacob @ 2021-11-19  4:34 UTC (permalink / raw)
  To: Honnappa Nagarahalli
  Cc: Ananyev, Konstantin, thomas, Ferruh Yigit,
	Ajit Khaparde (ajit.khaparde@broadcom.com),
	Andrew Boyer, Andrew Rybchenko, Beilei Xing, Richardson, Bruce,
	Chas Williams, Xia, Chenbo, Ciara Loftus, Devendra Singh Rawat,
	Ed Czeck, Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh,
	Guoyang Zhou, Haiyue Wang, Harman Kalra, heinrich.kuhn,
	hemant.agrawal, Hyong Youb Kim, Igor Chauskin, Igor Russkikh,
	Jakub Grajciar, Jasvinder Singh, Jian Wang, Jiawen Wu,
	Jingjing Wu, John Daley, John Miller, John W. Linville, Wiles,
	Keith, Kiran Kumar K, Lijun Ou, Liron Himi, Long Li,
	Marcin Wojtas, Martin Spinler, Matan Azrad, Matt Peters,
	Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
	Pradeep Kumar Nalla, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
	Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
	Rosen Xu, Sachin Saxena, Satha Koteswara Rao Kottidi,
	Shahed Shaikh, Shai Brandes, Shepard Siegel,
	Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
	Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
	Veerasenareddy Burru, Viacheslav Ovsiienko, Xiao Wang,
	Xiaoyun Wang, Yisen Zhuang, Yong Wang, Ziyang Xuan,
	Prasun Kapoor, nadavh, Satananda Burla, Narayana Prasad,
	Akhil Goyal, Ray Kinsella, Dmitry Kozlyuk, Anatoly Burakov,
	Cristian Dumitrescu, Mattias Rönnblom, Ruifeng Wang,
	David Christensen, Olivier Matz, Jayatheerthan, Jay,
	Ashwin Sekhar Thalakalath Kottilveetil, Pavan Nikhilesh,
	Elena Agostini, dev, techboard, nd

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>

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-11-19  4:35 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-02 15:39 [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27 Ananyev, Konstantin
2021-11-11 11:44 ` Jerin Jacob
2021-11-11 12:32   ` Ananyev, Konstantin
2021-11-12  0:56     ` Honnappa Nagarahalli
2021-11-12  1:46       ` Ananyev, Konstantin
2021-11-12  6:19         ` Jerin Jacob
2021-11-12  2:24   ` Honnappa Nagarahalli
2021-11-12  6:26     ` Jerin Jacob
2021-11-18 15:13       ` Honnappa Nagarahalli
2021-11-18 16:27         ` Jerin Jacob
2021-11-18 20:07           ` Honnappa Nagarahalli
2021-11-19  4:34             ` Jerin Jacob

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).