search for: cvq

On Thu, 13 Apr 2023 14:40:27 +0800, Jason Wang <jasowang at redhat.com> wrote: > We used to busy waiting on the cvq command this tends to be > problematic since there no way for to schedule another process which > may serve for the control virtqueue. This might be the case when the > control virtqueue is emulated by software. This patch switches to use > completion to allow the CPU to sleep instead o...

On Thu, Apr 13, 2023 at 3:31?PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > On Thu, 13 Apr 2023 14:40:27 +0800, Jason Wang <jasowang at redhat.com> wrote: > > We used to busy waiting on the cvq command this tends to be > > problematic since there no way for to schedule another process which > > may serve for the control virtqueue. This might be the case when the > > control virtqueue is emulated by software. This patch switches to use > > completion to allow the CP...

...0WvjGRr3whU+QasUg at mail.gmail.com/T/ > > > > > > > > > > Jason promised to post a new version of that patch. > > > > > Right Jason? > > > > > > > > Yes. > > > > > > > > > For now let's make sure CVQ feature flag is off? > > > > > > > > We can do that and relax on top of my patch. > > > > > > I agree? Do you prefer a features negotiation, or failing init (like > > > done for VERSION_1) if the VDUSE application advertises CVQ? > > >...

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use sleep instead of busy polling. In this version, I take a step back: the hardening part is not implemented and leave for future investigation. We u...

.../lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg at mail.gmail.com/T/ >>>> >>>> Jason promised to post a new version of that patch. >>>> Right Jason? >>> >>> Yes. >>> >>>> For now let's make sure CVQ feature flag is off? >>> >>> We can do that and relax on top of my patch. >> >> I agree? Do you prefer a features negotiation, or failing init (like >> done for VERSION_1) if the VDUSE application advertises CVQ? >> >> Thanks, >> Maxime > &g...

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use sleep + timeout instead of busy polling. Please review. Thanks Changes since RFC: - switch to use BAD_RING in virtio_break_device() - check vi...

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use cond_resched() in the waiting loop. Before doing this we need first make sure the cvq command is not executed in atomic environment, so we need fi...

Hi Jason, On 4/13/23 08:40, Jason Wang wrote: > Hi all: > > The code used to busy poll for cvq command which turns out to have > several side effects: > > 1) infinite poll for buggy devices > 2) bad interaction with scheduler > > So this series tries to use sleep instead of busy polling. In this > version, I take a step back: the hardening part is not implemented and &...

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use cond_resched() in the waiting loop. Before doing this we need first make sure the cvq command is not executed in atomic environment, so we need fi...

