search for: get_vq_irq

On 2020/7/28 ??12:24, Zhu Lingshan wrote: > This commit adds a new function get_vq_irq() in struct > vdpa_config_ops, which will return the irq number of a > virtqueue. > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > Suggested-by: Jason Wang <jasowang at redhat.com> > --- > include/linux/vdpa.h | 6 ++++++ > 1 file changed, 6 inser...

...irq offloading(irq bypass) for vDPA devices and gain > performance improvements. > > In my testing, with this feature, we can save 0.1ms > in a ping between two VFs on average. > changes from V3: > (1)removed vDPA irq allocate/free helpers in vDPA core. > (2)add a new function get_vq_irq() in struct vdpa_config_ops, > upper layer driver can use this function to: A. query the > irq numbner of a vq. B. detect whether a vq is enabled. > (3)implement get_vq_irq() in ifcvf driver. > (4)in vhost_vdpa, set_status() will setup irq offloading when > setting DRIVER_OK, and uns...

On Wed, Aug 05, 2020 at 07:38:32PM +0800, Zhu Lingshan wrote: > This commit merge vhost_vdpa_update_vq_irq() logics into > vhost_vdpa_setup_vq_irq(), so that code are unified. > > In vhost_vdpa_setup_vq_irq(), added checks for the existence > for get_vq_irq(). > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> which commit should I squash this into? commit f8e695e9dbd88464bc3d1f01769229dedf8f30d6 Author: Zhu Lingshan <lingshan.zhu at intel.com> Date: Fri Jul 31 14:55:31 2020 +0800 vhost_vdpa: implement IRQ offloadi...

...*vq = &v->vqs[qid]; >>> +??? const struct vdpa_config_ops *ops = v->vdpa->config; >>> +??? struct vdpa_device *vdpa = v->vdpa; >>> +??? int ret, irq; >>> + >>> +??? spin_lock(&vq->call_ctx.ctx_lock); >>> +??? irq = ops->get_vq_irq(vdpa, qid); >>> +??? if (!vq->call_ctx.ctx || irq < 0) { >>> +??????? spin_unlock(&vq->call_ctx.ctx_lock); >>> +??????? return; >>> +??? } >>> + >>> +??? vq->call_ctx.producer.token = vq->call_ctx.ctx; >>> +??? vq-&gt...

...+??? const struct vdpa_config_ops *ops = v->vdpa->config; >>>>> +??? struct vdpa_device *vdpa = v->vdpa; >>>>> +??? int ret, irq; >>>>> + >>>>> +??? spin_lock(&vq->call_ctx.ctx_lock); >>>>> +??? irq = ops->get_vq_irq(vdpa, qid); >>>>> +??? if (!vq->call_ctx.ctx || irq < 0) { >>>>> + spin_unlock(&vq->call_ctx.ctx_lock); >>>>> +??????? return; >>>>> +??? } >>>>> + >>>>> +??? vq->call_ctx.producer.token = vq-&...

