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

[Stefan Hajnoczi <stefanha@redhat.com>]

On Wed, Apr 05, 2023 at 09:16:14PM +0000, Parav Pandit wrote:
> > 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.

This was not mentioned in your original email. Taking virtio-net away
into your own sub-committee and relegating the VIRTIO TC to making
editorial changes is a major change. You need to make an effort to show
why this process change is good for the VIRTIO community, not just for
you.

VIRTIO operates like an open source project. Anyone can propose spec
changes or provide feedback. Whether that person is a hardware
developer, hypervisor developer, driver developer, academic, hobbyist,
etc doesn't matter. You need to accept that there are other
stakeholders and engage in technical discussion with them, not try to
change the process so you can bypass them.

Here is a suggestion for achieving some of what you want within the
existing process:

- Send an email announcing a recurring public call to work on virtio-net
  enhancements suitable for PCI hardware implementation.
- For each call, send an agenda ahead of time listing specific
  virtio-net features that will be discussed.
- Conduct written discussions of requirements and design on the virtio
  mailing list as necessary.
- Agree on how to divide up the spec writing work.
- Spec writers submit the spec changes to the mailing list for review.

This approach will allow you to get people on the same page before the
spec writing and review.

Here is how this approach matches what you've written:

> 0. Amount of changes a virtio net needs to undergo are huge that requires better design approach than just "sending patches".

Requirements and design can be discussed in calls and/or on the mailing
list before sending patches.

> 1. It is inefficient to discuss feature requirements in patch v11. Better discussed, agree/disagree/revise in v1.

Ditto.

> 2. It is inefficient to introduce a feature in 2022 that cannot work with a Linux kernel algorithm written in year 2018

I guess you're referring to a specific incident? I don't know what you
mean though.

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

Handled by call and/or 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

Ditto.

> 5. Some of the virtio net features are inter-related and just posting a patch per feature doesn't result in hw efficient spec.

Ditto.

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

Not solved by my approach and, importantly, also not solved by your
approach. VIRTIO is an open standard and anyone can participate,
including people with different perspectives.

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

Ditto.

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

Seems unrelated. Anyone outside the VIRTIO process can be pulled in (as
long as the OASIS intellectual property rights policy is followed) by
whatever means is most appropriate. I don't think a sub-committee has
any advantage here.

Please let me know if you disagree with these points and I'll try to
understand what is missing from the approach I've suggested.

Stefan

Attachment: signature.asc
Description: PGP signature