All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuval Shaia <yuval.shaia@oracle.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: mst@redhat.com, linux-rdma@vger.kernel.org, cohuck@redhat.com,
	qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	jgg@mellanox.com
Subject: Re: [RFC 3/3] RDMA/virtio-rdma: VirtIO rdma driver
Date: Tue, 16 Apr 2019 11:56:21 +0300	[thread overview]
Message-ID: <20190416085620.GA4493@lap1> (raw)
In-Reply-To: <f133d122-5b00-2e3b-f5cc-efc6d2cc3d3b@acm.org>

On Mon, Apr 15, 2019 at 06:07:52PM -0700, Bart Van Assche wrote:
> On 4/11/19 4:01 AM, Yuval Shaia wrote:
> > +++ b/drivers/infiniband/hw/virtio/Kconfig
> > @@ -0,0 +1,6 @@
> > +config INFINIBAND_VIRTIO_RDMA
> > +	tristate "VirtIO Paravirtualized RDMA Driver"
> > +	depends on NETDEVICES && ETHERNET && PCI && INET
> > +	---help---
> > +	  This driver provides low-level support for VirtIO Paravirtual
> > +	  RDMA adapter.
> 
> Does this driver really depend on Ethernet, or does it also work with
> Ethernet support disabled?

The device should eventually expose Ethernet interface as well as IB.

> 
> > +static inline struct virtio_rdma_info *to_vdev(struct ib_device *ibdev)
> > +{
> > +	return container_of(ibdev, struct virtio_rdma_info, ib_dev);
> > +}
> 
> Is it really worth to introduce this function? Have you considered to
> use container_of(ibdev, struct virtio_rdma_info, ib_dev) directly instead
> of to_vdev()?

Agree, not sure really needed, just saw that some drivers uses this pattern.

> 
> > +static void rdma_ctrl_ack(struct virtqueue *vq)
> > +{
> > +	struct virtio_rdma_info *dev = vq->vdev->priv;
> > +
> > +	wake_up(&dev->acked);
> > +
> > +	printk("%s\n", __func__);
> > +}
> 
> Should that printk() be changed into pr_debug()? The same comment holds for
> all other printk() calls.

All prints will be removed, this is still wip.

> 
> > +#define VIRTIO_RDMA_BOARD_ID	1
> > +#define VIRTIO_RDMA_HW_NAME	"virtio-rdma"
> > +#define VIRTIO_RDMA_HW_REV	1
> > +#define VIRTIO_RDMA_DRIVER_VER	"1.0"
> 
> Is a driver version number useful in an upstream driver?

I've noticed that other drivers exposes this in sysfs.

> 
> > +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);
> > +	if (!cmd)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	rsp = kmalloc(sizeof(*rsp), GFP_ATOMIC);
> > +	if (!rsp) {
> > +		kfree(cmd);
> > +		return ERR_PTR(-ENOMEM);
> > +	}
> > +
> > +	vcq = kzalloc(sizeof(*vcq), GFP_KERNEL);
> > +	if (!vcq)
> > +		goto out;
> 
> Are you sure that you want to mix GFP_ATOMIC and GFP_KERNEL in a single
> function?

Right, a mistake.

> 
> Thanks,
> 
> Bart.

Thanks.

> 

WARNING: multiple messages have this Message-ID (diff)
From: Yuval Shaia <yuval.shaia@oracle.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org,
	mst@redhat.com, cohuck@redhat.com, marcel.apfelbaum@gmail.com,
	linux-rdma@vger.kernel.org, jgg@mellanox.com
Subject: Re: [Qemu-devel] [RFC 3/3] RDMA/virtio-rdma: VirtIO rdma driver
Date: Tue, 16 Apr 2019 11:56:21 +0300	[thread overview]
Message-ID: <20190416085620.GA4493@lap1> (raw)
In-Reply-To: <f133d122-5b00-2e3b-f5cc-efc6d2cc3d3b@acm.org>