...; [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg at mail.gmail.com/T/ > > > > > > Jason promised to post a new version of that patch. > > > Right Jason? > > > > Yes. > > > > > For now let's make sure CVQ feature flag is off? > > > > We can do that and relax on top of my patch. > > I agree? Do you prefer a features negotiation, or failing init (like > done for VERSION_1) if the VDUSE application advertises CVQ? > > Thanks, > Maxime Unfortunately guests fail probe if...

...Jason Wang wrote: > > > > Adding cond_resched() to the command waiting loop for a better > > co-operation with the scheduler. This allows to give CPU a breath to > > run other task(workqueue) instead of busy looping when preemption is > > not allowed on a device whose CVQ might be slow. > > > > Signed-off-by: Jason Wang <jasowang at redhat.com> > > This still leaves hung processes, but at least it doesn't pin the CPU any > more. Thanks. > Reviewed-by: Shannon Nelson <shannon.nelson at amd.com> > I'd like to see a f...

...te: >>> >>> Adding cond_resched() to the command waiting loop for a better >>> co-operation with the scheduler. This allows to give CPU a breath to >>> run other task(workqueue) instead of busy looping when preemption is >>> not allowed on a device whose CVQ might be slow. >>> >>> Signed-off-by: Jason Wang <jasowang at redhat.com> >> >> This still leaves hung processes, but at least it doesn't pin the CPU any >> more. Thanks. >> Reviewed-by: Shannon Nelson <shannon.nelson at amd.com> >> &...

? 2023/2/8 17:42, Eugenio P?rez ??: > Devices with CVQ needs to migrate state beyond vq state. Leaving this > to future series. I may miss something but what is missed to support CVQ/MQ? Thanks > > Signed-off-by: Eugenio P?rez <eperezma at redhat.com> > --- > net/vhost-vdpa.c | 6 ++++++ > 1 file changed, 6 insertions(+...

...gt; > Adding cond_resched() to the command waiting loop for a better > > > > co-operation with the scheduler. This allows to give CPU a breath to > > > > run other task(workqueue) instead of busy looping when preemption is > > > > not allowed on a device whose CVQ might be slow. > > > > > > > > Signed-off-by: Jason Wang <jasowang at redhat.com> > > > > > > This still leaves hung processes, but at least it doesn't pin the CPU any > > > more. Thanks. > > > Reviewed-by: Shannon Nelson <...

...;> Adding cond_resched() to the command waiting loop for a better >>>>> co-operation with the scheduler. This allows to give CPU a breath to >>>>> run other task(workqueue) instead of busy looping when preemption is >>>>> not allowed on a device whose CVQ might be slow. >>>>> >>>>> Signed-off-by: Jason Wang <jasowang at redhat.com> >>>> >>>> This still leaves hung processes, but at least it doesn't pin the CPU any >>>> more. Thanks. >>>> Reviewed-by: Shannon Nel...

...to the command waiting loop for a better > > > > > > co-operation with the scheduler. This allows to give CPU a breath to > > > > > > run other task(workqueue) instead of busy looping when preemption is > > > > > > not allowed on a device whose CVQ might be slow. > > > > > > > > > > > > Signed-off-by: Jason Wang <jasowang at redhat.com> > > > > > > > > > > This still leaves hung processes, but at least it doesn't pin the CPU any > > > > > more. Thank...

On Thu, Apr 13, 2023 at 10:04?PM Jakub Kicinski <kuba at kernel.org> wrote: > > On Thu, 13 Apr 2023 14:40:25 +0800 Jason Wang wrote: > > The code used to busy poll for cvq command which turns out to have > > several side effects: > > > > 1) infinite poll for buggy devices > > 2) bad interaction with scheduler > > > > So this series tries to use sleep instead of busy polling. In this > > version, I take a step back: the harden...

...;hdr; if (out) sgs[out_num++] = out; /* Add return status. */ - sg_init_one(&stat, &status, sizeof(status)); + sg_init_one(&stat, &buf->status, sizeof(buf->status)); sgs[out_num] = &stat; BUG_ON(out_num + 1 > ARRAY_SIZE(sgs)); virtqueue_add_sgs(vi->cvq, sgs, out_num, 1, vi, GFP_ATOMIC); - if (unlikely(!virtqueue_kick(vi->cvq))) - return status == VIRTIO_NET_OK; + if (unlikely(!virtqueue_kick(vi->cvq))) { + ret = (buf->status == VIRTIO_NET_OK); + goto out; + } /* Spin for a response, the kick causes an ioport write, trapping *...

...;hdr; if (out) sgs[out_num++] = out; /* Add return status. */ - sg_init_one(&stat, &status, sizeof(status)); + sg_init_one(&stat, &buf->status, sizeof(buf->status)); sgs[out_num] = &stat; BUG_ON(out_num + 1 > ARRAY_SIZE(sgs)); virtqueue_add_sgs(vi->cvq, sgs, out_num, 1, vi, GFP_ATOMIC); - if (unlikely(!virtqueue_kick(vi->cvq))) - return status == VIRTIO_NET_OK; + if (unlikely(!virtqueue_kick(vi->cvq))) { + ret = (buf->status == VIRTIO_NET_OK); + goto out; + } /* Spin for a response, the kick causes an ioport write, trapping *...

...4cc5d..709bcd34e485 100644 > > --- a/drivers/net/virtio_net.c > > +++ b/drivers/net/virtio_net.c > > @@ -2560,6 +2560,9 @@ static int virtnet_set_features(struct net_device *dev, > > u64 offloads; > > int err; > > > > + if (!vi->has_cvq) > > + return 0; > > + > > Instead of checking for this in virtnet_set_features, how about we > make configurability contingent on cvq in virtnet_probe: > > - if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS)) > + if (virtio_has...