...vhost_vdpa *v, u16 qid) > +{ > + struct vhost_virtqueue *vq = &v->vqs[qid]; > + const struct vdpa_config_ops *ops = v->vdpa->config; > + struct vdpa_device *vdpa = v->vdpa; > + int ret, irq; > + > + spin_lock(&vq->call_ctx.ctx_lock); > + irq = ops->get_vq_irq(vdpa, qid); > + if (!vq->call_ctx.ctx || irq < 0) { > + spin_unlock(&vq->call_ctx.ctx_lock); > + return; > + } > + > + vq->call_ctx.producer.token = vq->call_ctx.ctx; > + vq->call_ctx.producer.irq = irq; > + ret = irq_bypass_register_producer(&vq-...

multiple queue virtio-net: flow steering through host/guest cooperation Hello all: This is a rough series adds the guest/host cooperation of flow steering support based on Krish Kumar's multiple queue virtio-net driver patch 3/3 (http://lwn.net/Articles/467283/). This idea is simple, the backend pass the rxhash to the guest and guest would tell the backend the hash to queue mapping when

multiple queue virtio-net: flow steering through host/guest cooperation Hello all: This is a rough series adds the guest/host cooperation of flow steering support based on Krish Kumar's multiple queue virtio-net driver patch 3/3 (http://lwn.net/Articles/467283/). This idea is simple, the backend pass the rxhash to the guest and guest would tell the backend the hash to queue mapping when

...*vq = &v->vqs[qid]; > +??? const struct vdpa_config_ops *ops = v->vdpa->config; > +??? struct vdpa_device *vdpa = v->vdpa; > +??? int ret, irq; > + > +??? spin_lock(&vq->call_ctx.ctx_lock); > +??? irq = ops->get_vq_irq(vdpa, qid); > +??? if (!vq->call_ctx.ctx || irq < 0) { > +??????? spin_unlock(&vq->call_ctx.ctx_lock); > +??????? return; > +??? } > + > +??? vq->call_ctx.producer.token = vq->call_ctx.ctx; > +??? vq-&gt...

...vhost_vdpa *v, u16 qid) > +{ > + struct vhost_virtqueue *vq = &v->vqs[qid]; > + const struct vdpa_config_ops *ops = v->vdpa->config; > + struct vdpa_device *vdpa = v->vdpa; > + int ret, irq; > + > + spin_lock(&vq->call_ctx.ctx_lock); > + irq = ops->get_vq_irq(vdpa, qid); Btw, this assumes that get_vq_irq is mandatory. This looks wrong since there's no guarantee that the vDPA device driver can see irq. And this break vdpa simulator. Let's add a check and make it optional by document this assumption in the vdpa.h. Thanks > + if (!vq-&g...

...+ * @idx: virtqueue index > + * @prot: original page protection value of the > + * notification area > + * Returns pgprot_t: the pgprot of the notification area > * @get_vq_irq: Get the irq number of a virtqueue (optional, > * but must implemented if require vq irq offloading) > * @vdev: vdpa device > @@ -305,6 +311,9 @@ struct vdpa_config_ops { >...

Hello All: This series is an update version of multiqueue virtio-net driver based on Krishna Kumar's work to let virtio-net use multiple rx/tx queues to do the packets reception and transmission. Please review and comments. Test Environment: - Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 8 cores 2 numa nodes - Two directed connected 82599 Test Summary: - Highlights: huge improvements on TCP_RR

Hello All: This series is an update version of multiqueue virtio-net driver based on Krishna Kumar's work to let virtio-net use multiple rx/tx queues to do the packets reception and transmission. Please review and comments. Test Environment: - Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 8 cores 2 numa nodes - Two directed connected 82599 Test Summary: - Highlights: huge improvements on TCP_RR

...vhost_vdpa *v, int qid) > +{ > + struct vhost_virtqueue *vq = &v->vqs[qid]; > + const struct vdpa_config_ops *ops = v->vdpa->config; > + struct vdpa_device *vdpa = v->vdpa; > + int ret, irq; > + > + spin_lock(&vq->call_ctx.ctx_lock); > + irq = ops->get_vq_irq(vdpa, qid); > + if (!vq->call_ctx.ctx || irq == -EINVAL) { It's better to check returned irq as "irq < 0" to be more robust. Forcing a specific errno value is not good. > + spin_unlock(&vq->call_ctx.ctx_lock); > + return; > + } > + > + vq->call...

...e inclusion in core driver net/mlx5: Avoid eswitch header inclusion in fs core layer Tariq Toukan (1): net/mlx5: kTLS, Improve TLS params layout structures Zhu Lingshan (7): vhost: introduce vhost_vring_call kvm: detect assigned device via irqbypass manager vDPA: add get_vq_irq() in vdpa_config_ops vhost_vdpa: implement IRQ offloading in vhost_vdpa ifcvf: implement vdpa_config_ops.get_vq_irq() irqbypass: do not start cons/prod when failed connect vDPA: dont change vq irq after DRIVER_OK arch/um/drivers/virtio_uml.c | 2 +-...

...; +{ >> + struct vhost_virtqueue *vq = &v->vqs[qid]; >> + const struct vdpa_config_ops *ops = v->vdpa->config; >> + struct vdpa_device *vdpa = v->vdpa; >> + int ret, irq; >> + >> + spin_lock(&vq->call_ctx.ctx_lock); >> + irq = ops->get_vq_irq(vdpa, qid); >> + if (!vq->call_ctx.ctx || irq == -EINVAL) { >> + spin_unlock(&vq->call_ctx.ctx_lock); >> + return; >> + } >> + > If I understand correctly, this will cause these IRQs to be forwarded > directly to the VCPU, e.g. will be handled by the...

...PI from V4 so driver won't notify us if irq is >> changed. >> >> Then it looks to me there's no need for the ctx_lock, everyhing could >> be synchronized with vq mutex. >> >> Thanks > from V4 to V5, there are only some minor improvements and bug fix, get_vq_irq() almost stays untouched, mutex can work for this, however I see the vq mutex is used in many scenarios. > We only use this lock to protect the producer information, can this help to get less coupling, defensive code for less bugs? I think not, vq mutex is used to protect all vq related data s...

...--git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > index 3fab94f88894..bc679d0b7b87 100644 > --- a/drivers/vhost/vdpa.c > +++ b/drivers/vhost/vdpa.c > @@ -97,26 +97,20 @@ static void vhost_vdpa_setup_vq_irq(struct vhost_vdpa *v, u16 qid) > return; > > irq = ops->get_vq_irq(vdpa, qid); > - spin_lock(&vq->call_ctx.ctx_lock); > irq_bypass_unregister_producer(&vq->call_ctx.producer); > - if (!vq->call_ctx.ctx || irq < 0) { > - spin_unlock(&vq->call_ctx.ctx_lock); > + if (!vq->call_ctx.ctx || irq < 0) > return; &g...

...uct vdpa_device *vdev, u16 idx, > - struct vdpa_vq_state *state); > + int (*get_vq_state)(struct vdpa_device *vdev, u16 idx, > + struct vdpa_vq_state *state); > struct vdpa_notification_area > (*get_vq_notification)(struct vdpa_device *vdev, u16 idx); > int (*get_vq_irq)(struct vdpa_device *vdv, u16 idx);

...p;v->vqs[qid]; >>>> + const struct vdpa_config_ops *ops = v->vdpa->config; >>>> + struct vdpa_device *vdpa = v->vdpa; >>>> + int ret, irq; >>>> + >>>> + spin_lock(&vq->call_ctx.ctx_lock); >>>> + irq = ops->get_vq_irq(vdpa, qid); >>>> + if (!vq->call_ctx.ctx || irq == -EINVAL) { >>>> + spin_unlock(&vq->call_ctx.ctx_lock); >>>> + return; >>>> + } >>>> + >>> If I understand correctly, this will cause these IRQs to be forwarded >&gt...