Linux Virtualization - Jul 2013 - [PATCH] virtio-net: put virtio net header inline with data

On Tue, Jul 09, 2013 at 11:46:23AM +0930, Rusty Russell
wrote:
> "Michael S. Tsirkin" <mst at redhat.com> writes:
> > For small packets we can simplify xmit processing
> > by linearizing buffers with the header:
> > most packets seem to have enough head room
> > we can use for this purpose.
> > Since existing hypervisors require that header
> > is the first s/g element, we need a feature bit
> > for this.
> >
> > Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
> > ---
> >
> > Note: this needs to be applied on top of patch
> > defining VIRTIO_F_ANY_LAYOUT - bit to be
> > selected by Rusty.
> >
> > The following patch should work for any definition of
> > VIRTIO_F_ANY_LAYOUT - I used bit 31 for testing.
> > Rusty, could you please pick a valid bit for VIRTIO_F_ANY_LAYOUT
> > and squeeze this patch into 3.11?
> 
> Sorry, it's too late.
> 
> First, I've been a bit lax in sending patches via DaveM, and this is
> definitely his territory (ie. more net than virtio).
Let's do this: I'll send a patch series, you ack and we see
what happens?
> Secondly, it needs baking and testing time.
> 
> Cheers,
> Rusty.
I did some testing on this.  But proper testing just isn't happening out
of tree.

-- 
MST

"Michael S. Tsirkin" <mst at redhat.com>
writes:
> On Tue, Jul 09, 2013 at 11:46:23AM +0930, Rusty Russell wrote:
>> "Michael S. Tsirkin" <mst at redhat.com> writes:
>> > For small packets we can simplify xmit processing
>> > by linearizing buffers with the header:
>> > most packets seem to have enough head room
>> > we can use for this purpose.
>> > Since existing hypervisors require that header
>> > is the first s/g element, we need a feature bit
>> > for this.
>> >
>> > Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
>> > ---
>> >
>> > Note: this needs to be applied on top of patch
>> > defining VIRTIO_F_ANY_LAYOUT - bit to be
>> > selected by Rusty.
>> >
>> > The following patch should work for any definition of
>> > VIRTIO_F_ANY_LAYOUT - I used bit 31 for testing.
>> > Rusty, could you please pick a valid bit for VIRTIO_F_ANY_LAYOUT
>> > and squeeze this patch into 3.11?
>> 
>> Sorry, it's too late.
>> 
>> First, I've been a bit lax in sending patches via DaveM, and this
is
>> definitely his territory (ie. more net than virtio).
>
> Let's do this: I'll send a patch series, you ack and we see
> what happens?
If you convince DaveM, I won't object :)
>> Secondly, it needs baking and testing time.
>> 
>> Cheers,
>> Rusty.
>
> I did some testing on this.  But proper testing just isn't happening
out
> of tree.
But it will get into linux-next for the *next* merge window.

Cheers,
Rusty.

From: Rusty Russell <rusty at rustcorp.com.au>
Date: Tue, 09 Jul 2013 17:38:51 +0930
> If you convince DaveM, I won't object :)
Simplifications are great, but not when the merge window opens up.

Sorry, this isn't appropriate now.

On Tue, Jul 09, 2013 at 05:38:51PM +0930, Rusty Russell
wrote:
> "Michael S. Tsirkin" <mst at redhat.com> writes:
> > On Tue, Jul 09, 2013 at 11:46:23AM +0930, Rusty Russell wrote:
> >> "Michael S. Tsirkin" <mst at redhat.com> writes:
> >> > For small packets we can simplify xmit processing
> >> > by linearizing buffers with the header:
> >> > most packets seem to have enough head room
> >> > we can use for this purpose.
> >> > Since existing hypervisors require that header
> >> > is the first s/g element, we need a feature bit
> >> > for this.
> >> >
> >> > Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
> >> > ---
> >> >
> >> > Note: this needs to be applied on top of patch
> >> > defining VIRTIO_F_ANY_LAYOUT - bit to be
> >> > selected by Rusty.
> >> >
> >> > The following patch should work for any definition of
> >> > VIRTIO_F_ANY_LAYOUT - I used bit 31 for testing.
> >> > Rusty, could you please pick a valid bit for
VIRTIO_F_ANY_LAYOUT
> >> > and squeeze this patch into 3.11?
> >> 
> >> Sorry, it's too late.
> >> 
> >> First, I've been a bit lax in sending patches via DaveM, and
this is
> >> definitely his territory (ie. more net than virtio).
> >
> > Let's do this: I'll send a patch series, you ack and we see
> > what happens?
> 
> If you convince DaveM, I won't object :)
> 
> >> Secondly, it needs baking and testing time.
> >> 
> >> Cheers,
> >> Rusty.
> >
> > I did some testing on this.  But proper testing just isn't
happening out
> > of tree.
> 
> But it will get into linux-next for the *next* merge window.
> 
> Cheers,
> Rusty.
Okay. Can you put it on virtio-next then?
I don't see it there ...

-- 
MST