virtio-net: put virtio net header inline with data

PATCH In review Michael S. Tsirkin 3 participants 16 messages Jul 8, 2013 – Jul 24, 2013

Subsystems (4)

Networking Network drivers virtio core virtio net driver

lore

Share & tools

lore

Michael S. Tsirkin

author maintainer

2013-07-08 10:11 UTC #0 lore raw

PATCH 1/1 virtio-net: put virtio net header inline with data

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 <[email protected]>

---

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?

 drivers/net/virtio_net.c        | 42 +++++++++++++++++++++++++++++++++--------
 include/uapi/linux/virtio_net.h |  4 +++-
 2 files changed, 37 insertions(+), 9 deletions(-)

drivers/net/virtio_net.c +34 -8

index c9e0038..5305bd1 100644
@@ -106,6 +106,9 @@ struct virtnet_info {
 	/* Has control virtqueue */
 	bool has_cvq;
 
+	/* Host can handle any s/g split between our header and packet data */
+	bool any_header_sg;
+
 	/* enable config space updates */
 	bool config_enable;

@@ -668,12 +671,28 @@ static void free_old_xmit_skbs(struct send_queue *sq)
 
 static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
 {
-	struct skb_vnet_hdr *hdr = skb_vnet_hdr(skb);
+	struct skb_vnet_hdr *hdr;
 	const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest;
 	struct virtnet_info *vi = sq->vq->vdev->priv;
 	unsigned num_sg;
+	unsigned hdr_len;
+	bool can_push;
 
 	pr_debug("%s: xmit %p %pM\n", vi->dev->name, skb, dest);
+	if (vi->mergeable_rx_bufs)
+		hdr_len = sizeof hdr->mhdr;
+	else
+		hdr_len = sizeof hdr->hdr;
+
+	can_push = vi->any_header_sg &&
+		!((unsigned long)skb->data & (__alignof__(*hdr) - 1)) &&
+		!skb_header_cloned(skb) && skb_headroom(skb) >= hdr_len;
+	/* Even if we can, don't push here yet as this would skew
+	 * csum_start offset below. */
+	if (can_push)
+		hdr = (struct skb_vnet_hdr *)(skb->data - hdr_len);
+	else
+		hdr = skb_vnet_hdr(skb);
 
 	if (skb->ip_summed == CHECKSUM_PARTIAL) {
 		hdr->hdr.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;

@@ -702,15 +721,18 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
 		hdr->hdr.gso_size = hdr->hdr.hdr_len = 0;
 	}
 
-	hdr->mhdr.num_buffers = 0;
-
-	/* Encode metadata header at front. */
 	if (vi->mergeable_rx_bufs)
-		sg_set_buf(sq->sg, &hdr->mhdr, sizeof hdr->mhdr);
-	else
-		sg_set_buf(sq->sg, &hdr->hdr, sizeof hdr->hdr);
+		hdr->mhdr.num_buffers = 0;
 
-	num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
+	if (can_push) {
+		__skb_push(skb, hdr_len);
+		num_sg = skb_to_sgvec(skb, sq->sg, 0, skb->len);
+		/* Pull header back to avoid skew in tx bytes calculations. */
+		__skb_pull(skb, hdr_len);
+	} else {
+		sg_set_buf(sq->sg, hdr, hdr_len);
+		num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
+	}
 	return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, GFP_ATOMIC);
 }

@@ -1554,6 +1576,9 @@ static int virtnet_probe(struct virtio_device *vdev)
 	if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
 		vi->mergeable_rx_bufs = true;
 
+	if (virtio_has_feature(vdev, VIRTIO_F_ANY_LAYOUT))
+		vi->any_header_sg = true;
+
 	if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
 		vi->has_cvq = true;

