Re: [RFC PATCH 2/2] macvtap: TX zero copy between guest and hostkernel

[Michael S. Tsirkin]

On Wed, Sep 15, 2010 at 10:46:02AM +0800, Xin, Xiaohui wrote:
> >From: Michael S. Tsirkin [mailto:mst@xxxxxxxxxx]
> >Sent: Wednesday, September 15, 2010 12:30 AM
> >To: Shirley Ma
> >Cc: Arnd Bergmann; Avi Kivity; Xin, Xiaohui; David Miller; netdev@xxxxxxxxxxxxxxx;
> >kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> >Subject: Re: [RFC PATCH 2/2] macvtap: TX zero copy between guest and host kernel
> >
> >On Tue, Sep 14, 2010 at 09:00:25AM -0700, Shirley Ma wrote:
> >> On Tue, 2010-09-14 at 17:22 +0200, Michael S. Tsirkin wrote:
> >> > I would expect this to hurt performance significantly.
> >> > We could do this for asynchronous requests only to avoid the
> >> > slowdown.
> >>
> >> Is kiocb in sendmsg helpful here? It is not used now.
> >>
> >> Shirley
> >
> >Precisely. This is what the patch from Xin Xiaohui does.  That code
> >already seems to do most of what you are trying to do, right?
> >
> >The main thing missing seems to be macvtap integration, so that we can fall back
> >on data copy if zero copy is unavailable?
> >How hard would it be to basically link the mp and macvtap modules
> >together to get us this functionality? Anyone?
> >
> Michael,
> Is to support macvtap with zero-copy through mp device the functionality
> you mentioned above?

I have trouble parsing the above question.  At some point Arnd suggested
that the mp device functionality would fit nicely as part of the macvtap
driver.  It seems to make sense superficially, the advantage if it
worked would be that we would get zero copy (mostly) transparently.

Do you agree with this goal?

> Before Shirley Ma has suggested to move the zero-copy functionality into
> tun/tap device or macvtap device. How do you think about that?
> I suspect
> there will be a lot of duplicate code in that three drivers except we can extract
> code of zero-copy into kernel APIs and vhost APIs.


tap would be very hard at this point as it does not bind to a device.
macvtap might work, we mainly need to figure out a way to detect that
device can do zero copy so the right mode is used.  I think a first step
could be to simply link mp code into macvtap module, pass necessary
ioctls on, then move some code around as necessary.  This might get rid
of code duplication nicely.


> Do you think that's worth to do and help current process which is blocked too
> long than I expected?

I think it's nice to have.

And if done hopefully this will get the folk working on the macvtap
driver to review the code, which will help find all issues faster.

I think if you post some performance numbers,
this will also help get people excited and looking at the code.

I also don't see the process as completely blocked, each review round points
out more issues: we aren't going back and forth changing
same lines again and again, are we?

One thing that might help is increase the frequency of updates,
try sending them out sooner.
On the other hand 10 new patches each revision is a lot:
if there is a part of patchset that has stabilised you can split it out,
post once and keep posting the changing part separately.

I hope these suggestions help.

> >
> >--
> >MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/