[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200219025948.GA972742@___>
Date: Wed, 19 Feb 2020 10:59:48 +0800
From: Tiwei Bie <tiwei.bie@...el.com>
To: Jason Gunthorpe <jgg@...lanox.com>
Cc: Jason Wang <jasowang@...hat.com>,
"mst@...hat.com" <mst@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"maxime.coquelin@...hat.com" <maxime.coquelin@...hat.com>,
"cunming.liang@...el.com" <cunming.liang@...el.com>,
"zhihong.wang@...el.com" <zhihong.wang@...el.com>,
"rob.miller@...adcom.com" <rob.miller@...adcom.com>,
"xiao.w.wang@...el.com" <xiao.w.wang@...el.com>,
"haotian.wang@...ive.com" <haotian.wang@...ive.com>,
"lingshan.zhu@...el.com" <lingshan.zhu@...el.com>,
"eperezma@...hat.com" <eperezma@...hat.com>,
"lulu@...hat.com" <lulu@...hat.com>,
Parav Pandit <parav@...lanox.com>,
"kevin.tian@...el.com" <kevin.tian@...el.com>,
"stefanha@...hat.com" <stefanha@...hat.com>,
"rdunlap@...radead.org" <rdunlap@...radead.org>,
"hch@...radead.org" <hch@...radead.org>,
"aadam@...hat.com" <aadam@...hat.com>,
Jiri Pirko <jiri@...lanox.com>,
Shahaf Shuler <shahafs@...lanox.com>,
"hanand@...inx.com" <hanand@...inx.com>,
"mhabets@...arflare.com" <mhabets@...arflare.com>
Subject: Re: [PATCH V2 3/5] vDPA: introduce vDPA bus
On Tue, Feb 18, 2020 at 01:56:12PM +0000, Jason Gunthorpe wrote:
> On Mon, Feb 17, 2020 at 02:08:03PM +0800, Jason Wang wrote:
>
> > I thought you were copied in the patch [1], maybe we can move vhost related
> > discussion there to avoid confusion.
> >
> > [1] https://lwn.net/Articles/811210/
>
> Wow, that is .. confusing.
>
> So this is supposed to duplicate the uAPI of vhost-user? But it is
> open coded and duplicated because .. vdpa?
Do you mean the vhost-user in DPDK? There is no vhost-user
in Linux kernel.
Thanks,
Tiwei
>
> > So it's cheaper and simpler to introduce a new bus instead of refactoring a
> > well known bus and API where brunches of drivers and devices had been
> > implemented for years.
>
> If you reason for this approach is to ease the implementation then you
> should talk about it in the cover letters/etc
>
> Maybe it is reasonable to do this because the rework is too great, I
> don't know, but to me this whole thing looks rather messy.
>
> Remember this stuff is all uAPI as it shows up in sysfs, so you can
> easilly get stuck with it forever.
>
> Jason
Powered by blists - more mailing lists