From: Rusty Russell <rusty@rustcorp.com.au>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Jason Wang <jasowang@redhat.com>, Cong Wang <amwang@redhat.com>,
Amos Kong <akong@redhat.com>, Dave Jones <davej@redhat.com>,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] virtio-net: put virtio net header inline with data
Date: Mon, 15 Jul 2013 11:10:41 +0930 [thread overview]
Message-ID: <878v1838iu.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20130710061407.GC19759@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Tue, Jul 09, 2013 at 05:38:51PM +0930, Rusty Russell wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> > On Tue, Jul 09, 2013 at 11:46:23AM +0930, Rusty Russell wrote:
>> >> "Michael S. Tsirkin" <mst@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@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 ...
Here's the general order:
- 1 week before Linus merge window: I stop putting new stuff into xxx-next.
- Linus merge window open: I push stuff to Linus, new stuff stays in -pending.
- Linus merge window close: I ff my -next trees to -rc1, merge stuff
from -pending.
In this case, your patch will go from pending-rebases to DaveM, not
virtio-next.
Which I will do now...
Cheers,
Rusty.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Cong Wang <amwang@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Dave Jones <davej@redhat.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] virtio-net: put virtio net header inline with data
Date: Mon, 15 Jul 2013 11:10:41 +0930 [thread overview]
Message-ID: <878v1838iu.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20130710061407.GC19759@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Tue, Jul 09, 2013 at 05:38:51PM +0930, Rusty Russell wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> > On Tue, Jul 09, 2013 at 11:46:23AM +0930, Rusty Russell wrote:
>> >> "Michael S. Tsirkin" <mst@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@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 ...
Here's the general order:
- 1 week before Linus merge window: I stop putting new stuff into xxx-next.
- Linus merge window open: I push stuff to Linus, new stuff stays in -pending.
- Linus merge window close: I ff my -next trees to -rc1, merge stuff
from -pending.
In this case, your patch will go from pending-rebases to DaveM, not
virtio-next.
Which I will do now...
Cheers,
Rusty.
next prev parent reply other threads:[~2013-07-15 4:23 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-08 10:12 [PATCH] virtio-net: put virtio net header inline with data Michael S. Tsirkin
2013-07-08 10:12 ` Michael S. Tsirkin
2013-07-09 2:16 ` Rusty Russell
2013-07-09 2:16 ` Rusty Russell
2013-07-09 5:18 ` Michael S. Tsirkin
2013-07-09 5:18 ` Michael S. Tsirkin
2013-07-09 8:08 ` Rusty Russell
2013-07-09 8:08 ` Rusty Russell
2013-07-10 4:38 ` David Miller
2013-07-10 4:38 ` David Miller
2013-07-15 1:43 ` Rusty Russell
2013-07-15 1:43 ` Rusty Russell
2013-07-16 19:33 ` David Miller
2013-07-16 19:33 ` David Miller
2013-07-17 0:08 ` Rusty Russell
2013-07-17 0:08 ` Rusty Russell
2013-07-17 5:00 ` Michael S. Tsirkin
2013-07-17 5:00 ` Michael S. Tsirkin
2013-07-17 5:05 ` David Miller
2013-07-17 5:05 ` David Miller
2013-07-17 6:02 ` Rusty Russell
2013-07-17 6:02 ` Rusty Russell
2013-07-24 19:44 ` Michael S. Tsirkin
2013-07-24 19:44 ` Michael S. Tsirkin
2013-07-10 6:14 ` Michael S. Tsirkin
2013-07-10 6:14 ` Michael S. Tsirkin
2013-07-15 1:40 ` Rusty Russell [this message]
2013-07-15 1:40 ` Rusty Russell
2013-07-11 13:00 ` Michael S. Tsirkin
2013-07-11 13:00 ` [Qemu-devel] " Michael S. Tsirkin
2013-07-11 13:00 ` Michael S. Tsirkin
2013-07-12 5:57 ` Rusty Russell
2013-07-12 5:57 ` [Qemu-devel] " Rusty Russell
2013-07-12 5:57 ` Rusty Russell
-- strict thread matches above, loose matches on Subject: below --
2013-06-06 9:55 Michael S. Tsirkin
2013-06-06 19:59 ` [Qemu-devel] " Jesse Larrew
2013-06-06 20:09 ` Dave Jones
2013-06-06 20:18 ` Jesse Larrew
2013-06-07 2:12 ` Rusty Russell
2013-06-09 7:11 ` Michael S. Tsirkin
2013-06-09 7:11 ` Michael S. Tsirkin
2013-06-07 2:52 ` Jason Wang
2013-06-07 2:52 ` Jason Wang
2013-06-09 6:52 ` Michael S. Tsirkin
2013-06-09 6:52 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878v1838iu.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=akong@redhat.com \
--cc=amwang@redhat.com \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.