Linux Virtualization - Mar 2017 - [virtio-dev] packed ring layout proposal - todo list

On Tue, Feb 28, 2017 at 12:29:43PM +0800, Yuanhan Liu
wrote:
> Hi Michael,
> 
> Again, as usual, sorry for being late :/
> 
> On Wed, Feb 22, 2017 at 06:27:11AM +0200, Michael S. Tsirkin wrote:
> > Stage 2: prototype guest/host drivers
> > 
> > At this stage we need real guest and host drivers
> > to be able to test real life performance.
> > I suggest dpdk drivers + munimal hack in qemu to
> > pass features around.
> > 
> 
> I have already done that in last Nov. I made a very rough (yet hacky)
> version (only with Tx path) in one day while companying my wife in
> hospital.
Any performance data?
> If someone are interested in, I could share the code soon. I could
> even cleanup the code a bit if necessary.
Especially if you don't have time to benchmark, I think sharing it
might help.
> > Tasks:
> > 
> > - implement vhost-user support in dpdk
> > - implement virtio support in dpdk
> > - implement minimal stub in qemu
> 
> I didn't hack the QEMU, instead, I hacked the DPDK virtio-user, yet
> another virtio-net emulation. It's simpler and quicker for me.
Sure, I merely meant a stub for negotiating new feature bits
between host and guest. But I guess an environment set
the same way in host and guest would serve too.
> And here is my plan on virtio 1.1:
> 
> - Look deeper inside the virtio net performance issues (WIP)
> 
>   It's basically a job about digging the DPDK vhost/virtio code
>   deeper, something like how exactly the cache acts while Tx/Rx
>   pkts, what can be optimized by implementation, and what could
>   be improved with the help of spec extension.
> 
>   Please note that I often got interrupted on this task: it didn't
>   go smooth as I would have expected.
> 
> 
> - Try to accelerate vhost/virtio with vector instructions.
That's interesting. What kind of optimizations would you say
do vector instructions enable, and why?

>   Something I will look into when above item is done. Currently,
>   I thought of two items may help the vector implementation:
> 
>   * what kind of vring and desc layout could make the vector
>     implementation easier.
> 
>   * what kind of hint we need from virtio spec for (dynamically)
>     enabling the vector path.
> 
>   Besides that, I don't have too much clue yet.
> 
> 	--yliu

On Wed, Mar 01, 2017 at 03:07:29AM +0200, Michael S. Tsirkin
wrote:
> On Tue, Feb 28, 2017 at 12:29:43PM +0800, Yuanhan Liu wrote:
> > Hi Michael,
> > 
> > Again, as usual, sorry for being late :/
> > 
> > On Wed, Feb 22, 2017 at 06:27:11AM +0200, Michael S. Tsirkin wrote:
> > > Stage 2: prototype guest/host drivers
> > > 
> > > At this stage we need real guest and host drivers
> > > to be able to test real life performance.
> > > I suggest dpdk drivers + munimal hack in qemu to
> > > pass features around.
> > > 
> > 
> > I have already done that in last Nov. I made a very rough (yet hacky)
> > version (only with Tx path) in one day while companying my wife in
> > hospital.
> 
> Any performance data?
A straightfoward implementation only brings 10% performance boost in a
txonly micro benchmarking. But I'm sure there are still plenty of room
for improvement.
> > If someone are interested in, I could share the code soon. I could
> > even cleanup the code a bit if necessary.
> 
> Especially if you don't have time to benchmark, I think sharing it
> might help.
Here it is (check the README-virtio-1.1 for howto):

    git://fridaybit.com/git/dpdk.git  virtio-1.1-v0.1
> > - Try to accelerate vhost/virtio with vector instructions.
> 
> That's interesting. What kind of optimizations would you say
> do vector instructions enable, and why?
If we have made the cache impact being minimum, the left thing could
be optimized is the instruction cycles. SIMD instructions (like AVX)
then should help on this.

	--yliu
> >   Something I will look into when above item is done. Currently,
> >   I thought of two items may help the vector implementation:
> > 
> >   * what kind of vring and desc layout could make the vector
> >     implementation easier.
> > 
> >   * what kind of hint we need from virtio spec for (dynamically)
> >     enabling the vector path.
> > 
> >   Besides that, I don't have too much clue yet.
> > 
> > 	--yliu

On Wed, Mar 08, 2017 at 03:09:48PM +0800, Yuanhan Liu
wrote:
> On Wed, Mar 01, 2017 at 03:07:29AM +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 28, 2017 at 12:29:43PM +0800, Yuanhan Liu wrote:
> > > Hi Michael,
> > > 
> > > Again, as usual, sorry for being late :/
> > > 
> > > On Wed, Feb 22, 2017 at 06:27:11AM +0200, Michael S. Tsirkin
wrote:
> > > > Stage 2: prototype guest/host drivers
> > > > 
> > > > At this stage we need real guest and host drivers
> > > > to be able to test real life performance.
> > > > I suggest dpdk drivers + munimal hack in qemu to
> > > > pass features around.
> > > > 
> > > 
> > > I have already done that in last Nov. I made a very rough (yet
hacky)
> > > version (only with Tx path) in one day while companying my wife
in
> > > hospital.
> > 
> > Any performance data?
> 
> A straightfoward implementation only brings 10% performance boost in a
> txonly micro benchmarking. But I'm sure there are still plenty of room
> for improvement.
> 
> > > If someone are interested in, I could share the code soon. I
could
> > > even cleanup the code a bit if necessary.
> > 
> > Especially if you don't have time to benchmark, I think sharing it
> > might help.
> 
> Here it is (check the README-virtio-1.1 for howto):
> 
>     git://fridaybit.com/git/dpdk.git  virtio-1.1-v0.1
Well, I was told it maybe not proper to share code like this way. So
this channel is closed. I will check how to find a proper way. Sorry
for the inconvenience!

	--yliu