search for: ib_udata

..._ROCE_UDP_ENCAP; + immutable->pkey_tbl_len = attr.pkey_tbl_len; + immutable->gid_tbl_len = attr.gid_tbl_len; + immutable->max_mad_size = IB_MGMT_MAD_SIZE; + + return 0; +} + +static int virtio_rdma_query_device(struct ib_device *ibdev, + struct ib_device_attr *props, + struct ib_udata *uhw) +{ + struct scatterlist data; + int offs; + int rc; + + if (uhw->inlen || uhw->outlen) + return -EINVAL; + + /* We start with sys_image_guid because of inconsistency beween ib_ + * and ibv_ */ + offs = offsetof(struct ib_device_attr, sys_image_guid); + sg_init_one(&data, (void *)p...

...= attr.pkey_tbl_len; > + immutable->gid_tbl_len = attr.gid_tbl_len; > + immutable->max_mad_size = IB_MGMT_MAD_SIZE; > + > + return 0; > +} > + > +static int virtio_rdma_query_device(struct ib_device *ibdev, > + struct ib_device_attr *props, > + struct ib_udata *uhw) > +{ > + struct scatterlist data; > + int offs; > + int rc; > + > + if (uhw->inlen || uhw->outlen) > + return -EINVAL; > + > + /* We start with sys_image_guid because of inconsistency beween ib_ > + * and ibv_ */ > + offs = offsetof(struct ib_device_at...

Data center backends use more and more RDMA or RoCE devices and more and more software runs in virtualized environment. There is a need for a standard to enable RDMA/RoCE on Virtual Machines. Virtio is the optimal solution since is the de-facto para-virtualizaton technology and also because the Virtio specification allows Hardware Vendors to support Virtio protocol natively in order to achieve

Data center backends use more and more RDMA or RoCE devices and more and more software runs in virtualized environment. There is a need for a standard to enable RDMA/RoCE on Virtual Machines. Virtio is the optimal solution since is the de-facto para-virtualizaton technology and also because the Virtio specification allows Hardware Vendors to support Virtio protocol natively in order to achieve

..._REV 1 > +#define VIRTIO_RDMA_DRIVER_VER "1.0" Is a driver version number useful in an upstream driver? > +struct ib_cq *virtio_rdma_create_cq(struct ib_device *ibdev, > + const struct ib_cq_init_attr *attr, > + struct ib_ucontext *context, > + struct ib_udata *udata) > +{ > + struct scatterlist in, out; > + struct virtio_rdma_ib_cq *vcq; > + struct cmd_create_cq *cmd; > + struct rsp_create_cq *rsp; > + struct ib_cq *cq = NULL; > + int rc; > + > + /* TODO: Check MAX_CQ */ > + > + cmd = kmalloc(sizeof(*cmd), GFP_ATOMIC); &...

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others