On Mon, Apr 15, 2019 at 06:07:52PM -0700, Bart Van Assche wrote:
> On 4/11/19 4:01 AM, Yuval Shaia wrote:
> > +++ b/drivers/infiniband/hw/virtio/Kconfig
> > @@ -0,0 +1,6 @@
> > +config INFINIBAND_VIRTIO_RDMA
> > +	tristate "VirtIO Paravirtualized RDMA Driver"
> > +	depends on NETDEVICES && ETHERNET && PCI && INET
> > +	---help---
> > +	  This driver provides low-level support for VirtIO Paravirtual
> > +	  RDMA adapter.
> 
> Does this driver really depend on Ethernet, or does it also work with
> Ethernet support disabled?

The device should eventually expose Ethernet interface as well as IB.

> 
> > +static inline struct virtio_rdma_info *to_vdev(struct ib_device *ibdev)
> > +{
> > +	return container_of(ibdev, struct virtio_rdma_info, ib_dev);
> > +}
> 
> Is it really worth to introduce this function? Have you considered to
> use container_of(ibdev, struct virtio_rdma_info, ib_dev) directly instead
> of to_vdev()?

Agree, not sure really needed, just saw that some drivers uses this pattern.

> 
> > +static void rdma_ctrl_ack(struct virtqueue *vq)
> > +{
> > +	struct virtio_rdma_info *dev = vq->vdev->priv;
> > +
> > +	wake_up(&dev->acked);
> > +
> > +	printk("%s\n", __func__);
> > +}
> 
> Should that printk() be changed into pr_debug()? The same comment holds for
> all other printk() calls.

All prints will be removed, this is still wip.

> 
> > +#define VIRTIO_RDMA_BOARD_ID	1
> > +#define VIRTIO_RDMA_HW_NAME	"virtio-rdma"
> > +#define VIRTIO_RDMA_HW_REV	1
> > +#define VIRTIO_RDMA_DRIVER_VER	"1.0"
> 
> Is a driver version number useful in an upstream driver?

I've noticed that other drivers exposes this in sysfs.

> 
> > +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);
> > +	if (!cmd)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	rsp = kmalloc(sizeof(*rsp), GFP_ATOMIC);
> > +	if (!rsp) {
> > +		kfree(cmd);
> > +		return ERR_PTR(-ENOMEM);
> > +	}
> > +
> > +	vcq = kzalloc(sizeof(*vcq), GFP_KERNEL);
> > +	if (!vcq)
> > +		goto out;
> 
> Are you sure that you want to mix GFP_ATOMIC and GFP_KERNEL in a single
> function?

Right, a mistake.

> 
> Thanks,
> 
> Bart.

Thanks.

> 

WARNING: multiple messages have this Message-ID (diff)
From: Yuval Shaia <yuval.shaia@oracle.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: mst@redhat.com, linux-rdma@vger.kernel.org, cohuck@redhat.com,
	qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	jgg@mellanox.com
Subject: Re: [Qemu-devel] [RFC 3/3] RDMA/virtio-rdma: VirtIO rdma driver
Date: Tue, 16 Apr 2019 11:56:21 +0300	[thread overview]
Message-ID: <20190416085620.GA4493@lap1> (raw)
Message-ID: <20190416085621.97qXiel2ZeGLvp9ml0V1najf_3IBkf83bs2DMzMn-KE@z> (raw)
In-Reply-To: <f133d122-5b00-2e3b-f5cc-efc6d2cc3d3b@acm.org>

On Mon, Apr 15, 2019 at 06:07:52PM -0700, Bart Van Assche wrote:
> On 4/11/19 4:01 AM, Yuval Shaia wrote:
> > +++ b/drivers/infiniband/hw/virtio/Kconfig
> > @@ -0,0 +1,6 @@
> > +config INFINIBAND_VIRTIO_RDMA
> > +	tristate "VirtIO Paravirtualized RDMA Driver"
> > +	depends on NETDEVICES && ETHERNET && PCI && INET
> > +	---help---
> > +	  This driver provides low-level support for VirtIO Paravirtual
> > +	  RDMA adapter.
> 
> Does this driver really depend on Ethernet, or does it also work with
> Ethernet support disabled?

