Minutes of Technical Board Meeting, 2022-06-01

Minutes of Technical Board Meeting, 2022-06-01

[Olivier Matz]

Members Attending
=================

9/11
- Aaron
- Bruce
- Hemant
- Jerin
- Kevin
- Maxime
- Olivier (chair)
- Stephen
- Thomas

NOTE: The technical board meetings are on 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-June-15 @3pm UTC, and will
be chaired by Stephen.

Agenda items
============

1) Update on the tech writer hire
---------------------------------

We are in the process of recruiting a tech writer to enhance DPDK
documentation.

The work group is composed of Nathan, Bruce, Stephen, Thomas.

- 5 reasonnable candidates among 17 applicants
- the list of tasks is defined, it has been estimated to ~250h
- the work should be spread over ~6 months to give enough time
  to the community for feedback
- after some time, if the community is satisfied, the writer can
  suggest new enhancements, reworks, or estimation updates
- in case the community is not satisfied, the contract could end
  before the end of the tasks

2) Discussions about alternatives to bug bounty to find bugs
------------------------------------------------------------

These three ideas were mentionned:

- static analysis tools
- fuzz testing
- adding more tests to CI

Projects from Google Project Zero were also mentionned:
https://github.com/orgs/googleprojectzero/repositories

3) Reminder about API/ABI stability
-----------------------------------

Recently, the vector keyword was removed from rte_altivec.h:
http://git.dpdk.org/dpdk/commit/?id=64fcadeac0f

Since it is a minor (accepted) API breakage, it is the opportunity
to do a reminder about the ABI/API process:

- API breakages are announced and can happen in minor versions
- ABI breakages are announced and can only happen in LTS releases

4) Removal of KNI
-----------------

There is no more maintainer for KNI.

A progressive removal proposal was made:
- add a message at runtime and/or compilation to announce deprecation
- remove KNI example after 22.11
- remove lib + kmod from main repo for 23.11

Bruce recently submitted a doc patchset to explain how to replace
it by virtio-user:
https://patchwork.dpdk.org/project/dpdk/list/?series=23218

The status of pending patches is not obvious. Until now, it was not
announced that new patches won't be integrated. Thomas will open the
discussion.

Re: Minutes of Technical Board Meeting, 2022-06-01

[fengchengwen]

[snip]

> 
> 4) Removal of KNI
> -----------------
> 
> There is no more maintainer for KNI.
> 
> A progressive removal proposal was made:
> - add a message at runtime and/or compilation to announce deprecation
> - remove KNI example after 22.11
> - remove lib + kmod from main repo for 23.11

We still use KNI in some business scenarios, and we want to maintain it in this case.

I recommend Huisong Li (lihuisong@huawei.com) as the new maintainer of the KNI.

He has been involved in the community for several years and submitted some
bugfix patches of KNI.

> 
> Bruce recently submitted a doc patchset to explain how to replace
> it by virtio-user:
> https://patchwork.dpdk.org/project/dpdk/list/?series=23218
> 
> The status of pending patches is not obvious. Until now, it was not
> announced that new patches won't be integrated. Thomas will open the
> discussion.
> 
> .
> 

Re: Minutes of Technical Board Meeting, 2022-06-01

[Stephen Hemminger]

On Thu, 9 Jun 2022 08:41:35 +0800
fengchengwen <fengchengwen@huawei.com> wrote:

> [snip]
> 
> > 
> > 4) Removal of KNI
> > -----------------
> > 
> > There is no more maintainer for KNI.
> > 
> > A progressive removal proposal was made:
> > - add a message at runtime and/or compilation to announce deprecation
> > - remove KNI example after 22.11
> > - remove lib + kmod from main repo for 23.11  
> 
> We still use KNI in some business scenarios, and we want to maintain it in this case.


Why?

> 
> I recommend Huisong Li (lihuisong@huawei.com) as the new maintainer of the KNI.
> 
> He has been involved in the community for several years and submitted some
> bugfix patches of KNI.

KNI has several unfixable architectural issues.
It would never pass a full upstream kernel review.

