similar to: [PATCH vhost next 06/10] vdpa: Add means to communicate vq status on get_vq_state

On 2020/7/16 ??3:23, Eli Cohen wrote: > Currently, get_vq_state() is used only to pass the available index value > of a vq. Extend the struct to return status on the VQ to the caller. > For now, define VQ_STATE_NOT_READY. In the future it will be extended to > include other infomration. > > Modify current vdpa driver to update this field. > > Reviewed-by: Parav Pandit

On 2020/7/16 ??4:21, Eli Cohen wrote: > On Thu, Jul 16, 2020 at 04:11:00PM +0800, Jason Wang wrote: >> On 2020/7/16 ??3:23, Eli Cohen wrote: >>> Currently, get_vq_state() is used only to pass the available index value >>> of a vq. Extend the struct to return status on the VQ to the caller. >>> For now, define VQ_STATE_NOT_READY. In the future it will be extended

On 2020/7/20 ??3:14, Eli Cohen wrote: > Modify get_vq_state() so it returns an error code. In case of hardware > acceleration, the available index may be retrieved from the device, an > operation that can possibly fail. > > Reviewed-by: Parav Pandit <parav at mellanox.com> > Signed-off-by: Eli Cohen <eli at mellanox.com> Acked-by: Jason Wang <jasowang at

On 2020/8/5 ??12:20, Eli Cohen wrote: > Modify get_vq_state() so it returns an error code. In case of hardware > acceleration, the available index may be retrieved from the device, an > operation that can possibly fail. > > Reviewed-by: Parav Pandit <parav at mellanox.com> > Signed-off-by: Eli Cohen <eli at mellanox.com> Acked-by: Jason Wang <jasowang at

On Mon, Mar 13, 2023 at 09:14:38PM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin <mst at redhat.com> > > Sent: Sunday, March 12, 2023 12:24 PM > > > > On Sun, Mar 12, 2023 at 01:28:06PM +0000, Parav Pandit wrote: > > > > > > > > > > From: Michael S. Tsirkin <mst at redhat.com> > > > > Sent: Sunday,

On 3/13/2023 8:47 PM, Parav Pandit wrote: >> From: Michael S. Tsirkin <mst at redhat.com> >> Sent: Monday, March 13, 2023 11:38 PM >> >> On Tue, Mar 14, 2023 at 02:05:50AM +0000, Parav Pandit wrote: >>>> From: Si-Wei Liu <si-wei.liu at oracle.com> >>>> Sent: Monday, March 13, 2023 6:19 PM >>>> Actually there's no such

On 2020/7/20 ??3:14, Eli Cohen wrote: > Add a front end VDPA driver that registers in the VDPA bus and provides > networking to a guest. The VDPA driver creates the necessary resources > on the VF it is driving such that data path will be offloaded. > > Notifications are being communicated through the driver. > > Currently, only VFs are supported. In subsequent patches we will

On 2020/8/5 ??12:20, Eli Cohen wrote: > Add a front end VDPA driver that registers in the VDPA bus and provides > networking to a guest. The VDPA driver creates the necessary resources > on the VF it is driving such that data path will be offloaded. > > Notifications are being communicated through the driver. > > Currently, only VFs are supported. In subsequent patches we will

On Fri, Mar 17, 2023 at 9:58?PM Parav Pandit <parav at mellanox.com> wrote: > > > > > From: Eli Cohen <elic at nvidia.com> > > Sent: Wednesday, March 15, 2023 3:28 AM > > > > Extend the possible list for features that can be supported by firmware. > > Note that different versions of firmware may or may not support these > > features. The

get_vq_align returns u16 now, but that's not enough for systems/devices with 64K pages. All callers assign it to a u32 variable anyway, so let's just change the return value type to u32. Cc: "Zhu, Lingshan" <lingshan.zhu at intel.com> Reported-by: Arnd Bergmann <arnd at arndb.de> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

On 2020/5/26 ??1:32, Zhu Lingshan wrote: > Standard vhost devices rely on waking up a vhost_worker to kick > a virtquque. However vdpa devices have hardware backends, so it > does not need this waking up routin. In this commit, vdpa device > will kick a virtqueue directly, reduce the performance overhead > caused by waking up a vhost_woker. Thanks for the patch. It would be

vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single Physical Function - VF (Virtual Function) - Device that supports

vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single Physical Function - VF (Virtual Function) - Device that supports

On 3/12/2023 6:28 AM, Parav Pandit wrote: > >> From: Michael S. Tsirkin <mst at redhat.com> >> Sent: Sunday, March 12, 2023 6:25 AM >> >> On Sun, Mar 12, 2023 at 11:10:25AM +0200, Eli Cohen wrote: >>> On 12/03/2023 10:58, Michael S. Tsirkin wrote: >>>> On Sun, Mar 12, 2023 at 10:39:19AM +0200, Eli Cohen wrote: >>>>> One can still

On Sun, Mar 12, 2023 at 01:28:06PM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin <mst at redhat.com> > > Sent: Sunday, March 12, 2023 6:25 AM > > > > On Sun, Mar 12, 2023 at 11:10:25AM +0200, Eli Cohen wrote: > > > > > > On 12/03/2023 10:58, Michael S. Tsirkin wrote: > > > > On Sun, Mar 12, 2023 at 10:39:19AM +0200,

On Sun, Jan 29, 2023 at 10:51 AM Longpeng(Mike) <longpeng2 at huawei.com> wrote: > > From: Longpeng <longpeng2 at huawei.com> > > Support doorbell mapping for vdpasim devices, then we can test the notify > passthrough feature even if there's no real hardware on hand. > > Allocates a dummy page which is used to emulate the notify page of the device, > all VQs

On Mon, Mar 13, 2023 at 09:34:50PM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin <mst at redhat.com> > > Sent: Monday, March 13, 2023 5:24 PM > > I mean if this is claiming to fix a performance regression it should have a Fixes: > > tag with the commit that introduced the regression. > > The fixes tag should be, > > Fixes:

On 2020/7/16 ??3:23, Eli Cohen wrote: > Add a front end VDPA driver that registers in the VDPA bus and provides > networking to a guest. The VDPA driver creates the necessary resources > on the VF it is driving such that data path will be offloaded. > > Notifications are being communicated through the driver. > > Currently, only VFs are supported. In subsequent patches we will

On 2020/1/17 ??10:10, Jason Gunthorpe wrote: >>>> Netlink based lifecycle management could be implemented for vDPA >>>> simulator as well. >>> This is just begging for a netlink based approach. >>> >>> Certainly netlink driven removal should be an agreeable standard for >>> all devices, I think. >> Well, I think Parav had some

On 2020/7/19 ??3:49, Eli Cohen wrote: > On Fri, Jul 17, 2020 at 04:57:29PM +0800, Jason Wang wrote: >>> Looks like checking intialized is enough. Will fix this. >>>>> + >>>>> +static void mlx5_vdpa_set_vq_ready(struct vdpa_device *vdev, u16 idx, bool ready) >>>>> +{ >>>>> + struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);