The device should eventually expose Ethernet interface as well as IB.

> 
> > +static inline struct virtio_rdma_info *to_vdev(struct ib_device *ibdev)
> > +{
> > +	return container_of(ibdev, struct virtio_rdma_info, ib_dev);
> > +}
> 
> Is it really worth to introduce this function? Have you considered to
> use container_of(ibdev, struct virtio_rdma_info, ib_dev) directly instead
> of to_vdev()?

Agree, not sure really needed, just saw that some drivers uses this pattern.

> 
> > +static void rdma_ctrl_ack(struct virtqueue *vq)
> > +{
> > +	struct virtio_rdma_info *dev = vq->vdev->priv;
> > +
> > +	wake_up(&dev->acked);
> > +
> > +	printk("%s\n", __func__);
> > +}
> 
> Should that printk() be changed into pr_debug()? The same comment holds for
> all other printk() calls.

All prints will be removed, this is still wip.

> 
> > +#define VIRTIO_RDMA_BOARD_ID	1
> > +#define VIRTIO_RDMA_HW_NAME	"virtio-rdma"
> > +#define VIRTIO_RDMA_HW_REV	1
> > +#define VIRTIO_RDMA_DRIVER_VER	"1.0"
> 
> Is a driver version number useful in an upstream driver?

I've noticed that other drivers exposes this in sysfs.

> 
> > +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);
> > +	if (!cmd)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	rsp = kmalloc(sizeof(*rsp), GFP_ATOMIC);
> > +	if (!rsp) {
> > +		kfree(cmd);
> > +		return ERR_PTR(-ENOMEM);
> > +	}
> > +
> > +	vcq = kzalloc(sizeof(*vcq), GFP_KERNEL);
> > +	if (!vcq)
> > +		goto out;
> 
> Are you sure that you want to mix GFP_ATOMIC and GFP_KERNEL in a single
> function?

Right, a mistake.

> 
> Thanks,
> 
> Bart.

Thanks.

