>>>>> Most of the existing drivers enable the napi(s) during the open() phase, >>>>> IIUC to avoid scheduling napi operations for devices that might never >>>>> get used. But here maybe there is a specific reason to do it this way? >>>>> >>>> >>>> I do not have idea. I moved to open() and something stopped to work. I >>>> am investigating it. >>>> >>> >>> On a second thought, it may be wiser to have the napis enabled on probe, >>> to drop the incoming messages even when the interface is brought down. >> >> It's a while since then but I wanted to drop messages not having lurking a 3 >> hours old cooling water temperature in some virtio message buffer being >> misinterpreted as an actual value. May have the disadvantage to cause load >> when the driver is not open-ed. But I see you also thought about 3 hours old >> outdated values now which may cause trouble. >> > > I am stil thinking about this. We are sending a ctrl message with > VIRTIO_CAN_SET_CTRL_MODE_STOP, so new frames shouldn't be arriving while > the interface is stopped (i.e., once it is brought down). May it be > sufficient to consume and re-queue all pending vring elements as part of > virtio_can_stop()?
The NAPI operations are only scheduled by interrupt functions virtio_can_tx_intr() and virtio_can_rx_intr(). When STOPPED, and this is the initial state, there will no TX messages and a well behaving virtio CAN device does also not send RX messages. So no interrupts and no additional load by scheduling NAPI when not STARTED. Having napi_enable() in virtio_can_probe() we conveniently get rid of messages received in a race when transitioning from STARTED to STOPPED and than there should be silence. A misbehaving device may cause RX load in STOPPED but this was a device issue. Under normal circumstances no resources (especially CPU) is wasted. But to "consume" all queue and re-queue is a bad idea. After made avail the element belongs to the device until the device gives it back to the driver by marking it as used (e.g. putting it into the used queue). It is not possible to steal queue elements from the device during live state. So this "consume" and "re-queue" is something I do not see as being feasible. Saw in the meantime that a new driver (V7) was sent and was happy not to see some queue stunts just to move napi_enable() around for no really good reason at all.
