Linux Virtualization - Nov 2019 - [PATCH V8 0/6] mdev based hardware virtio offloading support

On Wed, Nov 06, 2019 at 12:03:12PM -0700, Alex Williamson
wrote:
> On Wed, 6 Nov 2019 11:56:46 +0800
> Jason Wang <jasowang at redhat.com> wrote:
> 
> > On 2019/11/6 ??1:58, Alex Williamson wrote:
> > > On Tue,  5 Nov 2019 17:32:34 +0800
> > > Jason Wang <jasowang at redhat.com> wrote:
> > >  
> > >> Hi all:
> > >>
> > >> There are hardwares that can do virtio datapath offloading
while
> > >> having its own control path. This path tries to implement a
mdev based
> > >> unified API to support using kernel virtio driver to drive
those
> > >> devices. This is done by introducing a new mdev transport for
virtio
> > >> (virtio_mdev) and register itself as a new kind of mdev
driver. Then
> > >> it provides a unified way for kernel virtio driver to talk
with mdev
> > >> device implementation.
> > >>
> > >> Though the series only contains kernel driver support, the
goal is to
> > >> make the transport generic enough to support userspace
drivers. This
> > >> means vhost-mdev[1] could be built on top as well by resuing
the
> > >> transport.
> > >>
> > >> A sample driver is also implemented which simulate a
virito-net
> > >> loopback ethernet device on top of vringh + workqueue. This
could be
> > >> used as a reference implementation for real hardware driver.
> > >>
> > >> Also a real ICF VF driver was also posted here[2] which is a
good
> > >> reference for vendors who is interested in their own virtio
datapath
> > >> offloading product.
> > >>
> > >> Consider mdev framework only support VFIO device and driver
right now,
> > >> this series also extend it to support other types. This is
done
> > >> through introducing class id to the device and pairing it
with
> > >> id_talbe claimed by the driver. On top, this seris also
decouple
> > >> device specific parents ops out of the common ones.
> > >>
> > >> Pktgen test was done with virito-net + mvnet loop back
device.
> > >>
> > >> Please review.
> > >>
> > >> [1] https://lkml.org/lkml/2019/10/31/440
> > >> [2] https://lkml.org/lkml/2019/10/15/1226
> > >>
> > >> Changes from V7:
> > >> - drop {set|get}_mdev_features for virtio
> > >> - typo and comment style fixes  
> > >
> > > Seems we're nearly there, all the remaining comments are
relatively
> > > superficial, though I would appreciate a v9 addressing them as
well as
> > > the checkpatch warnings:
> > >
> > > https://patchwork.freedesktop.org/series/68977/  
> > 
> > 
> > Will do.
> > 
> > Btw, do you plan to merge vhost-mdev patch on top? Or you prefer it to
> > go through Michael's vhost tree?
> 
> I can include it if you wish.  The mdev changes are isolated enough in
> that patch that I wouldn't presume it, but clearly it would require
> less merge coordination to drop it in my tree.  Let me know.  Thanks,
> 
> Alex
I'm fine with merging through your tree. If you do, feel free to
include

Acked-by: Michael S. Tsirkin <mst at redhat.com>


-- 
MST

On Wed, 6 Nov 2019 14:25:23 -0500
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> On Wed, Nov 06, 2019 at 12:03:12PM -0700, Alex Williamson wrote:
> > On Wed, 6 Nov 2019 11:56:46 +0800
> > Jason Wang <jasowang at redhat.com> wrote:
> >   
> > > On 2019/11/6 ??1:58, Alex Williamson wrote:  
> > > > On Tue,  5 Nov 2019 17:32:34 +0800
> > > > Jason Wang <jasowang at redhat.com> wrote:
> > > >    
> > > >> Hi all:
> > > >>
> > > >> There are hardwares that can do virtio datapath
offloading while
> > > >> having its own control path. This path tries to
implement a mdev based
> > > >> unified API to support using kernel virtio driver to
drive those
> > > >> devices. This is done by introducing a new mdev
transport for virtio
> > > >> (virtio_mdev) and register itself as a new kind of mdev
driver. Then
> > > >> it provides a unified way for kernel virtio driver to
talk with mdev
> > > >> device implementation.
> > > >>
> > > >> Though the series only contains kernel driver support,
the goal is to
> > > >> make the transport generic enough to support userspace
drivers. This
> > > >> means vhost-mdev[1] could be built on top as well by
resuing the
> > > >> transport.
> > > >>
> > > >> A sample driver is also implemented which simulate a
virito-net
> > > >> loopback ethernet device on top of vringh + workqueue.
This could be
> > > >> used as a reference implementation for real hardware
driver.
> > > >>
> > > >> Also a real ICF VF driver was also posted here[2] which
is a good
> > > >> reference for vendors who is interested in their own
virtio datapath
> > > >> offloading product.
> > > >>
> > > >> Consider mdev framework only support VFIO device and
driver right now,
> > > >> this series also extend it to support other types. This
is done
> > > >> through introducing class id to the device and pairing
it with
> > > >> id_talbe claimed by the driver. On top, this seris also
decouple
> > > >> device specific parents ops out of the common ones.
> > > >>
> > > >> Pktgen test was done with virito-net + mvnet loop back
device.
> > > >>
> > > >> Please review.
> > > >>
> > > >> [1] https://lkml.org/lkml/2019/10/31/440
> > > >> [2] https://lkml.org/lkml/2019/10/15/1226
> > > >>
> > > >> Changes from V7:
> > > >> - drop {set|get}_mdev_features for virtio
> > > >> - typo and comment style fixes    
> > > >
> > > > Seems we're nearly there, all the remaining comments are
relatively
> > > > superficial, though I would appreciate a v9 addressing them
as well as
> > > > the checkpatch warnings:
> > > >
> > > > https://patchwork.freedesktop.org/series/68977/    
> > > 
> > > 
> > > Will do.
> > > 
> > > Btw, do you plan to merge vhost-mdev patch on top? Or you prefer
it to
> > > go through Michael's vhost tree?  
> > 
> > I can include it if you wish.  The mdev changes are isolated enough in
> > that patch that I wouldn't presume it, but clearly it would
require
> > less merge coordination to drop it in my tree.  Let me know.  Thanks,
> > 
> > Alex  
> 
> I'm fine with merging through your tree. If you do, feel free to
> include
> 
> Acked-by: Michael S. Tsirkin <mst at redhat.com>
AFAICT, it looks like we're expecting at least one more version of
Tiwei's patch after V5, so it'd probably be best to provide the ack and
go-ahead on that next version so there's no confusion.  Thanks,