@@ -1729,6 +1754,7 @@ static unsigned int features[] = {
 	VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN,
 	VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
 	VIRTIO_NET_F_CTRL_MAC_ADDR,
+	VIRTIO_F_ANY_LAYOUT,
 };
 
 static struct virtio_driver virtio_net_driver = {

include/uapi/linux/virtio_net.h +3 -1

index c520203..bd1993b 100644
@@ -70,7 +70,9 @@ struct virtio_net_config {
 	__u16 max_virtqueue_pairs;
 } __attribute__((packed));
 
-/* This is the first element of the scatter-gather list.  If you don't
+/* This header comes first in the scatter-gather list.
+ * If VIRTIO_F_ANY_LAYOUT is not negotiated, it must
+ * be the first element of the scatter-gather list.  If you don't
  * specify GSO or CSUM features, you can simply ignore the header. */
 struct virtio_net_hdr {
 #define VIRTIO_NET_HDR_F_NEEDS_CSUM	1	// Use csum_start, csum_offset

Signature · 1 line

MST

Rusty Russell

2013-07-09 02:16 UTC #1 lore raw

Quoted 11 lines · Michael S. Tsirkin

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 <[email protected]>
---

Quoted 8 lines

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).

Secondly, it needs baking and testing time.

Cheers,
Rusty.

Michael S. Tsirkin

author maintainer

2013-07-09 05:17 UTC #2 lore raw

Quoted 21 lines · Rusty Russell

Quoted 11 lines · Michael S. Tsirkin
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 <[email protected]>
---
Quoted 8 lines
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?

Quoted 4 lines

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?

Quoted 4 lines

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.

Signature · 1 line

MST

Rusty Russell

2013-07-09 08:08 UTC #3 lore raw

Quoted 22 lines · Michael S. Tsirkin

Quoted 21 lines · Rusty Russell
Quoted 19 lines · Michael S. Tsirkin
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 <[email protected]>
---
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?

Quoted 7 lines

Quoted 4 lines
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 :)

Quoted 7 lines

Quoted 4 lines
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.

David Miller

maintainer

2013-07-10 04:38 UTC #4 lore raw

From: Rusty Russell <[email protected]>
Date: Tue, 09 Jul 2013 17:38:51 +0930

Quoted 1 line

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.

Rusty Russell

2013-07-15 01:43 UTC #5 lore raw

PATCH 1/1 virtio-net: put virtio net header inline with data

From: Michael S. Tsirkin <[email protected]>

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 <[email protected]>

Signed-off-by Rusty Russell <[email protected]>

---
 drivers/net/virtio_net.c        | 42 +++++++++++++++++++++++++++++++++--------
 include/uapi/linux/virtio_net.h |  4 +++-
 2 files changed, 37 insertions(+), 9 deletions(-)

drivers/net/virtio_net.c +34 -8

index 3d2a90a..f216002 100644
@@ -106,6 +106,9 @@ struct virtnet_info {
 	/* Has control virtqueue */
 	bool has_cvq;
 
+	/* Host can handle any s/g split between our header and packet data */
+	bool any_header_sg;
+
 	/* enable config space updates */
 	bool config_enable;

@@ -669,12 +672,28 @@ static void free_old_xmit_skbs(struct send_queue *sq)
 
 static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
 {
-	struct skb_vnet_hdr *hdr = skb_vnet_hdr(skb);
+	struct skb_vnet_hdr *hdr;
 	const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest;
 	struct virtnet_info *vi = sq->vq->vdev->priv;
 	unsigned num_sg;
+	unsigned hdr_len;
+	bool can_push;
 
 	pr_debug("%s: xmit %p %pM\n", vi->dev->name, skb, dest);
+	if (vi->mergeable_rx_bufs)
+		hdr_len = sizeof hdr->mhdr;
+	else
+		hdr_len = sizeof hdr->hdr;
+
+	can_push = vi->any_header_sg &&
+		!((unsigned long)skb->data & (__alignof__(*hdr) - 1)) &&
+		!skb_header_cloned(skb) && skb_headroom(skb) >= hdr_len;
+	/* Even if we can, don't push here yet as this would skew
+	 * csum_start offset below. */
+	if (can_push)
+		hdr = (struct skb_vnet_hdr *)(skb->data - hdr_len);
+	else
+		hdr = skb_vnet_hdr(skb);
 
 	if (skb->ip_summed == CHECKSUM_PARTIAL) {
 		hdr->hdr.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;

@@ -703,15 +722,18 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
 		hdr->hdr.gso_size = hdr->hdr.hdr_len = 0;
 	}
 
-	hdr->mhdr.num_buffers = 0;
-
-	/* Encode metadata header at front. */
 	if (vi->mergeable_rx_bufs)
-		sg_set_buf(sq->sg, &hdr->mhdr, sizeof hdr->mhdr);
-	else
-		sg_set_buf(sq->sg, &hdr->hdr, sizeof hdr->hdr);
+		hdr->mhdr.num_buffers = 0;
 
-	num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
+	if (can_push) {
+		__skb_push(skb, hdr_len);
+		num_sg = skb_to_sgvec(skb, sq->sg, 0, skb->len);
+		/* Pull header back to avoid skew in tx bytes calculations. */
+		__skb_pull(skb, hdr_len);
+	} else {
+		sg_set_buf(sq->sg, hdr, hdr_len);
+		num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
+	}
 	return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, GFP_ATOMIC);
 }

