virtio — archive

[Parav Pandit <mst@redhat.com>]

> From: Michael S. Tsirkin <mst@redhat.com> > Sent: Tuesday, June 6, 2023 6:15 PM > > +# 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? > It matters for requirements, so we produce design that addresses it. We don't want to add config space every growing bit map which may be different between different devices. > > what matters is whether they have to be synchronized with a given queue - I get > it they don't have to. They don't have to be. I don't see how it can be every synchronized. > > > +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? True, but design need to keep this in mind if it has some touch points like of #4 so when migration arrives, it has the building block in place. > 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? > I don't follow the question. When a device migrates from src to dst, group owner needs to know if both side underlying member device has same counter attributes or not. > > > + > > +### 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? > Before. > pls stick to device/driver terminology not guest/host > Yes, will change the GUEST surfaced from the current F_GUEST terminology of the net device. > > +4. le64 rx_pkts: Total packets received by the device > > including dropped ones or not? > Not including. Will add this clarification further in v1. > > + > > +### 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 ... > It is left to the device to implement on what to do on bad desc. > > +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 > Ack. > >