Alex

On 2019/11/7 ??5:13, Alex Williamson wrote:
> On Wed, 6 Nov 2019 14:25:23 -0500
> "Michael S. Tsirkin" <mst at redhat.com> wrote:
>
>> On Wed, Nov 06, 2019 at 12:03:12PM -0700, Alex Williamson wrote:
>>> On Wed, 6 Nov 2019 11:56:46 +0800
>>> Jason Wang <jasowang at redhat.com> wrote:
>>>    
>>>> On 2019/11/6 ??1:58, Alex Williamson wrote:
>>>>> On Tue,  5 Nov 2019 17:32:34 +0800
>>>>> Jason Wang <jasowang at redhat.com> wrote:
>>>>>     
>>>>>> Hi all:
>>>>>>
>>>>>> There are hardwares that can do virtio datapath
offloading while
>>>>>> having its own control path. This path tries to
implement a mdev based
>>>>>> unified API to support using kernel virtio driver to
drive those
>>>>>> devices. This is done by introducing a new mdev
transport for virtio
>>>>>> (virtio_mdev) and register itself as a new kind of mdev
driver. Then
>>>>>> it provides a unified way for kernel virtio driver to
talk with mdev
>>>>>> device implementation.
>>>>>>
>>>>>> Though the series only contains kernel driver support,
the goal is to
>>>>>> make the transport generic enough to support userspace
drivers. This
>>>>>> means vhost-mdev[1] could be built on top as well by
resuing the
>>>>>> transport.
>>>>>>
>>>>>> A sample driver is also implemented which simulate a
virito-net
>>>>>> loopback ethernet device on top of vringh + workqueue.
This could be
>>>>>> used as a reference implementation for real hardware
driver.
>>>>>>
>>>>>> Also a real ICF VF driver was also posted here[2] which
is a good
>>>>>> reference for vendors who is interested in their own
virtio datapath
>>>>>> offloading product.
>>>>>>
>>>>>> Consider mdev framework only support VFIO device and
driver right now,
>>>>>> this series also extend it to support other types. This
is done
>>>>>> through introducing class id to the device and pairing
it with
>>>>>> id_talbe claimed by the driver. On top, this seris also
decouple
>>>>>> device specific parents ops out of the common ones.
>>>>>>
>>>>>> Pktgen test was done with virito-net + mvnet loop back
device.
>>>>>>
>>>>>> Please review.
>>>>>>
>>>>>> [1] https://lkml.org/lkml/2019/10/31/440
>>>>>> [2] https://lkml.org/lkml/2019/10/15/1226
>>>>>>
>>>>>> Changes from V7:
>>>>>> - drop {set|get}_mdev_features for virtio
>>>>>> - typo and comment style fixes
>>>>> Seems we're nearly there, all the remaining comments
are relatively
>>>>> superficial, though I would appreciate a v9 addressing them
as well as
>>>>> the checkpatch warnings:
>>>>>
>>>>> https://patchwork.freedesktop.org/series/68977/
>>>>
>>>> Will do.
>>>>
>>>> Btw, do you plan to merge vhost-mdev patch on top? Or you
prefer it to
>>>> go through Michael's vhost tree?
>>> I can include it if you wish.  The mdev changes are isolated enough
in
>>> that patch that I wouldn't presume it, but clearly it would
require
>>> less merge coordination to drop it in my tree.  Let me know. 
Thanks,
>>>
>>> Alex
>> I'm fine with merging through your tree. If you do, feel free to
>> include
>>
>> Acked-by: Michael S. Tsirkin <mst at redhat.com>
> AFAICT, it looks like we're expecting at least one more version of
> Tiwei's patch after V5, so it'd probably be best to provide the ack
and
> go-ahead on that next version so there's no confusion.  Thanks,
>
> Alex

Yes, it's probably need a V6. Will give ack there.

Thanks