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

[Cornelia Huck <cohuck@redhat.com>]

On Wed, Apr 12 2023, Halil Pasic <pasic@linux.ibm.com> wrote:

> On Sat, 8 Apr 2023 15:40:55 +0000
> Parav Pandit <parav@nvidia.com> wrote:
>
>> > From: Halil Pasic <pasic@linux.ibm.com>
>> > Sent: Friday, April 7, 2023 12:08 AM  
>> And those TC members who have interest in net sc work, will join net SC anyway.
>
> I object to that assumption.

Indeed. There's a huge difference between "I am interested in virtio-net
specifically, and want to participate in a group that aims to specify
new virtio-net features" and "I want to make sure that the spec as a
whole is in good shape" -- the latter surely includes looking at
virtio-net changes, but it does not make sense to require people to join
a subgroup for that.

>
>> 
>> > Please note that this is scoped to "the standard functionality across devices" for
>> > some reason.
>> >  
>> How RSS hashing done or how/when packet time stamp done is related to sound device?
>> I likely misunderstanding your above point.
>> Can you please explain?
>>  
>
> BTW you tend to quote my words, but not the words I comment on, so yet
> again I have to look at the previous mail, and quote from it to be
> able to start explaining.
>
> """
> 3rd, main proposal clearly mentions the function of SC as first point,
> snippet:
>
> " Consults virtio tc, feed and use master virtio specification for
>    the standard functionality across devices when applicable"
> """
>
> In my response, I was referring to that sentence. In the meanwhile I'm
> not sure how to read that sentence, but I'm pretty sure the part "for
> the standard functionality across devices when applicable" is about
> restricting the scope of some thing.
>
> Could it be rewritten like:
>   (1) Consult (the) virtio tc for the standard functionality across all
>   devices when applicable. Feed and use (the) master virtio specification
>   for the standard functionality when applicable.
> or rather like
>   (2) Consult (the) virtio tc. Feed and use (the) master virtio
>   specification for the standard functionality accross devices when
>   applicable. 
> or rather like
>   (3) Consult (the) virtio tc. Feed (the) master virtio specification,
>   and use the master specification for the standard functionality
>   accross devices when applicable. 
> ?
>
> I assumed the (1) reading is the closest to what the authors of that
> sentence intended to express. Because, (2) and (3) for example beg
> the question "Consult the Virtio TC on what?" And in that case
> " for the standard functionality accross devices when applicable" tells
> us __on what__ and __when__ is the SC intent on consulting the virtio
> TC and feed and use the "master virtio specification".
>
> In any case all this is not all that important. I invested the time to
> explain out of respect and courtesy. I hope it is not "straw man".

To be honest, I'm not sure what feeding and using is supposed to mean
anyway -- any change needs to be discussed on the lists, and while it
makes sense that people interested in network functionality specifically
concentrate on that, everything needs to be approved by the TC in any
case. Making the larger forum explicitly aware of changes that affect
areas outside of virtio-net even if dealing with something that
implements a new networking feature is just something I'd expect to
happen out of common sense?

>> I think I missed to include the note that Net SC keep the existing virtio spec changes by non virtio TC members open.
>> (not the role or intention of Net SC to define what its parent virtio tc can/cannot do).
>> 
>
> And I still fail to understand what prevents you guys from
> doing the technical work you want to do, having the meetings you want
> to have, and submitting change requests for the one and single Virtio
> Specification (not to some sort of **master** virtio specification as
> implied by the sentence I have quoted above) using the current framework.

Indeed, me too. "We want a forum to discuss net features and have
regular calls" is fine, and doesn't really need any resolution by the TC
(unless we want an explicit pointer in the charter), but any proposal
the people in that group come up with just needs to go via the usual way.

>> > I do see why do you want to have some sort of a tag. But I fail to understand
>> > why do you insist on the tag being "Net SC", and on establishing more or less
>> > formal processes around it.
>> >   
>> In other industry consortiums that I am directly/indirectly involved such as siov, pci, nvme etc,
>> It is named as "working group".
>> On asking OASIS about it, they suggested the equivalent is subcommittee in OASIS for such focused project work.
>> 
>
> Stefan made an effort at explaining how the Virtio specification is
> developed currently. That, along with the official documents around
> OASIS and Virtio TC should be enough to actually figure it out. 
>
> I'm not directly involved with the 'other industry consortium' you
> mentioned above, and thus I'm not really familiar with how those
> operate. But I have the feeling there are substantial differences
> in how some PCI SIG (by the way SIG stands for Special Interest
> Group) specifications are developed, and how the Virtio Specification is
> developed. Trying to transfer your experience from there to Virtio might
> not always be the best idea.

