All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@mellanox.com>
To: Jason Wang <jasowang@redhat.com>
Cc: mst@redhat.com, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, tiwei.bie@intel.com,
	maxime.coquelin@redhat.com, cunming.liang@intel.com,
	zhihong.wang@intel.com, rob.miller@broadcom.com,
	xiao.w.wang@intel.com, haotian.wang@sifive.com,
	lingshan.zhu@intel.com, eperezma@redhat.com, lulu@redhat.com,
	parav@mellanox.com, kevin.tian@intel.com, stefanha@redhat.com,
	rdunlap@infradead.org, hch@infradead.org, aadam@redhat.com,
	jiri@mellanox.com, shahafs@mellanox.com, hanand@xilinx.com,
	mhabets@solarflare.com
Subject: Re: [PATCH V2 3/5] vDPA: introduce vDPA bus
Date: Fri, 14 Feb 2020 09:52:32 -0400	[thread overview]
Message-ID: <20200214135232.GB4271@mellanox.com> (raw)
In-Reply-To: <8b3e6a9c-8bfd-fb3c-12a8-2d6a3879f1ae@redhat.com>

On Fri, Feb 14, 2020 at 11:23:27AM +0800, Jason Wang wrote:

> > > Though all vDPA devices have the same programming interface, but the
> > > semantic is different. So it looks to me that use bus complies what
> > > class.rst said:
> > > 
> > > "
> > > 
> > > Each device class defines a set of semantics and a programming interface
> > > that devices of that class adhere to. Device drivers are the
> > > implementation of that programming interface for a particular device on
> > > a particular bus.
> > > 
> > > "
> > Here we are talking about the /dev/XX node that provides the
> > programming interface.
> 
> 
> I'm confused here, are you suggesting to use class to create char device in
> vhost-vdpa? That's fine but the comment should go for vhost-vdpa patch.

Certainly yes, something creating many char devs should have a
class. That makes the sysfs work as expected

I suppose this is vhost user? I admit I don't really see how this
vhost stuff works, all I see are global misc devices? Very unusual for
a new subsystem to be using global misc devices..

I would have expected that a single VDPA device comes out as a single
char dev linked to only that VDPA device.

> > All the vdpa devices have the same basic
> > chardev interface and discover any semantic variations 'in band'
> 
> That's not true, char interface is only used for vhost. Kernel virtio driver
> does not need char dev but a device on the virtio bus.

Okay, this is fine, but why do you need two busses to accomplish this?

Shouldn't the 'struct virito_device' be the plug in point for HW
drivers I was talking about - and from there a vhost-user can connect
to the struct virtio_device to give it a char dev or a kernel driver
can connect to link it to another subsystem?

It is easy to see something is going wrong with this design because
the drivers/virtio/virtio_vdpa.c mainly contains a bunch of trampoline
functions reflecting identical calls from one ops struct to a
different ops struct. This suggests the 'vdpa' is some subclass of
'virtio' and it is possibly better to model it by extending 'struct
virito_device' to include the vdpa specific stuff.

Where does the vhost-user char dev get invovled in with the v2 series?
Is that included?

> > Every class of virtio traffic is going to need a special HW driver to
> > enable VDPA, that special driver can create the correct vhost side
> > class device.
> 
> Are you saying, e.g it's the charge of IFCVF driver to create vhost char dev
> and other stuffs?

No.

Jason

  reply	other threads:[~2020-02-14 13:52 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-10  3:56 [PATCH V2 0/5] vDPA support Jason Wang
2020-02-10  3:56 ` [PATCH V2 1/5] vhost: factor out IOTLB Jason Wang
2020-02-10  3:56 ` [PATCH V2 2/5] vringh: IOTLB support Jason Wang
2020-02-10  3:56 ` [PATCH V2 3/5] vDPA: introduce vDPA bus Jason Wang
2020-02-11 13:47   ` Jason Gunthorpe
2020-02-12  7:55     ` Jason Wang
2020-02-12 12:51       ` Jason Gunthorpe
2020-02-13  3:34         ` Jason Wang
2020-02-13 13:41           ` Jason Gunthorpe
2020-02-13 14:58             ` Jason Wang
2020-02-13 15:05               ` Jason Gunthorpe
2020-02-13 15:05                 ` Jason Gunthorpe
2020-02-13 15:41                 ` Michael S. Tsirkin
2020-02-13 15:51                   ` Jason Gunthorpe
2020-02-13 15:56                     ` Michael S. Tsirkin
2020-02-13 15:56                       ` Michael S. Tsirkin
2020-02-13 16:24                       ` Jason Gunthorpe
2020-02-14  4:05                         ` Jason Wang
2020-02-14 14:04                           ` Jason Gunthorpe
2020-02-17  6:07                             ` Jason Wang
2020-02-17  6:07                               ` Jason Wang
2020-02-13 15:59                     ` Michael S. Tsirkin
2020-02-13 16:13                       ` Jason Gunthorpe
2020-02-14  4:39                         ` Jason Wang
2020-02-14  3:23                 ` Jason Wang
2020-02-14  3:23                   ` Jason Wang
2020-02-14 13:52                   ` Jason Gunthorpe [this message]
2020-02-17  6:08                     ` Jason Wang
2020-02-17  6:08                       ` Jason Wang
2020-02-18 13:56                       ` Jason Gunthorpe
2020-02-18 13:56                         ` Jason Gunthorpe
2020-02-19  2:59                         ` Tiwei Bie
2020-02-19  2:59                           ` Tiwei Bie
2020-02-19  5:35                         ` Jason Wang
2020-02-19  5:35                           ` Jason Wang
2020-02-19 12:53                           ` Jason Gunthorpe
2020-02-19 12:53                             ` Jason Gunthorpe
2020-02-10  3:56 ` [PATCH V2 4/5] virtio: introduce a vDPA based transport Jason Wang
2020-02-10 13:34   ` Jason Gunthorpe
2020-02-10 13:34     ` Jason Gunthorpe
2020-02-11  3:04     ` Jason Wang
2020-02-11  3:04       ` Jason Wang
2020-02-10  3:56 ` [PATCH V2 5/5] vdpasim: vDPA device simulator Jason Wang
2020-02-10 11:23   ` Michael S. Tsirkin
2020-02-11  3:12     ` Jason Wang
2020-02-11 13:52   ` Jason Gunthorpe
2020-02-12  8:27     ` Jason Wang

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=20200214135232.GB4271@mellanox.com \
    --to=jgg@mellanox.com \
    --cc=aadam@redhat.com \
    --cc=cunming.liang@intel.com \
    --cc=eperezma@redhat.com \
    --cc=hanand@xilinx.com \
    --cc=haotian.wang@sifive.com \
    --cc=hch@infradead.org \
    --cc=jasowang@redhat.com \
    --cc=jiri@mellanox.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=lingshan.zhu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mhabets@solarflare.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=parav@mellanox.com \
    --cc=rdunlap@infradead.org \
    --cc=rob.miller@broadcom.com \
    --cc=shahafs@mellanox.com \
    --cc=stefanha@redhat.com \
    --cc=tiwei.bie@intel.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xiao.w.wang@intel.com \
    --cc=zhihong.wang@intel.com \
    /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.