virtio — archive

[PATCH requirements 0/7] virtio net new features requirements

From: Michael S. Tsirkin <[email protected]>
To: [email protected]
Date: Tue, 06 Jun 2023 22:15:00 -0000

On Fri, Jun 02, 2023 at 01:02:59AM +0300, Parav Pandit wrote: > Add requirements document template for the virtio net features. > > Add virtio net device counters visible to driver. > > Signed-off-by: Parav Pandit <[email protected]> > --- > net-workstream/features-1.4.md | 36 ++++++++++++++++++++++++++++++++++ > 1 file changed, 36 insertions(+) > create mode 100644 net-workstream/features-1.4.md > > diff --git a/net-workstream/features-1.4.md b/net-workstream/features-1.4.md > new file mode 100644 > index 0000000..03b4eb3 > --- /dev/null > +++ b/net-workstream/features-1.4.md > @@ -0,0 +1,36 @@ > +# 1. Introduction > + > +This document describes the overall requirements for virtio net device > +improvements for upcoming release 1.4. Some of these requirements are > +interrelated and influence the interface design, hence reviewing them > +together is desired while updating the virtio net interface. > + > +# 2. Summary > +1. Device counters visible to the driver > + > +# 3. Requirements > +## 3.1 Device counters > +1. The driver should be able to query the device and/or per vq counters for > + debugging purpose using a control vq command. > +2. The driver should be able to query which counters are supported using a > + control vq command. why does it matter for requirements whether it's a control vq? what matters is whether they have to be synchronized with a given queue - I get it they don't have to. > +3. If this device is migrated between two hosts, the driver should be able > + get the counter values in the destination host from where it was left > + off in the source host. we don't cover migration currently don't see how this is a spec rquirement. unless maybe it's justification for 4? so maybe it means there needs to be a way to set counters? so there's no need to mention migration - just that it should be possible to move counters between devices. > +4. If a virtio device is group member device, a group owner should be able > + to query all the counter attributes using the admin queue command which > + a virtio device will expose via a control vq to the driver. this seems weirdly specific. what is the actual requirement? > + > +### 3.1.1 Per receive queue counters > +1. le64 rx_oversize_pkt_errors: Packet dropped due to receive packet being > + oversize than the buffer size with mergeable buffers how does this differ from 2? > +2. le64 rx_no_buffer_pkt_errors: Packet dropped due to unavailability of the > + buffer in the receive queue > +3. le64 rx_gro_pkts: Packets treated as guest GSO sequence by the device what does this mean exactly? packets before or after they are combined? pls stick to device/driver terminology not guest/host > +4. le64 rx_pkts: Total packets received by the device including dropped ones or not? > + > +### 3.1.2 Per transmit queue counters > +1. le64 tx_bad_desc_errors: Descriptors dropped by the device due to errors in > + descriptors since when do we drop packets on error in descriptor? we just as likely stall ... > +2. le64 tx_gso_pkts: Packets send as host GSO sequence same questions as gro > +3. le64 tx_pkts: Total packets send by the device sent > -- > 2.26.2 > > > This publicly archived list offers a means to provide input to the > OASIS Virtual I/O Device (VIRTIO) TC. > > In order to verify user consent to the Feedback License terms and > to minimize spam in the list archive, subscription is required > before posting. > > Subscribe: [email protected] > Unsubscribe: [email protected] > List help: [email protected] > List archive: https://lists.oasis-open.org/archives/virtio-comment/ > Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf > List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists > Committee: https://www.oasis-open.org/committees/virtio/ > Join OASIS: https://www.oasis-open.org/join/ >