> 


  parent reply	other threads:[~2019-04-16  8:56 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 11:01 [RFC 0/3] VirtIO RDMA Yuval Shaia
2019-04-11 11:01 ` [Qemu-devel] " Yuval Shaia
2019-04-11 11:01 ` [RFC 1/3] virtio-net: Move some virtio-net-pci decl to include/hw/virtio Yuval Shaia
2019-04-11 11:01   ` [Qemu-devel] " Yuval Shaia
2019-04-11 11:01 ` Yuval Shaia
2019-04-11 11:01 ` [RFC 2/3] hw/virtio-rdma: VirtIO rdma device Yuval Shaia
2019-04-11 11:01   ` [Qemu-devel] " Yuval Shaia
2019-04-19 23:20   ` Michael S. Tsirkin
2019-04-19 23:20     ` [Qemu-devel] " Michael S. Tsirkin
2019-04-19 23:20     ` Michael S. Tsirkin
2019-04-23  7:59     ` Cornelia Huck
2019-04-23  7:59       ` [Qemu-devel] " Cornelia Huck
2019-04-23  7:59       ` Cornelia Huck
2019-04-11 11:01 ` Yuval Shaia
2019-04-11 11:01 ` [RFC 3/3] RDMA/virtio-rdma: VirtIO rdma driver Yuval Shaia
2019-04-11 11:01 ` Yuval Shaia
2019-04-11 11:01   ` [Qemu-devel] " Yuval Shaia
2019-04-13  7:58   ` Yanjun Zhu
2019-04-13  7:58     ` [Qemu-devel] " Yanjun Zhu
2019-04-14  5:20     ` Yuval Shaia
2019-04-14  5:20       ` [Qemu-devel] " Yuval Shaia
2019-04-14  5:20       ` Yuval Shaia
2019-04-14  5:20     ` Yuval Shaia
2019-04-13  7:58   ` Yanjun Zhu
2019-04-16  1:07   ` Bart Van Assche
2019-04-16  1:07     ` [Qemu-devel] " Bart Van Assche
2019-04-16  8:56     ` Yuval Shaia
2019-04-16  8:56     ` Yuval Shaia [this message]
2019-04-16  8:56       ` Yuval Shaia
2019-04-16  8:56       ` Yuval Shaia
2019-04-11 17:02 ` [RFC 0/3] VirtIO RDMA Cornelia Huck
2019-04-11 17:02   ` [Qemu-devel] " Cornelia Huck
2019-04-11 17:02   ` Cornelia Huck
2019-04-11 17:24   ` Jason Gunthorpe
2019-04-11 17:24   ` Jason Gunthorpe
2019-04-11 17:24     ` [Qemu-devel] " Jason Gunthorpe
2019-04-11 17:24     ` Jason Gunthorpe
2019-04-11 17:34     ` Yuval Shaia
2019-04-11 17:34     ` Yuval Shaia
2019-04-11 17:34       ` [Qemu-devel] " Yuval Shaia
2019-04-11 17:34       ` Yuval Shaia
2019-04-11 17:40       ` Jason Gunthorpe
2019-04-11 17:40       ` Jason Gunthorpe
2019-04-11 17:40         ` [Qemu-devel] " Jason Gunthorpe
2019-04-11 17:40         ` Jason Gunthorpe
2019-04-15 10:04         ` Yuval Shaia
2019-04-15 10:04         ` Yuval Shaia
2019-04-15 10:04           ` [Qemu-devel] " Yuval Shaia
2019-04-15 10:04           ` Yuval Shaia
2019-04-11 17:41       ` Yuval Shaia
2019-04-11 17:41       ` Yuval Shaia
2019-04-11 17:41         ` [Qemu-devel] " Yuval Shaia
2019-04-11 17:41         ` Yuval Shaia
2019-04-12  9:51         ` Devesh Sharma via Qemu-devel
2019-04-12  9:51           ` [Qemu-devel] " Devesh Sharma via Qemu-devel
2019-04-12  9:51           ` Devesh Sharma
2019-04-15 10:27           ` Yuval Shaia
2019-04-15 10:27           ` Yuval Shaia
2019-04-15 10:27             ` [Qemu-devel] " Yuval Shaia
2019-04-15 10:27             ` Yuval Shaia
2019-04-15 10:35   ` Yuval Shaia
2019-04-15 10:35   ` Yuval Shaia
2019-04-15 10:35     ` [Qemu-devel] " Yuval Shaia
2019-04-15 10:35     ` Yuval Shaia
2019-04-19 11:16     ` Hannes Reinecke
2019-04-19 11:16       ` Hannes Reinecke
2019-04-19 11:16       ` Hannes Reinecke
2019-04-22  6:00       ` Leon Romanovsky
2019-04-22  6:00         ` Leon Romanovsky
2019-04-30 17:16         ` Yuval Shaia
2019-04-30 17:16           ` Yuval Shaia
2019-04-30 17:16           ` Yuval Shaia
2019-04-22 16:45       ` Jason Gunthorpe
2019-04-22 16:45         ` Jason Gunthorpe
2019-04-30 17:13         ` Yuval Shaia
2019-04-30 17:13           ` Yuval Shaia
2019-04-30 17:13           ` Yuval Shaia
2019-04-30 17:13           ` Yuval Shaia
2019-05-07 19:43           ` Jason Gunthorpe
2019-05-07 19:43             ` Jason Gunthorpe
2019-04-30 12:16       ` Yuval Shaia
2019-04-30 12:16         ` Yuval Shaia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190416085620.GA4493@lap1 \
    --to=yuval.shaia@oracle.com \
    --cc=bvanassche@acm.org \
    --cc=cohuck@redhat.com \
    --cc=jgg@mellanox.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.