[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [PATCH v3] virtio-net: support the virtqueue coalescing moderation
> Not good. I feel we must come up with spec that is backwards compatible. > Hmm, maybe this is why Parav kept talking about modes. > I did not realize at the time, sorry Parav. > > I still feel modes are not the best way to describe things so I propose this: > - in addition to per vq parameters, device that supports global TX/RX > commands and ring reset maintains two sets of default parameters: for RX and TX > - existing commands change default and change all enabled vqs > of the correct type (RX/TX) to the same value > - vq reset changes a vq to the default > - device reset changes defaults to 0 and changes all vqs to 0 > > note how defaults are only used for ring reset. is "vq reset parameter" > a better name? I feel we will repeat "reset" too many times in a > sentence if we call it that though. > > So fundamentally the only change is with RING_RESET, then > default is not always 0, it can be set by the global command. I like the idea, maintaining default coalescing parameters is compatible with vq reset. "After a queue has been reset by the driver, the device MUST NOT execute any requests from that virtqueue, or notify the driver for it. The device MUST reset any state of a virtqueue to the *default state*, including the available state and the used state." I wonder if some of that should be included in my patch. Most of that is not relevant before introducing the per vq command. So maybe I could just mention in the device conformance that: "Coalescing parameters MUST/SHOULD persist a virtqueue reset." And then Heng can edit/add on top of that. Now that the existing commands do more than just iterating through all the virtqueues, maybe we should be able to modify all virtqueues with VIRTIO_NET_F_VQ_NOTF_COAL. I think that using a special vqn is messy, we can split "le32 reserved" to "le16 flags" and "le16 reserved". Then we can have: - A flag to apply parameters to all receive VQs, vqn is ignored in this case. (same as VIRTIO_NET_CTRL_NOTF_COAL_RX_SET but without changing the default parameters). - A flag to apply parameters to all transmit VQs, vqn is ignored in this case. (same as VIRTIO_NET_CTRL_NOTF_COAL_TX_SET but without changing the default parameters). And maybe a flag to apply to all vqs (transmit + receive), I actually am not sure how useful this is..
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]