RE: [virtio-comment] [PATCH requirements 0/7] virtio net new features requirements

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Tuesday, June 6, 2023 10:50 PM
> 
> On Fri, Jun 2, 2023 at 6:03âAM Parav Pandit <parav@nvidia.com> wrote:
> >
> > Hi All,
> >
> > This document captures the virtio net device requirements for the
> > upcoming release 1.4 that some of us are currently working on.
> >
> > I would like to capture if there are any other requirements linked to
> > the features captured in this document to consider in the interface design.
> >
> > The objectives are:
> > 1. to consider these requirements in introducing new features listed
> > in the document and work towards the interface design followed by
> > drafting the specification changes.
> >
> > 2. Define practical list of requirements that can be achieved in 1.4
> > timeframe incrementally and also have the ability to implement them.
> >
> > This is not a specification document. It is a pre-work document that
> > helps to understand the draft specification addressing these
> > requirements.
> >
> > Please review.
> >
> > Parav Pandit (7):
> >   net-features: Add requirements document for release 1.4
> >   net-features: Add low latency transmit queue requirements
> >   net-features: Add low latency receive queue requirements
> >   net-features: Add notification coalescing requirements
> >   net-features: Add n-tuple receive flow steering requirements
> >   net-features: Add packet timestamp requirements
> >   net-features: Add header data split requirements
> >
> >  net-workstream/features-1.4.md | 224
> > +++++++++++++++++++++++++++++++++
> 
> I feel that some patches go into too many details of the proposed solution
> which makes it more like RFC instead of a requirement.
> 
> It would be easier to start with to describe why a feature is needed and why it
> can't work well in current spec.

It is worded differently as features/requirements. This probably only applies to tx and rx q.
Rest all are the new features so its not about "cannot work well", because it just doesnt exist.

Instead of explaining negatively "why just yet add new descriptor for transmit timestamp", it is written with optimism in mind, how it should be done in one dma ...

But I agree that small portion can have rationale section, if its unclear.