Agreed.

> On a side note, I'm (as a voting member of the Virtio TC) happy to
> discuss on improving that process, and I believe this is true for the
> majority of the TC members -- but that is just my gut feeling.

Yes, that is my guess as well.

>> > In my understanding, what you really want is a "virtio-net interest group".  
>> 
>> If you care a lot for English, 
>
> I don't really care that much for English. It is my forth
> language, and I don't think I am very good at it. I care a lot
> for specifications, and for clarity regardless of the language
> in use. 
>
>> you trivialize it a lot by calling it out an "interest group".
>
> Sorry I must apologize if "interest group" is indeed a trivialization.
> No offense intended. I did a quick search and according to
> https://www.oxfordlearnersdictionaries.com/definition/english/interest-group
> the meaning ("a group of people who work together to achieve something
> that they are particularly interested in") seems to somewhat fit...

[side note: I don't see "interest group" as any kind of trivialization...]

>
>> so I must say it is not a "interest group".
>> It is a "work group" to produce work as part of virtio tc.
>
> ... but for some reason you seem to strongly prefer work group. So fine
> let us call it a "work group" then. In any case, I believe you can
> organize an informal work group with your (slightly modified) charter, do
> your meetings, do your organized work, and contribute it to the virtio
> community, and not lose a thing over having a formal NET SC.  And if your
> group figures out that there is an even better way to do the organized
> work, you can just do it. You don't have to come back to the TC to vote
> about the change (of your constitutional document), or about dissolving
> the current subcommittee, and creating an new one with new rules and/or
> new mission. (I have to admit I didn't study the procedural details.)

Agreed.

>
>> (without taking away ability for non TC members to contribute to virtio spec).
>
> Well, that seems to somewhat contradict with what you have laid out up
> till now. I.e. to contribute to the virtio-net part of the virtio spec
> one is **expected** to be a NET SC member, and per definition all SC
> members must be TC members.
>
>> 
>> > According to my understanding of how the standardization process for virtio
>> > works, it does not impose restrictions on the process of coming up with a
>> > proposal (patches), nor is the circle of entities who are allowed to submit
>> > proposals. I believe all of the TC members would be very happy about very high
>> > quality proposals that require no discussion, no changes, and can be voted in
>> > without doing more iterations. It would indeed reduce workload. I don't thing
>> > that talking to other people before submitting a proposal or in between
>> > submitting proposals is disallowed. But that is just my opinion and I'm no
>> > lawyer.
>> > 
>> > In summary, this "virtio-net subcommitee" is at idea, in its current form, and
>> > with the current arguments presented has my NAK.  
>> 
>> As I responded to Stefan,
>> 
>> Net SC intents to do structured work in good spirit.
>
> I'm not opposing 'structured work in good spirit', On the
> contrary! But I do fail to see the benefits of creating a formal
> subcommittee for that.
>
>> 
>> I don't see Net SC can success in execution if you or Stefan see it as separate body from virtio TC.
>> (and net sc is not/cannot be different part from virtio tc).
>> 
>> In our view those existing virtio TC members who really care for improving the virio-net as we listed in mission & SOP, should join the net SC.
>> 
>> Being new to virtio tc, I am familiar with contribution of Michael and Jason Wang in improving virio net.
>> So, a humble request to both to join if they can help to improve the pace towards described mission, SOP.
>> 
>
> Sorry, I don't think I have voted about creating the so called NET SC. So
> form where I stand, the NET SC does not exist. And one can not join
> something that does not exist. We are still discussing if creating
> a the NET SC is a good idea or not. I see, that you Parav are 
> convinced it is, but I'm not.

Me neither.

>
>> And same humble request to all virtio tc members who wants to give early feedback (during requirements, design, WIP spec patches) to Net SC, should also join.
>> 
>
> And what about any virtio TC non-members. Should they join as well? 

So, how are TC non-members actually supposed to interact with that
special net group? Currently, we have the virtio-comment list to send
comments, and the virtio-dev list to discuss implementation. Would
non-members use the same lists to interact with the net group as well?
They cannot join a SC if they are not TC members.

And, as I already wrote above, "if you want to give early feedback, you
should join the net group" is not a good requirement: everybody should
be able to see and discuss any proposals easily, not the least because
feedback like "hey, we want to do something similar in $OTHER_DEVICE as
well, let's come up with a common feature" or "doing it like that will
have negative effects, as we already found out when trying to implement
$OTHER_FEATURE" should come in as early as possible.