I hope you realize the security impacts of this.

Re: Minutes of Technical Board Meeting, 2022-06-01

[fengchengwen]

On 2022/6/9 9:31, Stephen Hemminger wrote:
> On Thu, 9 Jun 2022 08:41:35 +0800
> fengchengwen <fengchengwen@huawei.com> wrote:
> 
>> [snip]
>>
>>>
>>> 4) Removal of KNI
>>> -----------------
>>>
>>> There is no more maintainer for KNI.
>>>
>>> A progressive removal proposal was made:
>>> - add a message at runtime and/or compilation to announce deprecation
>>> - remove KNI example after 22.11
>>> - remove lib + kmod from main repo for 23.11  
>>
>> We still use KNI in some business scenarios, and we want to maintain it in this case.
> 
> 
> Why?

The KNI module can be used in following scenarios: when the PF is taken over by the DPDK,
some traffic needs to be transmitted through the kernel protocol stack, we did have this
application scenario.

If do not proactively maintain the KNI, security risks may occur. and this's our starting point.

> 
>>
>> I recommend Huisong Li (lihuisong@huawei.com) as the new maintainer of the KNI.
>>
>> He has been involved in the community for several years and submitted some
>> bugfix patches of KNI.
> 
> KNI has several unfixable architectural issues.

Could you show detail on this ?

> It would never pass a full upstream kernel review.
> 
> I hope you realize the security impacts of this.

Is there another option to act like KNI role ?

> 
> .
> 

Re: Minutes of Technical Board Meeting, 2022-06-01

[Stephen Hemminger]

On Thu, 9 Jun 2022 10:07:28 +0800
fengchengwen <fengchengwen@huawei.com> wrote:

> On 2022/6/9 9:31, Stephen Hemminger wrote:
> > On Thu, 9 Jun 2022 08:41:35 +0800
> > fengchengwen <fengchengwen@huawei.com> wrote:
> >   
> >> [snip]
> >>  
> >>>
> >>> 4) Removal of KNI
> >>> -----------------
> >>>
> >>> There is no more maintainer for KNI.
> >>>
> >>> A progressive removal proposal was made:
> >>> - add a message at runtime and/or compilation to announce deprecation
> >>> - remove KNI example after 22.11
> >>> - remove lib + kmod from main repo for 23.11    
> >>
> >> We still use KNI in some business scenarios, and we want to maintain it in this case.  
> > 
> > 
> > Why?  
> 
> The KNI module can be used in following scenarios: when the PF is taken over by the DPDK,
> some traffic needs to be transmitted through the kernel protocol stack, we did have this
> application scenario.
> 
> If do not proactively maintain the KNI, security risks may occur. and this's our starting point.

What is wrong with TAP or virtio user for your application?

KNI already is a security risk, it implicitly trusts userspace.

> 
> >   
> >>
> >> I recommend Huisong Li (lihuisong@huawei.com) as the new maintainer of the KNI.
> >>
> >> He has been involved in the community for several years and submitted some
> >> bugfix patches of KNI.  
> > 
> > KNI has several unfixable architectural issues.  
> 
> Could you show detail on this ?

The fact that KNI calls user mode holding the RTNL mutex is only one of many
places where KNI trusts user space.

> > It would never pass a full upstream kernel review.
> > 
> > I hope you realize the security impacts of this.  
> 
> Is there another option to act like KNI role ?

Virtio user has been used as a better alternative. Bruce has recently taken
on providing more documentation to make the transistion easier.

One other option is you are free to take KNI on as a project that is maintained
in parallel with DPDK (like TREX and some other packages).

Re: Minutes of Technical Board Meeting, 2022-06-01

[David Marchand]

On Tue, Jun 7, 2022 at 3:48 PM Olivier Matz <olivier.matz@6wind.com> wrote:
> NOTE: Next meeting will be on Wednesday 2021-June-15 @3pm UTC, and will

Looking at recent 2022 minutes, we have a few wrong 2021 dates.
Not a big deal, the next techboard chairs probably won't do the same
mistake :-).

> be chaired by Stephen.


-- 
David Marchand