@@ -1552,6 +1574,9 @@ static int virtnet_probe(struct virtio_device *vdev)
 	if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
 		vi->mergeable_rx_bufs = true;
 
+	if (virtio_has_feature(vdev, VIRTIO_F_ANY_LAYOUT))
+		vi->any_header_sg = true;
+
 	if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
 		vi->has_cvq = true;

@@ -1727,6 +1752,7 @@ static unsigned int features[] = {
 	VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN,
 	VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
 	VIRTIO_NET_F_CTRL_MAC_ADDR,
+	VIRTIO_F_ANY_LAYOUT,
 };
 
 static struct virtio_driver virtio_net_driver = {

include/uapi/linux/virtio_net.h +3 -1

index c520203..227d4ce 100644
@@ -70,7 +70,9 @@ struct virtio_net_config {
 	__u16 max_virtqueue_pairs;
 } __attribute__((packed));
 
-/* This is the first element of the scatter-gather list.  If you don't
+/* This header comes first in the scatter-gather list.
+ * If VIRTIO_F_ANY_LAYOUT is not negotiated, it must
+ * be the first element of the scatter-gather list.  If you don't
  * specify GSO or CSUM features, you can simply ignore the header. */
 struct virtio_net_hdr {
 #define VIRTIO_NET_HDR_F_NEEDS_CSUM	1	// Use csum_start, csum_offset

David Miller

maintainer

2013-07-16 19:33 UTC #6 lore raw

From: Rusty Russell <[email protected]>
Date: Mon, 15 Jul 2013 11:13:25 +0930

Quoted 10 lines

From: Michael S. Tsirkin <[email protected]>
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.

Quoted 2 lines

Signed-off-by Michael S. Tsirkin <[email protected]>
Signed-off-by Rusty Russell <[email protected]>

I really think this has to wait until the next merge window, sorry.

Please resubmit this when I open net-next back up, thanks.

Rusty Russell

2013-07-17 00:08 UTC #7 lore raw

Quoted 13 lines · David Miller

From: Rusty Russell <[email protected]>
Date: Mon, 15 Jul 2013 11:13:25 +0930
Quoted 10 lines
From: Michael S. Tsirkin <[email protected]>
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.

Quoted 6 lines

Quoted 2 lines
Signed-off-by Michael S. Tsirkin <[email protected]>
Signed-off-by Rusty Russell <[email protected]>
I really think this has to wait until the next merge window, sorry.
Please resubmit this when I open net-next back up, thanks.

Oh, assumed it was already open. Will re-submit then.

Cheers,
Rusty.

Michael S. Tsirkin

author maintainer

2013-07-17 04:59 UTC #8 lore raw

In reply to David Miller

Quoted 13 lines · David Miller

From: Rusty Russell <[email protected]>
Date: Mon, 15 Jul 2013 11:13:25 +0930
Quoted 10 lines
From: Michael S. Tsirkin <[email protected]>
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.

Quoted 6 lines

Quoted 2 lines
Signed-off-by Michael S. Tsirkin <[email protected]>
Signed-off-by Rusty Russell <[email protected]>
I really think this has to wait until the next merge window, sorry.
Please resubmit this when I open net-next back up, thanks.

I assumed since -rc1 is out net-next is already open?

David Miller

maintainer

2013-07-17 05:05 UTC #9 lore raw

From: "Michael S. Tsirkin" <[email protected]>
Date: Wed, 17 Jul 2013 08:00:32 +0300

Quoted 14 lines · David Miller

Quoted 13 lines
From: Rusty Russell <[email protected]>
Date: Mon, 15 Jul 2013 11:13:25 +0930
Quoted 10 lines
From: Michael S. Tsirkin <[email protected]>
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.

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
Signed-off-by Michael S. Tsirkin <[email protected]>
Signed-off-by Rusty Russell <[email protected]>
I really think this has to wait until the next merge window, sorry.
Please resubmit this when I open net-next back up, thanks.
I assumed since -rc1 is out net-next is already open?

-rc1 being released never makes net-next open. Instead, I explicitly open it up at some point in time after -rc1 when I feel that things have settled down enough.

And when that happens, I announce so here.

So you have to follow my announcements here on netdev to know when net-next is actually open.

Rusty Russell

2013-07-17 06:02 UTC #10 lore raw

Quoted 26 lines · David Miller

From: "Michael S. Tsirkin" <[email protected]>
Date: Wed, 17 Jul 2013 08:00:32 +0300
Quoted 14 lines · David Miller
Quoted 13 lines
From: Rusty Russell <[email protected]>
Date: Mon, 15 Jul 2013 11:13:25 +0930
Quoted 10 lines
From: Michael S. Tsirkin <[email protected]>
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.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Signed-off-by Michael S. Tsirkin <[email protected]>
Signed-off-by Rusty Russell <[email protected]>
I really think this has to wait until the next merge window, sorry.
Please resubmit this when I open net-next back up, thanks.
I assumed since -rc1 is out net-next is already open?

Quoted 8 lines

-rc1 being released never makes net-next open. Instead, I explicitly open it up at some point in time after -rc1 when I feel that things have settled down enough.
And when that happens, I announce so here.
So you have to follow my announcements here on netdev to know when net-next is actually open.

Thanks for letting me know. I'm sure that works well for others, but I can't follow the mailing lists of every maintainer I deal with.

Fortunately, you're the paragon for acking applied patches, so if I hit this failure mode again I will know.

Cheers,
Rusty.

Michael S. Tsirkin

author maintainer

2013-07-24 19:43 UTC #11 lore raw

Quoted 36 lines · Rusty Russell

Quoted 26 lines · David Miller
From: "Michael S. Tsirkin" <[email protected]>
Date: Wed, 17 Jul 2013 08:00:32 +0300
Quoted 14 lines · David Miller
Quoted 13 lines
From: Rusty Russell <[email protected]>
Date: Mon, 15 Jul 2013 11:13:25 +0930
Quoted 10 lines
From: Michael S. Tsirkin <[email protected]>
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.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Signed-off-by Michael S. Tsirkin <[email protected]>
Signed-off-by Rusty Russell <[email protected]>
I really think this has to wait until the next merge window, sorry.
Please resubmit this when I open net-next back up, thanks.
I assumed since -rc1 is out net-next is already open?
Quoted 8 lines
-rc1 being released never makes net-next open. Instead, I explicitly open it up at some point in time after -rc1 when I feel that things have settled down enough.
And when that happens, I announce so here.
So you have to follow my announcements here on netdev to know when net-next is actually open.

Quoted 8 lines

Thanks for letting me know. I'm sure that works well for others, but I can't follow the mailing lists of every maintainer I deal with.
Fortunately, you're the paragon for acking applied patches, so if I hit this failure mode again I will know.
Cheers,
Rusty.

In case you missed this, net-next opened Fri, 19 Jul 2013.

Signature · 1 line

MST

Michael S. Tsirkin

author maintainer

2013-07-10 06:12 UTC #12 lore raw

In reply to Rusty Russell

Quoted 38 lines · Rusty Russell

Quoted 22 lines · Michael S. Tsirkin
Quoted 21 lines · Rusty Russell
Quoted 19 lines · Michael S. Tsirkin
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 <[email protected]>
---
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?
Quoted 7 lines
Quoted 4 lines
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 :)
Quoted 5 lines
Quoted 4 lines
Secondly, it needs baking and testing time.
Cheers,
Rusty.

Quoted 7 lines

Quoted 2 lines
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 ...

Signature · 1 line

MST

Rusty Russell

2013-07-15 01:40 UTC #13 lore raw

Quoted 42 lines · Michael S. Tsirkin

Quoted 41 lines · Rusty Russell
Quoted 22 lines · Michael S. Tsirkin
Quoted 21 lines · Rusty Russell
Quoted 19 lines · Michael S. Tsirkin
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 <[email protected]>
---
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?
Quoted 7 lines
Quoted 4 lines
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 :)
Quoted 7 lines
Quoted 4 lines
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.

Quoted 7 lines

Quoted 4 lines
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.

Michael S. Tsirkin

author maintainer

2013-07-11 12:59 UTC #14 lore raw

In reply to Rusty Russell

Quoted 23 lines · Rusty Russell

Quoted 11 lines · Michael S. Tsirkin
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 <[email protected]>
---
Quoted 8 lines
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.

Quoted 7 lines

First, I've been a bit lax in sending patches via DaveM, and this is definitely his territory (ie. more net than virtio).
Secondly, it needs baking and testing time.
Cheers,
Rusty.

Okay. But we can already commit the qemu change, right? Also, can you submit the spec update please?

Rusty Russell

2013-07-12 05:57 UTC #15 lore raw

Quoted 27 lines · Michael S. Tsirkin

Quoted 26 lines · Rusty Russell
Quoted 11 lines · Michael S. Tsirkin
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 <[email protected]>
---
Quoted 8 lines
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).

Quoted 7 lines

Quoted 4 lines
Secondly, it needs baking and testing time.
Cheers,
Rusty.
Okay. But we can already commit the qemu change, right? Also, can you submit the spec update please?

The spec has been updated, BTW.

Cheers,
Rusty.