RE: [virtio] [PATCH] virtio-net subcommittee proposal

[Parav Pandit <parav@nvidia.com>]

> From: Stefan Hajnoczi <stefanha@redhat.com>
> Sent: Wednesday, April 5, 2023 3:12 PM
> 
> I feel like you're proposing a solution without explaining the problem that it
> solves.
> 
Not every approach of collaboration to start with problem->solution design pattern. :)

> I don't know why a 4-step process or a sub-committee is necessary.
> 
> Why not just schedule a recurring call for face-to-face communication, have
> written discussions on the mailing list, and send spec patches?
> 
Net SC will do virtual recurring call as you suggested (already listed in first proposal email).
And as usual will do written discussions too.

> An answer to that will help me understand why the 4-step process and sub-
> committee are needed.

Why 4 steps?
Because,
0. Amount of changes a virtio net needs to undergo are huge that requires better design approach than just "sending patches".
1. It is inefficient to discuss feature requirements in patch v11. Better discussed, agree/disagree/revise in v1.
2. It is inefficient to introduce a feature in 2022 that cannot work with a Linux kernel algorithm written in year 2018
3. It is efficient to discuss the design, theory of operation, pros and cons before writing the normative spec.
(even in plain text over mailing list).
4. #3 is more important when virtio devices are being implemented as PCI hw devices to utilize the hw and also to gradually build new hw
5. Some of the virtio net features are inter-related and just posting a patch per feature doesn't result in hw efficient spec.
6. Past authors have been in circles unable to modernize virtio spec (to a level where other industry leading devices reached 2 to 3 years back).
Circling in discussions and intermixing things.
7. Reviewers suggesting some "may be" type of random idea, that leads to a spec that no hw vendor is ready to implement it
(reviewer ignoring feedback from hw vendor).
8. When you want to get feedback from hw or sw expert who is not daily consuming the spec or WIP spec, better to communicate with him/her in a way that gives best outcome to the SC.

Hence, 3+1 simple steps bring efficiency that resolves above issues (without intermixing them).

As you know, above 3 step approach is not at all new to leading industry consortiums or organizations.

And why sub-committee?
Because of below reasons.
1. SC members who share common mission and SOP, understands near term and long-term tradeoffs to make forward progress.
2. main TC can have some level of trust on the SC to produce technical content that should be reasonably good because hw vendors, users, sw developers has done the joint design
3. Doing process change at smaller scale, maturing the model and making it to wider use avoids friction at multiple places.
Why? Because some of those issues may have been faced at smaller scale and may be already resolved.

In one line, we anticipate that actual spec patch vN to vN+1 should be around editorial changes and not design changes.