2014-02-10 13:57:48 +00:00
|
|
|
/*-
|
|
|
|
* BSD LICENSE
|
2014-06-03 23:42:50 +00:00
|
|
|
*
|
vhost: refactor code structure
The code structure is a bit messy now. For example, vhost-user message
handling is spread to three different files:
vhost-net-user.c virtio-net.c virtio-net-user.c
Where, vhost-net-user.c is the entrance to handle all those messages
and then invoke the right method for a specific message. Some of them
are stored at virtio-net.c, while others are stored at virtio-net-user.c.
The truth is all of them should be in one file, vhost_user.c.
So this patch refactors the source code structure: mainly on renaming
files and moving code from one file to another file that is more suitable
for storing it. Thus, no functional changes are made.
After the refactor, the code structure becomes to:
- socket.c handles all vhost-user socket file related stuff, such
as, socket file creation for server mode, reconnection
for client mode.
- vhost.c mainly on stuff like vhost device creation/destroy/reset.
Most of the vhost API implementation are there, too.
- vhost_user.c all stuff about vhost-user messages handling goes there.
- virtio_net.c all stuff about virtio-net should go there. It has virtio
net Rx/Tx implementation only so far: it's just a rename
from vhost_rxtx.c
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
2016-08-18 08:48:39 +00:00
|
|
|
* Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
|
2014-02-10 13:57:48 +00:00
|
|
|
* All rights reserved.
|
2014-06-03 23:42:50 +00:00
|
|
|
*
|
2014-02-10 13:57:48 +00:00
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
2014-06-03 23:42:50 +00:00
|
|
|
*
|
2014-02-10 13:57:48 +00:00
|
|
|
* * Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* * Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
* distribution.
|
|
|
|
* * Neither the name of Intel Corporation nor the names of its
|
|
|
|
* contributors may be used to endorse or promote products derived
|
|
|
|
* from this software without specific prior written permission.
|
2014-06-03 23:42:50 +00:00
|
|
|
*
|
2014-02-10 13:57:48 +00:00
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
|
|
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
|
|
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdint.h>
|
2015-10-22 12:35:52 +00:00
|
|
|
#include <stdbool.h>
|
2014-10-08 18:54:54 +00:00
|
|
|
#include <linux/virtio_net.h>
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2014-10-08 18:54:54 +00:00
|
|
|
#include <rte_mbuf.h>
|
|
|
|
#include <rte_memcpy.h>
|
2016-02-05 07:31:38 +00:00
|
|
|
#include <rte_ether.h>
|
|
|
|
#include <rte_ip.h>
|
2017-04-01 07:22:57 +00:00
|
|
|
#include <rte_vhost.h>
|
2016-02-05 07:31:38 +00:00
|
|
|
#include <rte_tcp.h>
|
|
|
|
#include <rte_udp.h>
|
|
|
|
#include <rte_sctp.h>
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
#include <rte_arp.h>
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2017-10-05 08:36:20 +00:00
|
|
|
#include "iotlb.h"
|
vhost: refactor code structure
The code structure is a bit messy now. For example, vhost-user message
handling is spread to three different files:
vhost-net-user.c virtio-net.c virtio-net-user.c
Where, vhost-net-user.c is the entrance to handle all those messages
and then invoke the right method for a specific message. Some of them
are stored at virtio-net.c, while others are stored at virtio-net-user.c.
The truth is all of them should be in one file, vhost_user.c.
So this patch refactors the source code structure: mainly on renaming
files and moving code from one file to another file that is more suitable
for storing it. Thus, no functional changes are made.
After the refactor, the code structure becomes to:
- socket.c handles all vhost-user socket file related stuff, such
as, socket file creation for server mode, reconnection
for client mode.
- vhost.c mainly on stuff like vhost device creation/destroy/reset.
Most of the vhost API implementation are there, too.
- vhost_user.c all stuff about vhost-user messages handling goes there.
- virtio_net.c all stuff about virtio-net should go there. It has virtio
net Rx/Tx implementation only so far: it's just a rename
from vhost_rxtx.c
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
2016-08-18 08:48:39 +00:00
|
|
|
#include "vhost.h"
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2014-10-08 18:54:57 +00:00
|
|
|
#define MAX_PKT_BURST 32
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
#define MAX_BATCH_LEN 256
|
|
|
|
|
2015-10-22 12:35:52 +00:00
|
|
|
static bool
|
2017-04-01 07:22:47 +00:00
|
|
|
is_valid_virt_queue_idx(uint32_t idx, int is_tx, uint32_t nr_vring)
|
2015-10-22 12:35:52 +00:00
|
|
|
{
|
2017-04-01 07:22:47 +00:00
|
|
|
return (is_tx ^ (idx & 1)) == 0 && idx < nr_vring;
|
2015-10-22 12:35:52 +00:00
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline void
|
2016-10-14 09:34:36 +00:00
|
|
|
do_flush_shadow_used_ring(struct virtio_net *dev, struct vhost_virtqueue *vq,
|
|
|
|
uint16_t to, uint16_t from, uint16_t size)
|
|
|
|
{
|
|
|
|
rte_memcpy(&vq->used->ring[to],
|
|
|
|
&vq->shadow_used_ring[from],
|
|
|
|
size * sizeof(struct vring_used_elem));
|
|
|
|
vhost_log_used_vring(dev, vq,
|
|
|
|
offsetof(struct vring_used, ring[to]),
|
|
|
|
size * sizeof(struct vring_used_elem));
|
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline void
|
2016-10-14 09:34:36 +00:00
|
|
|
flush_shadow_used_ring(struct virtio_net *dev, struct vhost_virtqueue *vq)
|
|
|
|
{
|
|
|
|
uint16_t used_idx = vq->last_used_idx & (vq->size - 1);
|
|
|
|
|
|
|
|
if (used_idx + vq->shadow_used_idx <= vq->size) {
|
|
|
|
do_flush_shadow_used_ring(dev, vq, used_idx, 0,
|
|
|
|
vq->shadow_used_idx);
|
|
|
|
} else {
|
|
|
|
uint16_t size;
|
|
|
|
|
|
|
|
/* update used ring interval [used_idx, vq->size] */
|
|
|
|
size = vq->size - used_idx;
|
|
|
|
do_flush_shadow_used_ring(dev, vq, used_idx, 0, size);
|
|
|
|
|
|
|
|
/* update the left half used ring interval [0, left_size] */
|
|
|
|
do_flush_shadow_used_ring(dev, vq, 0, size,
|
|
|
|
vq->shadow_used_idx - size);
|
|
|
|
}
|
|
|
|
vq->last_used_idx += vq->shadow_used_idx;
|
|
|
|
|
|
|
|
rte_smp_wmb();
|
|
|
|
|
|
|
|
*(volatile uint16_t *)&vq->used->idx += vq->shadow_used_idx;
|
|
|
|
vhost_log_used_vring(dev, vq, offsetof(struct vring_used, idx),
|
|
|
|
sizeof(vq->used->idx));
|
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline void
|
2016-10-14 09:34:36 +00:00
|
|
|
update_shadow_used_ring(struct vhost_virtqueue *vq,
|
|
|
|
uint16_t desc_idx, uint16_t len)
|
|
|
|
{
|
|
|
|
uint16_t i = vq->shadow_used_idx++;
|
|
|
|
|
|
|
|
vq->shadow_used_ring[i].id = desc_idx;
|
|
|
|
vq->shadow_used_ring[i].len = len;
|
|
|
|
}
|
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
static inline void
|
|
|
|
do_data_copy_enqueue(struct virtio_net *dev, struct vhost_virtqueue *vq)
|
|
|
|
{
|
|
|
|
struct batch_copy_elem *elem = vq->batch_copy_elems;
|
|
|
|
uint16_t count = vq->batch_copy_nb_elems;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
rte_memcpy(elem[i].dst, elem[i].src, elem[i].len);
|
|
|
|
vhost_log_write(dev, elem[i].log_addr, elem[i].len);
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)elem[i].dst, elem[i].len, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
do_data_copy_dequeue(struct vhost_virtqueue *vq)
|
|
|
|
{
|
|
|
|
struct batch_copy_elem *elem = vq->batch_copy_elems;
|
|
|
|
uint16_t count = vq->batch_copy_nb_elems;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
rte_memcpy(elem[i].dst, elem[i].src, elem[i].len);
|
|
|
|
}
|
|
|
|
|
2017-04-14 07:53:18 +00:00
|
|
|
/* avoid write operation when necessary, to lessen cache issues */
|
|
|
|
#define ASSIGN_UNLESS_EQUAL(var, val) do { \
|
|
|
|
if ((var) != (val)) \
|
|
|
|
(var) = (val); \
|
|
|
|
} while (0)
|
|
|
|
|
vhost: add guest offload setting
Add guest offload setting in vhost lib.
Virtio 1.0 spec (5.1.6.4 Processing of Incoming Packets) says:
1. If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
VIRTIO_NET_HDR_F_NEEDS_CSUM bit in flags can be set: if so,
the packet checksum at offset csum_offset from csum_start
and any preceding checksums have been validated. The checksum
on the packet is incomplete and csum_start and csum_offset
indicate how to calculate it (see Packet Transmission point 1).
2. If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
negotiated, then gso_type MAY be something other than
VIRTIO_NET_HDR_GSO_NONE, and gso_size field indicates the
desired MSS (see Packet Transmission point 2).
In order to support these features, the following changes are added,
1. Extend 'VHOST_SUPPORTED_FEATURES' macro to add the offload features negotiation.
2. Enqueue these offloads: convert some fields in mbuf to the fields in virtio_net_hdr.
There are more explanations for the implementation.
For VM2VM case, there is no need to do checksum, for we think the
data should be reliable enough, and setting VIRTIO_NET_HDR_F_NEEDS_CSUM
at RX side will let the TCP layer to bypass the checksum validation,
so that the RX side could receive the packet in the end.
In terms of us-vhost, at vhost RX side, the offload information is
inherited from mbuf, which is in turn inherited from TX side. If we
can still get those info at RX side, it means the packet is from
another VM at same host. So, it's safe to set the
VIRTIO_NET_HDR_F_NEEDS_CSUM, to skip checksum validation.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-05 07:31:39 +00:00
|
|
|
static void
|
|
|
|
virtio_enqueue_offload(struct rte_mbuf *m_buf, struct virtio_net_hdr *net_hdr)
|
|
|
|
{
|
2017-06-07 06:41:36 +00:00
|
|
|
uint64_t csum_l4 = m_buf->ol_flags & PKT_TX_L4_MASK;
|
|
|
|
|
|
|
|
if (m_buf->ol_flags & PKT_TX_TCP_SEG)
|
|
|
|
csum_l4 |= PKT_TX_TCP_CKSUM;
|
|
|
|
|
|
|
|
if (csum_l4) {
|
vhost: add guest offload setting
Add guest offload setting in vhost lib.
Virtio 1.0 spec (5.1.6.4 Processing of Incoming Packets) says:
1. If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
VIRTIO_NET_HDR_F_NEEDS_CSUM bit in flags can be set: if so,
the packet checksum at offset csum_offset from csum_start
and any preceding checksums have been validated. The checksum
on the packet is incomplete and csum_start and csum_offset
indicate how to calculate it (see Packet Transmission point 1).
2. If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
negotiated, then gso_type MAY be something other than
VIRTIO_NET_HDR_GSO_NONE, and gso_size field indicates the
desired MSS (see Packet Transmission point 2).
In order to support these features, the following changes are added,
1. Extend 'VHOST_SUPPORTED_FEATURES' macro to add the offload features negotiation.
2. Enqueue these offloads: convert some fields in mbuf to the fields in virtio_net_hdr.
There are more explanations for the implementation.
For VM2VM case, there is no need to do checksum, for we think the
data should be reliable enough, and setting VIRTIO_NET_HDR_F_NEEDS_CSUM
at RX side will let the TCP layer to bypass the checksum validation,
so that the RX side could receive the packet in the end.
In terms of us-vhost, at vhost RX side, the offload information is
inherited from mbuf, which is in turn inherited from TX side. If we
can still get those info at RX side, it means the packet is from
another VM at same host. So, it's safe to set the
VIRTIO_NET_HDR_F_NEEDS_CSUM, to skip checksum validation.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-05 07:31:39 +00:00
|
|
|
net_hdr->flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
|
|
|
|
net_hdr->csum_start = m_buf->l2_len + m_buf->l3_len;
|
|
|
|
|
2017-06-07 06:41:36 +00:00
|
|
|
switch (csum_l4) {
|
vhost: add guest offload setting
Add guest offload setting in vhost lib.
Virtio 1.0 spec (5.1.6.4 Processing of Incoming Packets) says:
1. If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
VIRTIO_NET_HDR_F_NEEDS_CSUM bit in flags can be set: if so,
the packet checksum at offset csum_offset from csum_start
and any preceding checksums have been validated. The checksum
on the packet is incomplete and csum_start and csum_offset
indicate how to calculate it (see Packet Transmission point 1).
2. If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
negotiated, then gso_type MAY be something other than
VIRTIO_NET_HDR_GSO_NONE, and gso_size field indicates the
desired MSS (see Packet Transmission point 2).
In order to support these features, the following changes are added,
1. Extend 'VHOST_SUPPORTED_FEATURES' macro to add the offload features negotiation.
2. Enqueue these offloads: convert some fields in mbuf to the fields in virtio_net_hdr.
There are more explanations for the implementation.
For VM2VM case, there is no need to do checksum, for we think the
data should be reliable enough, and setting VIRTIO_NET_HDR_F_NEEDS_CSUM
at RX side will let the TCP layer to bypass the checksum validation,
so that the RX side could receive the packet in the end.
In terms of us-vhost, at vhost RX side, the offload information is
inherited from mbuf, which is in turn inherited from TX side. If we
can still get those info at RX side, it means the packet is from
another VM at same host. So, it's safe to set the
VIRTIO_NET_HDR_F_NEEDS_CSUM, to skip checksum validation.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-05 07:31:39 +00:00
|
|
|
case PKT_TX_TCP_CKSUM:
|
|
|
|
net_hdr->csum_offset = (offsetof(struct tcp_hdr,
|
|
|
|
cksum));
|
|
|
|
break;
|
|
|
|
case PKT_TX_UDP_CKSUM:
|
|
|
|
net_hdr->csum_offset = (offsetof(struct udp_hdr,
|
|
|
|
dgram_cksum));
|
|
|
|
break;
|
|
|
|
case PKT_TX_SCTP_CKSUM:
|
|
|
|
net_hdr->csum_offset = (offsetof(struct sctp_hdr,
|
|
|
|
cksum));
|
|
|
|
break;
|
|
|
|
}
|
2017-04-14 07:53:18 +00:00
|
|
|
} else {
|
|
|
|
ASSIGN_UNLESS_EQUAL(net_hdr->csum_start, 0);
|
|
|
|
ASSIGN_UNLESS_EQUAL(net_hdr->csum_offset, 0);
|
|
|
|
ASSIGN_UNLESS_EQUAL(net_hdr->flags, 0);
|
vhost: add guest offload setting
Add guest offload setting in vhost lib.
Virtio 1.0 spec (5.1.6.4 Processing of Incoming Packets) says:
1. If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
VIRTIO_NET_HDR_F_NEEDS_CSUM bit in flags can be set: if so,
the packet checksum at offset csum_offset from csum_start
and any preceding checksums have been validated. The checksum
on the packet is incomplete and csum_start and csum_offset
indicate how to calculate it (see Packet Transmission point 1).
2. If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
negotiated, then gso_type MAY be something other than
VIRTIO_NET_HDR_GSO_NONE, and gso_size field indicates the
desired MSS (see Packet Transmission point 2).
In order to support these features, the following changes are added,
1. Extend 'VHOST_SUPPORTED_FEATURES' macro to add the offload features negotiation.
2. Enqueue these offloads: convert some fields in mbuf to the fields in virtio_net_hdr.
There are more explanations for the implementation.
For VM2VM case, there is no need to do checksum, for we think the
data should be reliable enough, and setting VIRTIO_NET_HDR_F_NEEDS_CSUM
at RX side will let the TCP layer to bypass the checksum validation,
so that the RX side could receive the packet in the end.
In terms of us-vhost, at vhost RX side, the offload information is
inherited from mbuf, which is in turn inherited from TX side. If we
can still get those info at RX side, it means the packet is from
another VM at same host. So, it's safe to set the
VIRTIO_NET_HDR_F_NEEDS_CSUM, to skip checksum validation.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-05 07:31:39 +00:00
|
|
|
}
|
|
|
|
|
2017-06-07 06:41:37 +00:00
|
|
|
/* IP cksum verification cannot be bypassed, then calculate here */
|
|
|
|
if (m_buf->ol_flags & PKT_TX_IP_CKSUM) {
|
|
|
|
struct ipv4_hdr *ipv4_hdr;
|
|
|
|
|
|
|
|
ipv4_hdr = rte_pktmbuf_mtod_offset(m_buf, struct ipv4_hdr *,
|
|
|
|
m_buf->l2_len);
|
|
|
|
ipv4_hdr->hdr_checksum = rte_ipv4_cksum(ipv4_hdr);
|
|
|
|
}
|
|
|
|
|
vhost: add guest offload setting
Add guest offload setting in vhost lib.
Virtio 1.0 spec (5.1.6.4 Processing of Incoming Packets) says:
1. If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
VIRTIO_NET_HDR_F_NEEDS_CSUM bit in flags can be set: if so,
the packet checksum at offset csum_offset from csum_start
and any preceding checksums have been validated. The checksum
on the packet is incomplete and csum_start and csum_offset
indicate how to calculate it (see Packet Transmission point 1).
2. If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
negotiated, then gso_type MAY be something other than
VIRTIO_NET_HDR_GSO_NONE, and gso_size field indicates the
desired MSS (see Packet Transmission point 2).
In order to support these features, the following changes are added,
1. Extend 'VHOST_SUPPORTED_FEATURES' macro to add the offload features negotiation.
2. Enqueue these offloads: convert some fields in mbuf to the fields in virtio_net_hdr.
There are more explanations for the implementation.
For VM2VM case, there is no need to do checksum, for we think the
data should be reliable enough, and setting VIRTIO_NET_HDR_F_NEEDS_CSUM
at RX side will let the TCP layer to bypass the checksum validation,
so that the RX side could receive the packet in the end.
In terms of us-vhost, at vhost RX side, the offload information is
inherited from mbuf, which is in turn inherited from TX side. If we
can still get those info at RX side, it means the packet is from
another VM at same host. So, it's safe to set the
VIRTIO_NET_HDR_F_NEEDS_CSUM, to skip checksum validation.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-05 07:31:39 +00:00
|
|
|
if (m_buf->ol_flags & PKT_TX_TCP_SEG) {
|
|
|
|
if (m_buf->ol_flags & PKT_TX_IPV4)
|
|
|
|
net_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
|
|
|
|
else
|
|
|
|
net_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
|
|
|
|
net_hdr->gso_size = m_buf->tso_segsz;
|
|
|
|
net_hdr->hdr_len = m_buf->l2_len + m_buf->l3_len
|
|
|
|
+ m_buf->l4_len;
|
2017-04-14 07:53:18 +00:00
|
|
|
} else {
|
|
|
|
ASSIGN_UNLESS_EQUAL(net_hdr->gso_type, 0);
|
|
|
|
ASSIGN_UNLESS_EQUAL(net_hdr->gso_size, 0);
|
|
|
|
ASSIGN_UNLESS_EQUAL(net_hdr->hdr_len, 0);
|
vhost: add guest offload setting
Add guest offload setting in vhost lib.
Virtio 1.0 spec (5.1.6.4 Processing of Incoming Packets) says:
1. If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
VIRTIO_NET_HDR_F_NEEDS_CSUM bit in flags can be set: if so,
the packet checksum at offset csum_offset from csum_start
and any preceding checksums have been validated. The checksum
on the packet is incomplete and csum_start and csum_offset
indicate how to calculate it (see Packet Transmission point 1).
2. If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
negotiated, then gso_type MAY be something other than
VIRTIO_NET_HDR_GSO_NONE, and gso_size field indicates the
desired MSS (see Packet Transmission point 2).
In order to support these features, the following changes are added,
1. Extend 'VHOST_SUPPORTED_FEATURES' macro to add the offload features negotiation.
2. Enqueue these offloads: convert some fields in mbuf to the fields in virtio_net_hdr.
There are more explanations for the implementation.
For VM2VM case, there is no need to do checksum, for we think the
data should be reliable enough, and setting VIRTIO_NET_HDR_F_NEEDS_CSUM
at RX side will let the TCP layer to bypass the checksum validation,
so that the RX side could receive the packet in the end.
In terms of us-vhost, at vhost RX side, the offload information is
inherited from mbuf, which is in turn inherited from TX side. If we
can still get those info at RX side, it means the packet is from
another VM at same host. So, it's safe to set the
VIRTIO_NET_HDR_F_NEEDS_CSUM, to skip checksum validation.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-05 07:31:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline int
|
2017-09-08 12:50:46 +00:00
|
|
|
copy_mbuf_to_desc(struct virtio_net *dev, struct vhost_virtqueue *vq,
|
|
|
|
struct vring_desc *descs, struct rte_mbuf *m,
|
|
|
|
uint16_t desc_idx, uint32_t size)
|
2016-03-10 04:32:40 +00:00
|
|
|
{
|
|
|
|
uint32_t desc_avail, desc_offset;
|
|
|
|
uint32_t mbuf_avail, mbuf_offset;
|
|
|
|
uint32_t cpy_len;
|
|
|
|
struct vring_desc *desc;
|
|
|
|
uint64_t desc_addr;
|
2017-01-22 08:46:58 +00:00
|
|
|
/* A counter to avoid desc dead loop chain */
|
|
|
|
uint16_t nr_desc = 1;
|
2017-09-08 12:50:46 +00:00
|
|
|
struct batch_copy_elem *batch_copy = vq->batch_copy_elems;
|
|
|
|
uint16_t copy_nb = vq->batch_copy_nb_elems;
|
|
|
|
int error = 0;
|
2016-03-10 04:32:40 +00:00
|
|
|
|
2016-10-18 15:35:39 +00:00
|
|
|
desc = &descs[desc_idx];
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr = vhost_iova_to_vva(dev, vq, desc->addr,
|
|
|
|
desc->len, VHOST_ACCESS_RW);
|
2016-07-15 11:15:05 +00:00
|
|
|
/*
|
|
|
|
* Checking of 'desc_addr' placed outside of 'unlikely' macro to avoid
|
|
|
|
* performance issue with some versions of gcc (4.8.4 and 5.3.0) which
|
|
|
|
* otherwise stores offset on the stack instead of in a register.
|
|
|
|
*/
|
2017-09-08 12:50:46 +00:00
|
|
|
if (unlikely(desc->len < dev->vhost_hlen) || !desc_addr) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
vhost: do sanity check for ring descriptor length
We need make sure that desc->len is bigger than the size of virtio net
header, otherwise, unexpected behaviour might happen due to "desc_avail"
would become a huge number with for following code:
desc_avail = desc->len - vq->vhost_hlen;
For dequeue code path, it will try to allocate enough mbuf to hold such
size of desc buf, which ends up with consuming all mbufs, leading to no
free mbuf is available. Therefore, you might see an error message:
Failed to allocate memory for mbuf.
Also, for both dequeue/enqueue code path, while it copies data from/to
desc buf, the big "desc_avail" would result to access memory not belong
the desc buf, which could lead to some potential memory access errors.
A malicious guest could easily forge such malformed vring desc buf. Every
time we restart an interrupted DPDK application inside guest would also
trigger this issue, as all huge pages are reset to 0 during DPDK re-init,
leading to desc->len being 0.
Therefore, this patch does a sanity check for desc->len, to make vhost
robust.
Reported-by: Rich Lane <rich.lane@bigswitch.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-03-10 04:32:44 +00:00
|
|
|
|
2016-03-10 04:32:40 +00:00
|
|
|
rte_prefetch0((void *)(uintptr_t)desc_addr);
|
|
|
|
|
2017-04-14 07:53:18 +00:00
|
|
|
virtio_enqueue_offload(m, (struct virtio_net_hdr *)(uintptr_t)desc_addr);
|
2016-05-01 23:58:52 +00:00
|
|
|
vhost_log_write(dev, desc->addr, dev->vhost_hlen);
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)desc_addr, dev->vhost_hlen, 0);
|
2016-03-10 04:32:40 +00:00
|
|
|
|
2016-05-01 23:58:52 +00:00
|
|
|
desc_offset = dev->vhost_hlen;
|
|
|
|
desc_avail = desc->len - dev->vhost_hlen;
|
2016-03-10 04:32:40 +00:00
|
|
|
|
|
|
|
mbuf_avail = rte_pktmbuf_data_len(m);
|
|
|
|
mbuf_offset = 0;
|
|
|
|
while (mbuf_avail != 0 || m->next != NULL) {
|
|
|
|
/* done with current mbuf, fetch next */
|
|
|
|
if (mbuf_avail == 0) {
|
|
|
|
m = m->next;
|
|
|
|
|
|
|
|
mbuf_offset = 0;
|
|
|
|
mbuf_avail = rte_pktmbuf_data_len(m);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* done with current desc buf, fetch next */
|
|
|
|
if (desc_avail == 0) {
|
|
|
|
if ((desc->flags & VRING_DESC_F_NEXT) == 0) {
|
|
|
|
/* Room in vring buffer is not enough */
|
2017-09-08 12:50:46 +00:00
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
if (unlikely(desc->next >= size || ++nr_desc > size)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
2016-03-10 04:32:40 +00:00
|
|
|
}
|
|
|
|
|
2016-10-18 15:35:39 +00:00
|
|
|
desc = &descs[desc->next];
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr = vhost_iova_to_vva(dev, vq, desc->addr,
|
|
|
|
desc->len,
|
|
|
|
VHOST_ACCESS_RW);
|
2017-09-08 12:50:46 +00:00
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
2016-07-15 11:15:05 +00:00
|
|
|
|
2016-03-10 04:32:40 +00:00
|
|
|
desc_offset = 0;
|
|
|
|
desc_avail = desc->len;
|
|
|
|
}
|
|
|
|
|
|
|
|
cpy_len = RTE_MIN(desc_avail, mbuf_avail);
|
2017-09-08 12:50:46 +00:00
|
|
|
if (likely(cpy_len > MAX_BATCH_LEN || copy_nb >= vq->size)) {
|
|
|
|
rte_memcpy((void *)((uintptr_t)(desc_addr +
|
|
|
|
desc_offset)),
|
|
|
|
rte_pktmbuf_mtod_offset(m, void *, mbuf_offset),
|
|
|
|
cpy_len);
|
|
|
|
vhost_log_write(dev, desc->addr + desc_offset, cpy_len);
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)(desc_addr + desc_offset),
|
|
|
|
cpy_len, 0);
|
|
|
|
} else {
|
|
|
|
batch_copy[copy_nb].dst =
|
|
|
|
(void *)((uintptr_t)(desc_addr + desc_offset));
|
|
|
|
batch_copy[copy_nb].src =
|
|
|
|
rte_pktmbuf_mtod_offset(m, void *, mbuf_offset);
|
|
|
|
batch_copy[copy_nb].log_addr = desc->addr + desc_offset;
|
|
|
|
batch_copy[copy_nb].len = cpy_len;
|
|
|
|
copy_nb++;
|
|
|
|
}
|
2016-03-10 04:32:40 +00:00
|
|
|
|
|
|
|
mbuf_avail -= cpy_len;
|
|
|
|
mbuf_offset += cpy_len;
|
|
|
|
desc_avail -= cpy_len;
|
|
|
|
desc_offset += cpy_len;
|
|
|
|
}
|
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
out:
|
|
|
|
vq->batch_copy_nb_elems = copy_nb;
|
|
|
|
|
|
|
|
return error;
|
2016-03-10 04:32:40 +00:00
|
|
|
}
|
|
|
|
|
2014-10-08 18:54:57 +00:00
|
|
|
/**
|
2014-02-10 13:57:48 +00:00
|
|
|
* This function adds buffers to the virtio devices RX virtqueue. Buffers can
|
|
|
|
* be received from the physical port or from another virtio device. A packet
|
2017-06-07 05:05:06 +00:00
|
|
|
* count is returned to indicate the number of packets that are successfully
|
2015-06-09 01:03:01 +00:00
|
|
|
* added to the RX queue. This function works when the mbuf is scattered, but
|
|
|
|
* it doesn't support the mergeable feature.
|
2014-02-10 13:57:48 +00:00
|
|
|
*/
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline uint32_t
|
2014-10-08 18:54:57 +00:00
|
|
|
virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
|
2016-03-10 04:32:40 +00:00
|
|
|
struct rte_mbuf **pkts, uint32_t count)
|
2014-02-10 13:57:48 +00:00
|
|
|
{
|
|
|
|
struct vhost_virtqueue *vq;
|
2016-06-13 11:52:12 +00:00
|
|
|
uint16_t avail_idx, free_entries, start_idx;
|
2016-03-10 04:32:40 +00:00
|
|
|
uint16_t desc_indexes[MAX_PKT_BURST];
|
2016-10-18 15:35:39 +00:00
|
|
|
struct vring_desc *descs;
|
2016-05-03 00:46:16 +00:00
|
|
|
uint16_t used_idx;
|
2016-10-18 15:35:39 +00:00
|
|
|
uint32_t i, sz;
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2016-05-23 08:36:33 +00:00
|
|
|
LOG_DEBUG(VHOST_DATA, "(%d) %s\n", dev->vid, __func__);
|
2017-04-01 07:22:47 +00:00
|
|
|
if (unlikely(!is_valid_virt_queue_idx(queue_id, 0, dev->nr_vring))) {
|
2016-04-29 20:45:51 +00:00
|
|
|
RTE_LOG(ERR, VHOST_DATA, "(%d) %s: invalid virtqueue idx %d.\n",
|
2016-05-23 08:36:33 +00:00
|
|
|
dev->vid, __func__, queue_id);
|
2014-10-08 18:54:43 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-10-22 12:35:52 +00:00
|
|
|
vq = dev->virtqueue[queue_id];
|
2015-10-22 12:35:54 +00:00
|
|
|
if (unlikely(vq->enabled == 0))
|
|
|
|
return 0;
|
|
|
|
|
2017-10-05 08:36:25 +00:00
|
|
|
if (dev->features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))
|
|
|
|
vhost_user_iotlb_rd_lock(vq);
|
|
|
|
|
|
|
|
if (unlikely(vq->access_ok == 0)) {
|
|
|
|
if (unlikely(vring_translate(dev, vq) < 0)) {
|
|
|
|
count = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-13 11:52:12 +00:00
|
|
|
avail_idx = *((volatile uint16_t *)&vq->avail->idx);
|
|
|
|
start_idx = vq->last_used_idx;
|
|
|
|
free_entries = avail_idx - start_idx;
|
|
|
|
count = RTE_MIN(count, free_entries);
|
|
|
|
count = RTE_MIN(count, (uint32_t)MAX_PKT_BURST);
|
2016-03-10 04:32:40 +00:00
|
|
|
if (count == 0)
|
2017-10-05 08:36:25 +00:00
|
|
|
goto out;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-06-13 11:52:12 +00:00
|
|
|
LOG_DEBUG(VHOST_DATA, "(%d) start_idx %d | end_idx %d\n",
|
|
|
|
dev->vid, start_idx, start_idx + count);
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
vq->batch_copy_nb_elems = 0;
|
|
|
|
|
2016-03-10 04:32:40 +00:00
|
|
|
/* Retrieve all of the desc indexes first to avoid caching issues. */
|
2016-06-13 11:52:12 +00:00
|
|
|
rte_prefetch0(&vq->avail->ring[start_idx & (vq->size - 1)]);
|
2016-03-10 04:32:40 +00:00
|
|
|
for (i = 0; i < count; i++) {
|
2016-06-13 11:52:12 +00:00
|
|
|
used_idx = (start_idx + i) & (vq->size - 1);
|
2016-05-03 00:46:16 +00:00
|
|
|
desc_indexes[i] = vq->avail->ring[used_idx];
|
|
|
|
vq->used->ring[used_idx].id = desc_indexes[i];
|
|
|
|
vq->used->ring[used_idx].len = pkts[i]->pkt_len +
|
|
|
|
dev->vhost_hlen;
|
|
|
|
vhost_log_used_vring(dev, vq,
|
|
|
|
offsetof(struct vring_used, ring[used_idx]),
|
|
|
|
sizeof(vq->used->ring[used_idx]));
|
2016-03-10 04:32:40 +00:00
|
|
|
}
|
2015-06-09 01:03:01 +00:00
|
|
|
|
2016-03-10 04:32:40 +00:00
|
|
|
rte_prefetch0(&vq->desc[desc_indexes[0]]);
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
uint16_t desc_idx = desc_indexes[i];
|
|
|
|
int err;
|
2015-06-09 01:03:01 +00:00
|
|
|
|
2016-10-18 15:35:39 +00:00
|
|
|
if (vq->desc[desc_idx].flags & VRING_DESC_F_INDIRECT) {
|
2017-04-01 07:22:46 +00:00
|
|
|
descs = (struct vring_desc *)(uintptr_t)
|
2017-10-05 08:36:20 +00:00
|
|
|
vhost_iova_to_vva(dev,
|
|
|
|
vq, vq->desc[desc_idx].addr,
|
|
|
|
vq->desc[desc_idx].len,
|
|
|
|
VHOST_ACCESS_RO);
|
2016-10-18 15:35:39 +00:00
|
|
|
if (unlikely(!descs)) {
|
|
|
|
count = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
desc_idx = 0;
|
|
|
|
sz = vq->desc[desc_idx].len / sizeof(*descs);
|
|
|
|
} else {
|
|
|
|
descs = vq->desc;
|
|
|
|
sz = vq->size;
|
|
|
|
}
|
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
err = copy_mbuf_to_desc(dev, vq, descs, pkts[i], desc_idx, sz);
|
2016-05-03 00:46:16 +00:00
|
|
|
if (unlikely(err)) {
|
2017-10-05 08:36:10 +00:00
|
|
|
count = i;
|
|
|
|
break;
|
2016-05-03 00:46:16 +00:00
|
|
|
}
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2016-03-10 04:32:40 +00:00
|
|
|
if (i + 1 < count)
|
|
|
|
rte_prefetch0(&vq->desc[desc_indexes[i+1]]);
|
2014-02-10 13:57:48 +00:00
|
|
|
}
|
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
do_data_copy_enqueue(dev, vq);
|
|
|
|
|
2016-03-18 12:23:53 +00:00
|
|
|
rte_smp_wmb();
|
2014-02-10 13:57:48 +00:00
|
|
|
|
|
|
|
*(volatile uint16_t *)&vq->used->idx += count;
|
2016-06-13 11:52:12 +00:00
|
|
|
vq->last_used_idx += count;
|
2016-01-29 04:57:57 +00:00
|
|
|
vhost_log_used_vring(dev, vq,
|
|
|
|
offsetof(struct vring_used, idx),
|
|
|
|
sizeof(vq->used->idx));
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2015-04-29 11:11:24 +00:00
|
|
|
/* flush used->idx update before we read avail->flags. */
|
|
|
|
rte_mb();
|
|
|
|
|
2014-02-10 13:57:48 +00:00
|
|
|
/* Kick the guest if necessary. */
|
2016-03-14 08:53:32 +00:00
|
|
|
if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
|
|
|
|
&& (vq->callfd >= 0))
|
2015-09-09 05:34:36 +00:00
|
|
|
eventfd_write(vq->callfd, (eventfd_t)1);
|
2017-10-05 08:36:25 +00:00
|
|
|
out:
|
|
|
|
if (dev->features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))
|
|
|
|
vhost_user_iotlb_rd_unlock(vq);
|
|
|
|
|
2014-02-10 13:57:48 +00:00
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline int
|
2016-10-18 15:35:38 +00:00
|
|
|
fill_vec_buf(struct virtio_net *dev, struct vhost_virtqueue *vq,
|
|
|
|
uint32_t avail_idx, uint32_t *vec_idx,
|
|
|
|
struct buf_vector *buf_vec, uint16_t *desc_chain_head,
|
|
|
|
uint16_t *desc_chain_len)
|
2014-08-15 04:58:01 +00:00
|
|
|
{
|
2016-03-14 07:35:22 +00:00
|
|
|
uint16_t idx = vq->avail->ring[avail_idx & (vq->size - 1)];
|
|
|
|
uint32_t vec_id = *vec_idx;
|
2016-10-14 09:34:36 +00:00
|
|
|
uint32_t len = 0;
|
2016-10-18 15:35:38 +00:00
|
|
|
struct vring_desc *descs = vq->desc;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-10-14 09:34:36 +00:00
|
|
|
*desc_chain_head = idx;
|
2016-10-18 15:35:38 +00:00
|
|
|
|
|
|
|
if (vq->desc[idx].flags & VRING_DESC_F_INDIRECT) {
|
|
|
|
descs = (struct vring_desc *)(uintptr_t)
|
2017-10-05 08:36:20 +00:00
|
|
|
vhost_iova_to_vva(dev, vq, vq->desc[idx].addr,
|
|
|
|
vq->desc[idx].len,
|
|
|
|
VHOST_ACCESS_RO);
|
2016-10-18 15:35:38 +00:00
|
|
|
if (unlikely(!descs))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
idx = 0;
|
|
|
|
}
|
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
while (1) {
|
2016-03-10 04:32:45 +00:00
|
|
|
if (unlikely(vec_id >= BUF_VECTOR_MAX || idx >= vq->size))
|
2016-03-14 07:35:22 +00:00
|
|
|
return -1;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-10-18 15:35:38 +00:00
|
|
|
len += descs[idx].len;
|
|
|
|
buf_vec[vec_id].buf_addr = descs[idx].addr;
|
|
|
|
buf_vec[vec_id].buf_len = descs[idx].len;
|
2016-05-02 18:30:41 +00:00
|
|
|
buf_vec[vec_id].desc_idx = idx;
|
2016-03-14 07:35:22 +00:00
|
|
|
vec_id++;
|
2015-10-22 12:35:54 +00:00
|
|
|
|
2016-10-18 15:35:38 +00:00
|
|
|
if ((descs[idx].flags & VRING_DESC_F_NEXT) == 0)
|
2016-03-14 07:35:22 +00:00
|
|
|
break;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-10-18 15:35:38 +00:00
|
|
|
idx = descs[idx].next;
|
2016-03-14 07:35:22 +00:00
|
|
|
}
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-10-14 09:34:36 +00:00
|
|
|
*desc_chain_len = len;
|
|
|
|
*vec_idx = vec_id;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
/*
|
|
|
|
* Returns -1 on fail, 0 on success
|
|
|
|
*/
|
|
|
|
static inline int
|
2016-10-18 15:35:38 +00:00
|
|
|
reserve_avail_buf_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
|
|
|
|
uint32_t size, struct buf_vector *buf_vec,
|
|
|
|
uint16_t *num_buffers, uint16_t avail_head)
|
2016-03-14 07:35:22 +00:00
|
|
|
{
|
2016-06-13 11:52:12 +00:00
|
|
|
uint16_t cur_idx;
|
|
|
|
uint32_t vec_idx = 0;
|
|
|
|
uint16_t tries = 0;
|
vhost: add guest offload setting
Add guest offload setting in vhost lib.
Virtio 1.0 spec (5.1.6.4 Processing of Incoming Packets) says:
1. If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
VIRTIO_NET_HDR_F_NEEDS_CSUM bit in flags can be set: if so,
the packet checksum at offset csum_offset from csum_start
and any preceding checksums have been validated. The checksum
on the packet is incomplete and csum_start and csum_offset
indicate how to calculate it (see Packet Transmission point 1).
2. If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
negotiated, then gso_type MAY be something other than
VIRTIO_NET_HDR_GSO_NONE, and gso_size field indicates the
desired MSS (see Packet Transmission point 2).
In order to support these features, the following changes are added,
1. Extend 'VHOST_SUPPORTED_FEATURES' macro to add the offload features negotiation.
2. Enqueue these offloads: convert some fields in mbuf to the fields in virtio_net_hdr.
There are more explanations for the implementation.
For VM2VM case, there is no need to do checksum, for we think the
data should be reliable enough, and setting VIRTIO_NET_HDR_F_NEEDS_CSUM
at RX side will let the TCP layer to bypass the checksum validation,
so that the RX side could receive the packet in the end.
In terms of us-vhost, at vhost RX side, the offload information is
inherited from mbuf, which is in turn inherited from TX side. If we
can still get those info at RX side, it means the packet is from
another VM at same host. So, it's safe to set the
VIRTIO_NET_HDR_F_NEEDS_CSUM, to skip checksum validation.
Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-05 07:31:39 +00:00
|
|
|
|
2016-10-14 09:34:36 +00:00
|
|
|
uint16_t head_idx = 0;
|
|
|
|
uint16_t len = 0;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-10-14 09:34:36 +00:00
|
|
|
*num_buffers = 0;
|
|
|
|
cur_idx = vq->last_avail_idx;
|
|
|
|
|
|
|
|
while (size > 0) {
|
2016-10-14 09:34:38 +00:00
|
|
|
if (unlikely(cur_idx == avail_head))
|
2016-03-14 07:35:22 +00:00
|
|
|
return -1;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-10-18 15:35:38 +00:00
|
|
|
if (unlikely(fill_vec_buf(dev, vq, cur_idx, &vec_idx, buf_vec,
|
|
|
|
&head_idx, &len) < 0))
|
2016-03-14 07:35:22 +00:00
|
|
|
return -1;
|
2016-10-14 09:34:36 +00:00
|
|
|
len = RTE_MIN(len, size);
|
|
|
|
update_shadow_used_ring(vq, head_idx, len);
|
|
|
|
size -= len;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-06-13 11:52:12 +00:00
|
|
|
cur_idx++;
|
2016-03-14 07:35:22 +00:00
|
|
|
tries++;
|
2016-10-14 09:34:36 +00:00
|
|
|
*num_buffers += 1;
|
2016-01-29 04:57:57 +00:00
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
/*
|
|
|
|
* if we tried all available ring items, and still
|
|
|
|
* can't get enough buf, it means something abnormal
|
|
|
|
* happened.
|
|
|
|
*/
|
|
|
|
if (unlikely(tries >= vq->size))
|
|
|
|
return -1;
|
|
|
|
}
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline int
|
2017-09-08 12:50:46 +00:00
|
|
|
copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
|
|
|
|
struct rte_mbuf *m, struct buf_vector *buf_vec,
|
|
|
|
uint16_t num_buffers)
|
2016-03-14 07:35:22 +00:00
|
|
|
{
|
|
|
|
uint32_t vec_idx = 0;
|
|
|
|
uint64_t desc_addr;
|
|
|
|
uint32_t mbuf_offset, mbuf_avail;
|
|
|
|
uint32_t desc_offset, desc_avail;
|
|
|
|
uint32_t cpy_len;
|
2016-10-14 09:34:33 +00:00
|
|
|
uint64_t hdr_addr, hdr_phys_addr;
|
|
|
|
struct rte_mbuf *hdr_mbuf;
|
2017-09-08 12:50:46 +00:00
|
|
|
struct batch_copy_elem *batch_copy = vq->batch_copy_elems;
|
|
|
|
uint16_t copy_nb = vq->batch_copy_nb_elems;
|
|
|
|
int error = 0;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
if (unlikely(m == NULL)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr = vhost_iova_to_vva(dev, vq, buf_vec[vec_idx].buf_addr,
|
|
|
|
buf_vec[vec_idx].buf_len,
|
|
|
|
VHOST_ACCESS_RW);
|
2017-09-08 12:50:46 +00:00
|
|
|
if (buf_vec[vec_idx].buf_len < dev->vhost_hlen || !desc_addr) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
vhost: do sanity check for ring descriptor length
We need make sure that desc->len is bigger than the size of virtio net
header, otherwise, unexpected behaviour might happen due to "desc_avail"
would become a huge number with for following code:
desc_avail = desc->len - vq->vhost_hlen;
For dequeue code path, it will try to allocate enough mbuf to hold such
size of desc buf, which ends up with consuming all mbufs, leading to no
free mbuf is available. Therefore, you might see an error message:
Failed to allocate memory for mbuf.
Also, for both dequeue/enqueue code path, while it copies data from/to
desc buf, the big "desc_avail" would result to access memory not belong
the desc buf, which could lead to some potential memory access errors.
A malicious guest could easily forge such malformed vring desc buf. Every
time we restart an interrupted DPDK application inside guest would also
trigger this issue, as all huge pages are reset to 0 during DPDK re-init,
leading to desc->len being 0.
Therefore, this patch does a sanity check for desc->len, to make vhost
robust.
Reported-by: Rich Lane <rich.lane@bigswitch.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-03-10 04:32:44 +00:00
|
|
|
|
2016-10-14 09:34:33 +00:00
|
|
|
hdr_mbuf = m;
|
|
|
|
hdr_addr = desc_addr;
|
|
|
|
hdr_phys_addr = buf_vec[vec_idx].buf_addr;
|
|
|
|
rte_prefetch0((void *)(uintptr_t)hdr_addr);
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-04-29 20:45:51 +00:00
|
|
|
LOG_DEBUG(VHOST_DATA, "(%d) RX: num merge buffers %d\n",
|
2016-10-14 09:34:36 +00:00
|
|
|
dev->vid, num_buffers);
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-05-02 18:30:41 +00:00
|
|
|
desc_avail = buf_vec[vec_idx].buf_len - dev->vhost_hlen;
|
2016-05-01 23:58:52 +00:00
|
|
|
desc_offset = dev->vhost_hlen;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
mbuf_avail = rte_pktmbuf_data_len(m);
|
|
|
|
mbuf_offset = 0;
|
|
|
|
while (mbuf_avail != 0 || m->next != NULL) {
|
|
|
|
/* done with current desc buf, get the next one */
|
|
|
|
if (desc_avail == 0) {
|
2016-09-20 02:00:12 +00:00
|
|
|
vec_idx++;
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr =
|
|
|
|
vhost_iova_to_vva(dev, vq,
|
|
|
|
buf_vec[vec_idx].buf_addr,
|
|
|
|
buf_vec[vec_idx].buf_len,
|
|
|
|
VHOST_ACCESS_RW);
|
2017-09-08 12:50:46 +00:00
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
2016-03-14 07:35:22 +00:00
|
|
|
|
|
|
|
/* Prefetch buffer address. */
|
|
|
|
rte_prefetch0((void *)(uintptr_t)desc_addr);
|
|
|
|
desc_offset = 0;
|
2016-05-02 18:30:41 +00:00
|
|
|
desc_avail = buf_vec[vec_idx].buf_len;
|
2014-08-15 04:58:01 +00:00
|
|
|
}
|
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
/* done with current mbuf, get the next one */
|
|
|
|
if (mbuf_avail == 0) {
|
|
|
|
m = m->next;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
mbuf_offset = 0;
|
|
|
|
mbuf_avail = rte_pktmbuf_data_len(m);
|
|
|
|
}
|
2015-06-09 01:03:03 +00:00
|
|
|
|
2016-10-14 09:34:33 +00:00
|
|
|
if (hdr_addr) {
|
2017-04-14 07:53:18 +00:00
|
|
|
struct virtio_net_hdr_mrg_rxbuf *hdr;
|
|
|
|
|
|
|
|
hdr = (struct virtio_net_hdr_mrg_rxbuf *)(uintptr_t)
|
|
|
|
hdr_addr;
|
|
|
|
virtio_enqueue_offload(hdr_mbuf, &hdr->hdr);
|
|
|
|
ASSIGN_UNLESS_EQUAL(hdr->num_buffers, num_buffers);
|
|
|
|
|
2016-10-14 09:34:33 +00:00
|
|
|
vhost_log_write(dev, hdr_phys_addr, dev->vhost_hlen);
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)hdr_addr,
|
|
|
|
dev->vhost_hlen, 0);
|
|
|
|
|
|
|
|
hdr_addr = 0;
|
|
|
|
}
|
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
cpy_len = RTE_MIN(desc_avail, mbuf_avail);
|
2017-09-08 12:50:46 +00:00
|
|
|
|
|
|
|
if (likely(cpy_len > MAX_BATCH_LEN || copy_nb >= vq->size)) {
|
|
|
|
rte_memcpy((void *)((uintptr_t)(desc_addr +
|
|
|
|
desc_offset)),
|
|
|
|
rte_pktmbuf_mtod_offset(m, void *, mbuf_offset),
|
|
|
|
cpy_len);
|
|
|
|
vhost_log_write(dev,
|
|
|
|
buf_vec[vec_idx].buf_addr + desc_offset,
|
|
|
|
cpy_len);
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)(desc_addr + desc_offset),
|
|
|
|
cpy_len, 0);
|
|
|
|
} else {
|
|
|
|
batch_copy[copy_nb].dst =
|
|
|
|
(void *)((uintptr_t)(desc_addr + desc_offset));
|
|
|
|
batch_copy[copy_nb].src =
|
|
|
|
rte_pktmbuf_mtod_offset(m, void *, mbuf_offset);
|
|
|
|
batch_copy[copy_nb].log_addr =
|
|
|
|
buf_vec[vec_idx].buf_addr + desc_offset;
|
|
|
|
batch_copy[copy_nb].len = cpy_len;
|
|
|
|
copy_nb++;
|
|
|
|
}
|
2015-06-09 01:03:03 +00:00
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
mbuf_avail -= cpy_len;
|
|
|
|
mbuf_offset += cpy_len;
|
|
|
|
desc_avail -= cpy_len;
|
|
|
|
desc_offset += cpy_len;
|
|
|
|
}
|
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
out:
|
|
|
|
vq->batch_copy_nb_elems = copy_nb;
|
|
|
|
|
|
|
|
return error;
|
2015-06-09 01:03:03 +00:00
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline uint32_t
|
2014-10-08 18:54:57 +00:00
|
|
|
virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
|
|
|
|
struct rte_mbuf **pkts, uint32_t count)
|
2014-08-15 04:58:01 +00:00
|
|
|
{
|
|
|
|
struct vhost_virtqueue *vq;
|
2016-10-14 09:34:34 +00:00
|
|
|
uint32_t pkt_idx = 0;
|
|
|
|
uint16_t num_buffers;
|
2016-05-02 18:30:41 +00:00
|
|
|
struct buf_vector buf_vec[BUF_VECTOR_MAX];
|
2016-10-14 09:34:38 +00:00
|
|
|
uint16_t avail_head;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-05-23 08:36:33 +00:00
|
|
|
LOG_DEBUG(VHOST_DATA, "(%d) %s\n", dev->vid, __func__);
|
2017-04-01 07:22:47 +00:00
|
|
|
if (unlikely(!is_valid_virt_queue_idx(queue_id, 0, dev->nr_vring))) {
|
2016-04-29 20:45:51 +00:00
|
|
|
RTE_LOG(ERR, VHOST_DATA, "(%d) %s: invalid virtqueue idx %d.\n",
|
2016-05-23 08:36:33 +00:00
|
|
|
dev->vid, __func__, queue_id);
|
2015-10-22 12:35:52 +00:00
|
|
|
return 0;
|
2014-10-08 18:54:43 +00:00
|
|
|
}
|
|
|
|
|
2015-10-22 12:35:52 +00:00
|
|
|
vq = dev->virtqueue[queue_id];
|
2015-10-22 12:35:54 +00:00
|
|
|
if (unlikely(vq->enabled == 0))
|
|
|
|
return 0;
|
|
|
|
|
2017-10-05 08:36:25 +00:00
|
|
|
if (dev->features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))
|
|
|
|
vhost_user_iotlb_rd_lock(vq);
|
|
|
|
|
|
|
|
if (unlikely(vq->access_ok == 0))
|
|
|
|
if (unlikely(vring_translate(dev, vq) < 0))
|
|
|
|
goto out;
|
|
|
|
|
2014-08-15 04:58:01 +00:00
|
|
|
count = RTE_MIN((uint32_t)MAX_PKT_BURST, count);
|
|
|
|
if (count == 0)
|
2017-10-05 08:36:25 +00:00
|
|
|
goto out;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
vq->batch_copy_nb_elems = 0;
|
|
|
|
|
2016-10-14 09:34:37 +00:00
|
|
|
rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]);
|
|
|
|
|
2016-10-14 09:34:36 +00:00
|
|
|
vq->shadow_used_idx = 0;
|
2016-10-14 09:34:38 +00:00
|
|
|
avail_head = *((volatile uint16_t *)&vq->avail->idx);
|
2014-08-15 04:58:01 +00:00
|
|
|
for (pkt_idx = 0; pkt_idx < count; pkt_idx++) {
|
2016-05-01 23:58:52 +00:00
|
|
|
uint32_t pkt_len = pkts[pkt_idx]->pkt_len + dev->vhost_hlen;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-10-18 15:35:38 +00:00
|
|
|
if (unlikely(reserve_avail_buf_mergeable(dev, vq,
|
|
|
|
pkt_len, buf_vec, &num_buffers,
|
|
|
|
avail_head) < 0)) {
|
2016-03-14 07:35:22 +00:00
|
|
|
LOG_DEBUG(VHOST_DATA,
|
2016-04-29 20:45:51 +00:00
|
|
|
"(%d) failed to get enough desc from vring\n",
|
2016-05-23 08:36:33 +00:00
|
|
|
dev->vid);
|
2016-10-14 09:34:36 +00:00
|
|
|
vq->shadow_used_idx -= num_buffers;
|
2016-03-14 07:35:22 +00:00
|
|
|
break;
|
|
|
|
}
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-10-14 09:34:36 +00:00
|
|
|
LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
|
|
|
|
dev->vid, vq->last_avail_idx,
|
|
|
|
vq->last_avail_idx + num_buffers);
|
2016-10-14 09:34:34 +00:00
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
if (copy_mbuf_to_desc_mergeable(dev, vq, pkts[pkt_idx],
|
2016-10-14 09:34:36 +00:00
|
|
|
buf_vec, num_buffers) < 0) {
|
|
|
|
vq->shadow_used_idx -= num_buffers;
|
|
|
|
break;
|
|
|
|
}
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-10-14 09:34:35 +00:00
|
|
|
vq->last_avail_idx += num_buffers;
|
2015-09-21 08:16:14 +00:00
|
|
|
}
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
do_data_copy_enqueue(dev, vq);
|
|
|
|
|
2016-10-14 09:34:36 +00:00
|
|
|
if (likely(vq->shadow_used_idx)) {
|
|
|
|
flush_shadow_used_ring(dev, vq);
|
|
|
|
|
2015-04-29 11:11:24 +00:00
|
|
|
/* flush used->idx update before we read avail->flags. */
|
|
|
|
rte_mb();
|
|
|
|
|
2014-08-15 04:58:01 +00:00
|
|
|
/* Kick the guest if necessary. */
|
2016-03-14 08:53:32 +00:00
|
|
|
if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
|
|
|
|
&& (vq->callfd >= 0))
|
2015-09-09 05:34:36 +00:00
|
|
|
eventfd_write(vq->callfd, (eventfd_t)1);
|
2014-08-15 04:58:01 +00:00
|
|
|
}
|
|
|
|
|
2017-10-05 08:36:25 +00:00
|
|
|
out:
|
|
|
|
if (dev->features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))
|
|
|
|
vhost_user_iotlb_rd_unlock(vq);
|
|
|
|
|
2015-09-21 08:16:14 +00:00
|
|
|
return pkt_idx;
|
2014-08-15 04:58:01 +00:00
|
|
|
}
|
|
|
|
|
2014-10-08 18:54:45 +00:00
|
|
|
uint16_t
|
2016-06-13 09:55:49 +00:00
|
|
|
rte_vhost_enqueue_burst(int vid, uint16_t queue_id,
|
2014-10-08 18:54:57 +00:00
|
|
|
struct rte_mbuf **pkts, uint16_t count)
|
2014-10-08 18:54:45 +00:00
|
|
|
{
|
2016-06-13 09:55:49 +00:00
|
|
|
struct virtio_net *dev = get_device(vid);
|
|
|
|
|
|
|
|
if (!dev)
|
|
|
|
return 0;
|
|
|
|
|
2016-03-10 04:32:43 +00:00
|
|
|
if (dev->features & (1 << VIRTIO_NET_F_MRG_RXBUF))
|
2014-10-08 18:54:45 +00:00
|
|
|
return virtio_dev_merge_rx(dev, queue_id, pkts, count);
|
|
|
|
else
|
|
|
|
return virtio_dev_rx(dev, queue_id, pkts, count);
|
|
|
|
}
|
|
|
|
|
2016-10-14 08:07:07 +00:00
|
|
|
static inline bool
|
|
|
|
virtio_net_with_host_offload(struct virtio_net *dev)
|
|
|
|
{
|
|
|
|
if (dev->features &
|
2017-06-28 12:40:31 +00:00
|
|
|
((1ULL << VIRTIO_NET_F_CSUM) |
|
|
|
|
(1ULL << VIRTIO_NET_F_HOST_ECN) |
|
|
|
|
(1ULL << VIRTIO_NET_F_HOST_TSO4) |
|
|
|
|
(1ULL << VIRTIO_NET_F_HOST_TSO6) |
|
|
|
|
(1ULL << VIRTIO_NET_F_HOST_UFO)))
|
2016-10-14 08:07:07 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-02-05 07:31:38 +00:00
|
|
|
static void
|
|
|
|
parse_ethernet(struct rte_mbuf *m, uint16_t *l4_proto, void **l4_hdr)
|
|
|
|
{
|
|
|
|
struct ipv4_hdr *ipv4_hdr;
|
|
|
|
struct ipv6_hdr *ipv6_hdr;
|
|
|
|
void *l3_hdr = NULL;
|
|
|
|
struct ether_hdr *eth_hdr;
|
|
|
|
uint16_t ethertype;
|
|
|
|
|
|
|
|
eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
|
|
|
|
|
|
|
|
m->l2_len = sizeof(struct ether_hdr);
|
|
|
|
ethertype = rte_be_to_cpu_16(eth_hdr->ether_type);
|
|
|
|
|
|
|
|
if (ethertype == ETHER_TYPE_VLAN) {
|
|
|
|
struct vlan_hdr *vlan_hdr = (struct vlan_hdr *)(eth_hdr + 1);
|
|
|
|
|
|
|
|
m->l2_len += sizeof(struct vlan_hdr);
|
|
|
|
ethertype = rte_be_to_cpu_16(vlan_hdr->eth_proto);
|
|
|
|
}
|
|
|
|
|
|
|
|
l3_hdr = (char *)eth_hdr + m->l2_len;
|
|
|
|
|
|
|
|
switch (ethertype) {
|
|
|
|
case ETHER_TYPE_IPv4:
|
2017-04-07 17:44:47 +00:00
|
|
|
ipv4_hdr = l3_hdr;
|
2016-02-05 07:31:38 +00:00
|
|
|
*l4_proto = ipv4_hdr->next_proto_id;
|
|
|
|
m->l3_len = (ipv4_hdr->version_ihl & 0x0f) * 4;
|
|
|
|
*l4_hdr = (char *)l3_hdr + m->l3_len;
|
|
|
|
m->ol_flags |= PKT_TX_IPV4;
|
|
|
|
break;
|
|
|
|
case ETHER_TYPE_IPv6:
|
2017-04-07 17:44:47 +00:00
|
|
|
ipv6_hdr = l3_hdr;
|
2016-02-05 07:31:38 +00:00
|
|
|
*l4_proto = ipv6_hdr->proto;
|
|
|
|
m->l3_len = sizeof(struct ipv6_hdr);
|
|
|
|
*l4_hdr = (char *)l3_hdr + m->l3_len;
|
|
|
|
m->ol_flags |= PKT_TX_IPV6;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
m->l3_len = 0;
|
|
|
|
*l4_proto = 0;
|
2017-01-24 20:36:03 +00:00
|
|
|
*l4_hdr = NULL;
|
2016-02-05 07:31:38 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline void
|
2016-02-05 07:31:38 +00:00
|
|
|
vhost_dequeue_offload(struct virtio_net_hdr *hdr, struct rte_mbuf *m)
|
|
|
|
{
|
|
|
|
uint16_t l4_proto = 0;
|
|
|
|
void *l4_hdr = NULL;
|
|
|
|
struct tcp_hdr *tcp_hdr = NULL;
|
|
|
|
|
2016-10-14 08:07:07 +00:00
|
|
|
if (hdr->flags == 0 && hdr->gso_type == VIRTIO_NET_HDR_GSO_NONE)
|
|
|
|
return;
|
|
|
|
|
2016-02-05 07:31:38 +00:00
|
|
|
parse_ethernet(m, &l4_proto, &l4_hdr);
|
|
|
|
if (hdr->flags == VIRTIO_NET_HDR_F_NEEDS_CSUM) {
|
|
|
|
if (hdr->csum_start == (m->l2_len + m->l3_len)) {
|
|
|
|
switch (hdr->csum_offset) {
|
|
|
|
case (offsetof(struct tcp_hdr, cksum)):
|
|
|
|
if (l4_proto == IPPROTO_TCP)
|
|
|
|
m->ol_flags |= PKT_TX_TCP_CKSUM;
|
|
|
|
break;
|
|
|
|
case (offsetof(struct udp_hdr, dgram_cksum)):
|
|
|
|
if (l4_proto == IPPROTO_UDP)
|
|
|
|
m->ol_flags |= PKT_TX_UDP_CKSUM;
|
|
|
|
break;
|
|
|
|
case (offsetof(struct sctp_hdr, cksum)):
|
|
|
|
if (l4_proto == IPPROTO_SCTP)
|
|
|
|
m->ol_flags |= PKT_TX_SCTP_CKSUM;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-24 20:36:03 +00:00
|
|
|
if (l4_hdr && hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
|
2016-02-05 07:31:38 +00:00
|
|
|
switch (hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
|
|
|
|
case VIRTIO_NET_HDR_GSO_TCPV4:
|
|
|
|
case VIRTIO_NET_HDR_GSO_TCPV6:
|
2017-04-07 17:44:47 +00:00
|
|
|
tcp_hdr = l4_hdr;
|
2016-02-05 07:31:38 +00:00
|
|
|
m->ol_flags |= PKT_TX_TCP_SEG;
|
|
|
|
m->tso_segsz = hdr->gso_size;
|
|
|
|
m->l4_len = (tcp_hdr->data_off & 0xf0) >> 2;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
RTE_LOG(WARNING, VHOST_DATA,
|
|
|
|
"unsupported gso type %u.\n", hdr->gso_type);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
#define RARP_PKT_SIZE 64
|
|
|
|
|
|
|
|
static int
|
|
|
|
make_rarp_packet(struct rte_mbuf *rarp_mbuf, const struct ether_addr *mac)
|
|
|
|
{
|
|
|
|
struct ether_hdr *eth_hdr;
|
|
|
|
struct arp_hdr *rarp;
|
|
|
|
|
|
|
|
if (rarp_mbuf->buf_len < 64) {
|
|
|
|
RTE_LOG(WARNING, VHOST_DATA,
|
|
|
|
"failed to make RARP; mbuf size too small %u (< %d)\n",
|
|
|
|
rarp_mbuf->buf_len, RARP_PKT_SIZE);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Ethernet header. */
|
|
|
|
eth_hdr = rte_pktmbuf_mtod_offset(rarp_mbuf, struct ether_hdr *, 0);
|
|
|
|
memset(eth_hdr->d_addr.addr_bytes, 0xff, ETHER_ADDR_LEN);
|
|
|
|
ether_addr_copy(mac, ð_hdr->s_addr);
|
|
|
|
eth_hdr->ether_type = htons(ETHER_TYPE_RARP);
|
|
|
|
|
|
|
|
/* RARP header. */
|
|
|
|
rarp = (struct arp_hdr *)(eth_hdr + 1);
|
|
|
|
rarp->arp_hrd = htons(ARP_HRD_ETHER);
|
|
|
|
rarp->arp_pro = htons(ETHER_TYPE_IPv4);
|
|
|
|
rarp->arp_hln = ETHER_ADDR_LEN;
|
|
|
|
rarp->arp_pln = 4;
|
|
|
|
rarp->arp_op = htons(ARP_OP_REVREQUEST);
|
|
|
|
|
|
|
|
ether_addr_copy(mac, &rarp->arp_data.arp_sha);
|
|
|
|
ether_addr_copy(mac, &rarp->arp_data.arp_tha);
|
|
|
|
memset(&rarp->arp_data.arp_sip, 0x00, 4);
|
|
|
|
memset(&rarp->arp_data.arp_tip, 0x00, 4);
|
|
|
|
|
|
|
|
rarp_mbuf->pkt_len = rarp_mbuf->data_len = RARP_PKT_SIZE;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline void
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
put_zmbuf(struct zcopy_mbuf *zmbuf)
|
|
|
|
{
|
|
|
|
zmbuf->in_use = 0;
|
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline int
|
2017-09-08 12:50:46 +00:00
|
|
|
copy_desc_to_mbuf(struct virtio_net *dev, struct vhost_virtqueue *vq,
|
|
|
|
struct vring_desc *descs, uint16_t max_desc,
|
|
|
|
struct rte_mbuf *m, uint16_t desc_idx,
|
2016-03-10 04:32:39 +00:00
|
|
|
struct rte_mempool *mbuf_pool)
|
|
|
|
{
|
|
|
|
struct vring_desc *desc;
|
|
|
|
uint64_t desc_addr;
|
|
|
|
uint32_t desc_avail, desc_offset;
|
|
|
|
uint32_t mbuf_avail, mbuf_offset;
|
|
|
|
uint32_t cpy_len;
|
|
|
|
struct rte_mbuf *cur = m, *prev = m;
|
2016-10-14 08:07:07 +00:00
|
|
|
struct virtio_net_hdr *hdr = NULL;
|
2016-03-10 04:32:46 +00:00
|
|
|
/* A counter to avoid desc dead loop chain */
|
|
|
|
uint32_t nr_desc = 1;
|
2017-09-08 12:50:46 +00:00
|
|
|
struct batch_copy_elem *batch_copy = vq->batch_copy_elems;
|
|
|
|
uint16_t copy_nb = vq->batch_copy_nb_elems;
|
|
|
|
int error = 0;
|
2016-03-10 04:32:39 +00:00
|
|
|
|
2016-09-27 08:42:49 +00:00
|
|
|
desc = &descs[desc_idx];
|
|
|
|
if (unlikely((desc->len < dev->vhost_hlen)) ||
|
2017-09-08 12:50:46 +00:00
|
|
|
(desc->flags & VRING_DESC_F_INDIRECT)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
vhost: do sanity check for ring descriptor length
We need make sure that desc->len is bigger than the size of virtio net
header, otherwise, unexpected behaviour might happen due to "desc_avail"
would become a huge number with for following code:
desc_avail = desc->len - vq->vhost_hlen;
For dequeue code path, it will try to allocate enough mbuf to hold such
size of desc buf, which ends up with consuming all mbufs, leading to no
free mbuf is available. Therefore, you might see an error message:
Failed to allocate memory for mbuf.
Also, for both dequeue/enqueue code path, while it copies data from/to
desc buf, the big "desc_avail" would result to access memory not belong
the desc buf, which could lead to some potential memory access errors.
A malicious guest could easily forge such malformed vring desc buf. Every
time we restart an interrupted DPDK application inside guest would also
trigger this issue, as all huge pages are reset to 0 during DPDK re-init,
leading to desc->len being 0.
Therefore, this patch does a sanity check for desc->len, to make vhost
robust.
Reported-by: Rich Lane <rich.lane@bigswitch.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-03-10 04:32:44 +00:00
|
|
|
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr = vhost_iova_to_vva(dev,
|
|
|
|
vq, desc->addr,
|
|
|
|
desc->len,
|
|
|
|
VHOST_ACCESS_RO);
|
2017-09-08 12:50:46 +00:00
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
2016-07-15 11:15:05 +00:00
|
|
|
|
2016-10-14 08:07:07 +00:00
|
|
|
if (virtio_net_with_host_offload(dev)) {
|
|
|
|
hdr = (struct virtio_net_hdr *)((uintptr_t)desc_addr);
|
|
|
|
rte_prefetch0(hdr);
|
|
|
|
}
|
2016-05-03 00:46:17 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* A virtio driver normally uses at least 2 desc buffers
|
|
|
|
* for Tx: the first for storing the header, and others
|
|
|
|
* for storing the data.
|
|
|
|
*/
|
|
|
|
if (likely((desc->len == dev->vhost_hlen) &&
|
|
|
|
(desc->flags & VRING_DESC_F_NEXT) != 0)) {
|
2016-09-27 08:42:49 +00:00
|
|
|
desc = &descs[desc->next];
|
2017-09-08 12:50:46 +00:00
|
|
|
if (unlikely(desc->flags & VRING_DESC_F_INDIRECT)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
2016-05-03 00:46:17 +00:00
|
|
|
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr = vhost_iova_to_vva(dev,
|
|
|
|
vq, desc->addr,
|
|
|
|
desc->len,
|
|
|
|
VHOST_ACCESS_RO);
|
2017-09-08 12:50:46 +00:00
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
2016-07-15 11:15:05 +00:00
|
|
|
|
2016-05-03 00:46:17 +00:00
|
|
|
desc_offset = 0;
|
|
|
|
desc_avail = desc->len;
|
|
|
|
nr_desc += 1;
|
|
|
|
} else {
|
|
|
|
desc_avail = desc->len - dev->vhost_hlen;
|
|
|
|
desc_offset = dev->vhost_hlen;
|
|
|
|
}
|
2016-03-10 04:32:39 +00:00
|
|
|
|
2016-10-14 08:07:07 +00:00
|
|
|
rte_prefetch0((void *)(uintptr_t)(desc_addr + desc_offset));
|
|
|
|
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)(desc_addr + desc_offset), desc_avail, 0);
|
|
|
|
|
2016-03-10 04:32:39 +00:00
|
|
|
mbuf_offset = 0;
|
|
|
|
mbuf_avail = m->buf_len - RTE_PKTMBUF_HEADROOM;
|
2016-05-03 00:46:17 +00:00
|
|
|
while (1) {
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
uint64_t hpa;
|
|
|
|
|
2016-05-03 00:46:17 +00:00
|
|
|
cpy_len = RTE_MIN(desc_avail, mbuf_avail);
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* A desc buf might across two host physical pages that are
|
|
|
|
* not continuous. In such case (gpa_to_hpa returns 0), data
|
|
|
|
* will be copied even though zero copy is enabled.
|
|
|
|
*/
|
|
|
|
if (unlikely(dev->dequeue_zero_copy && (hpa = gpa_to_hpa(dev,
|
|
|
|
desc->addr + desc_offset, cpy_len)))) {
|
|
|
|
cur->data_len = cpy_len;
|
|
|
|
cur->data_off = 0;
|
|
|
|
cur->buf_addr = (void *)(uintptr_t)desc_addr;
|
|
|
|
cur->buf_physaddr = hpa;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In zero copy mode, one mbuf can only reference data
|
|
|
|
* for one or partial of one desc buff.
|
|
|
|
*/
|
|
|
|
mbuf_avail = cpy_len;
|
|
|
|
} else {
|
2017-09-08 12:50:46 +00:00
|
|
|
if (likely(cpy_len > MAX_BATCH_LEN ||
|
|
|
|
copy_nb >= vq->size)) {
|
|
|
|
rte_memcpy(rte_pktmbuf_mtod_offset(cur, void *,
|
|
|
|
mbuf_offset),
|
|
|
|
(void *)((uintptr_t)(desc_addr +
|
|
|
|
desc_offset)),
|
|
|
|
cpy_len);
|
|
|
|
} else {
|
|
|
|
batch_copy[copy_nb].dst =
|
|
|
|
rte_pktmbuf_mtod_offset(cur, void *,
|
|
|
|
mbuf_offset);
|
|
|
|
batch_copy[copy_nb].src =
|
|
|
|
(void *)((uintptr_t)(desc_addr +
|
|
|
|
desc_offset));
|
|
|
|
batch_copy[copy_nb].len = cpy_len;
|
|
|
|
copy_nb++;
|
|
|
|
}
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
}
|
2016-05-03 00:46:17 +00:00
|
|
|
|
|
|
|
mbuf_avail -= cpy_len;
|
|
|
|
mbuf_offset += cpy_len;
|
|
|
|
desc_avail -= cpy_len;
|
|
|
|
desc_offset += cpy_len;
|
|
|
|
|
2016-03-10 04:32:39 +00:00
|
|
|
/* This desc reaches to its end, get the next one */
|
|
|
|
if (desc_avail == 0) {
|
2016-05-03 00:46:17 +00:00
|
|
|
if ((desc->flags & VRING_DESC_F_NEXT) == 0)
|
|
|
|
break;
|
|
|
|
|
2016-09-27 08:42:49 +00:00
|
|
|
if (unlikely(desc->next >= max_desc ||
|
2017-09-08 12:50:46 +00:00
|
|
|
++nr_desc > max_desc)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
2016-09-27 08:42:49 +00:00
|
|
|
desc = &descs[desc->next];
|
2017-09-08 12:50:46 +00:00
|
|
|
if (unlikely(desc->flags & VRING_DESC_F_INDIRECT)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
2016-03-10 04:32:39 +00:00
|
|
|
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr = vhost_iova_to_vva(dev,
|
|
|
|
vq, desc->addr,
|
|
|
|
desc->len,
|
|
|
|
VHOST_ACCESS_RO);
|
2017-09-08 12:50:46 +00:00
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
2016-07-15 11:15:05 +00:00
|
|
|
|
2016-03-10 04:32:39 +00:00
|
|
|
rte_prefetch0((void *)(uintptr_t)desc_addr);
|
|
|
|
|
|
|
|
desc_offset = 0;
|
|
|
|
desc_avail = desc->len;
|
|
|
|
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)desc_addr, desc->len, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This mbuf reaches to its end, get a new one
|
|
|
|
* to hold more data.
|
|
|
|
*/
|
|
|
|
if (mbuf_avail == 0) {
|
|
|
|
cur = rte_pktmbuf_alloc(mbuf_pool);
|
|
|
|
if (unlikely(cur == NULL)) {
|
|
|
|
RTE_LOG(ERR, VHOST_DATA, "Failed to "
|
|
|
|
"allocate memory for mbuf.\n");
|
2017-09-08 12:50:46 +00:00
|
|
|
error = -1;
|
|
|
|
goto out;
|
2016-03-10 04:32:39 +00:00
|
|
|
}
|
vhost: fix dequeue zero copy
For zero copy mode, we need pin the mbuf to not let the underlaying PMD
driver (or the app) free the mbuf. Currently, only the heading mbuf is
pinned. However, the mbuf free function would try to free all mbufs
in the mbuf chain (-1 to the refcnt). This may lead the head mbuf being
still pinned, while the other subsequent mbufs are actually freed. Which
is wrong.
It becomes more fatal after the mbuf refactor, more specificly, after
the commit 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool"). The
refcnt resets to 1 after the last real reference. OTOH, it leads to a
situtation that we never know one mbuf is actually freed or not. This
would result the mbuf __just__ after the heading mbuf being freed twice:
it's firstly freed (and put back to mempool) when the underlaying PMD
finishes the DMA. Later, it will then be freed again when vhost unpins
it. Meaning, one mbuf may be returned to the mempool twice, while in
turn, being allocated twice later. Something uncertain may happen then.
For example, the VM2VM case becomes broken.
Fixes: b0a985d1f340 ("vhost: add dequeue zero copy")
Cc: stable@dpdk.org
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2017-04-19 05:26:01 +00:00
|
|
|
if (unlikely(dev->dequeue_zero_copy))
|
|
|
|
rte_mbuf_refcnt_update(cur, 1);
|
2016-03-10 04:32:39 +00:00
|
|
|
|
|
|
|
prev->next = cur;
|
|
|
|
prev->data_len = mbuf_offset;
|
|
|
|
m->nb_segs += 1;
|
|
|
|
m->pkt_len += mbuf_offset;
|
|
|
|
prev = cur;
|
|
|
|
|
|
|
|
mbuf_offset = 0;
|
|
|
|
mbuf_avail = cur->buf_len - RTE_PKTMBUF_HEADROOM;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
prev->data_len = mbuf_offset;
|
|
|
|
m->pkt_len += mbuf_offset;
|
|
|
|
|
2016-10-14 08:07:07 +00:00
|
|
|
if (hdr)
|
2016-03-10 04:32:39 +00:00
|
|
|
vhost_dequeue_offload(hdr, m);
|
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
out:
|
|
|
|
vq->batch_copy_nb_elems = copy_nb;
|
|
|
|
|
|
|
|
return error;
|
2016-03-10 04:32:39 +00:00
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline void
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
update_used_ring(struct virtio_net *dev, struct vhost_virtqueue *vq,
|
|
|
|
uint32_t used_idx, uint32_t desc_idx)
|
|
|
|
{
|
|
|
|
vq->used->ring[used_idx].id = desc_idx;
|
|
|
|
vq->used->ring[used_idx].len = 0;
|
|
|
|
vhost_log_used_vring(dev, vq,
|
|
|
|
offsetof(struct vring_used, ring[used_idx]),
|
|
|
|
sizeof(vq->used->ring[used_idx]));
|
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline void
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
update_used_idx(struct virtio_net *dev, struct vhost_virtqueue *vq,
|
|
|
|
uint32_t count)
|
|
|
|
{
|
|
|
|
if (unlikely(count == 0))
|
|
|
|
return;
|
|
|
|
|
|
|
|
rte_smp_wmb();
|
|
|
|
rte_smp_rmb();
|
|
|
|
|
|
|
|
vq->used->idx += count;
|
|
|
|
vhost_log_used_vring(dev, vq, offsetof(struct vring_used, idx),
|
|
|
|
sizeof(vq->used->idx));
|
|
|
|
|
|
|
|
/* Kick guest if required. */
|
|
|
|
if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
|
|
|
|
&& (vq->callfd >= 0))
|
|
|
|
eventfd_write(vq->callfd, (eventfd_t)1);
|
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline struct zcopy_mbuf *
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
get_zmbuf(struct vhost_virtqueue *vq)
|
|
|
|
{
|
|
|
|
uint16_t i;
|
|
|
|
uint16_t last;
|
|
|
|
int tries = 0;
|
|
|
|
|
|
|
|
/* search [last_zmbuf_idx, zmbuf_size) */
|
|
|
|
i = vq->last_zmbuf_idx;
|
|
|
|
last = vq->zmbuf_size;
|
|
|
|
|
|
|
|
again:
|
|
|
|
for (; i < last; i++) {
|
|
|
|
if (vq->zmbufs[i].in_use == 0) {
|
|
|
|
vq->last_zmbuf_idx = i + 1;
|
|
|
|
vq->zmbufs[i].in_use = 1;
|
|
|
|
return &vq->zmbufs[i];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
tries++;
|
|
|
|
if (tries == 1) {
|
|
|
|
/* search [0, last_zmbuf_idx) */
|
|
|
|
i = 0;
|
|
|
|
last = vq->last_zmbuf_idx;
|
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-05-13 09:27:25 +00:00
|
|
|
static __rte_always_inline bool
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
mbuf_is_consumed(struct rte_mbuf *m)
|
|
|
|
{
|
|
|
|
while (m) {
|
|
|
|
if (rte_mbuf_refcnt_read(m) > 1)
|
|
|
|
return false;
|
|
|
|
m = m->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-10-08 18:54:45 +00:00
|
|
|
uint16_t
|
2016-06-13 09:55:49 +00:00
|
|
|
rte_vhost_dequeue_burst(int vid, uint16_t queue_id,
|
2014-10-08 18:54:57 +00:00
|
|
|
struct rte_mempool *mbuf_pool, struct rte_mbuf **pkts, uint16_t count)
|
2014-02-10 13:57:48 +00:00
|
|
|
{
|
2016-06-13 09:55:49 +00:00
|
|
|
struct virtio_net *dev;
|
2016-03-10 04:32:39 +00:00
|
|
|
struct rte_mbuf *rarp_mbuf = NULL;
|
2014-10-08 18:54:37 +00:00
|
|
|
struct vhost_virtqueue *vq;
|
2016-03-10 04:32:39 +00:00
|
|
|
uint32_t desc_indexes[MAX_PKT_BURST];
|
2014-10-08 18:54:37 +00:00
|
|
|
uint32_t used_idx;
|
2016-03-10 04:32:39 +00:00
|
|
|
uint32_t i = 0;
|
|
|
|
uint16_t free_entries;
|
2014-10-08 18:54:37 +00:00
|
|
|
uint16_t avail_idx;
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2016-06-13 09:55:49 +00:00
|
|
|
dev = get_device(vid);
|
|
|
|
if (!dev)
|
|
|
|
return 0;
|
|
|
|
|
2017-04-01 07:22:47 +00:00
|
|
|
if (unlikely(!is_valid_virt_queue_idx(queue_id, 1, dev->nr_vring))) {
|
2016-04-29 20:45:51 +00:00
|
|
|
RTE_LOG(ERR, VHOST_DATA, "(%d) %s: invalid virtqueue idx %d.\n",
|
2016-05-23 08:36:33 +00:00
|
|
|
dev->vid, __func__, queue_id);
|
2014-10-08 18:54:43 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-10-22 12:35:52 +00:00
|
|
|
vq = dev->virtqueue[queue_id];
|
2015-10-22 12:35:54 +00:00
|
|
|
if (unlikely(vq->enabled == 0))
|
|
|
|
return 0;
|
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
vq->batch_copy_nb_elems = 0;
|
|
|
|
|
2017-10-05 08:36:25 +00:00
|
|
|
if (dev->features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))
|
|
|
|
vhost_user_iotlb_rd_lock(vq);
|
|
|
|
|
|
|
|
if (unlikely(vq->access_ok == 0))
|
|
|
|
if (unlikely(vring_translate(dev, vq) < 0))
|
|
|
|
goto out;
|
|
|
|
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
if (unlikely(dev->dequeue_zero_copy)) {
|
|
|
|
struct zcopy_mbuf *zmbuf, *next;
|
|
|
|
int nr_updated = 0;
|
|
|
|
|
|
|
|
for (zmbuf = TAILQ_FIRST(&vq->zmbuf_list);
|
|
|
|
zmbuf != NULL; zmbuf = next) {
|
|
|
|
next = TAILQ_NEXT(zmbuf, next);
|
|
|
|
|
|
|
|
if (mbuf_is_consumed(zmbuf->mbuf)) {
|
|
|
|
used_idx = vq->last_used_idx++ & (vq->size - 1);
|
|
|
|
update_used_ring(dev, vq, used_idx,
|
|
|
|
zmbuf->desc_idx);
|
|
|
|
nr_updated += 1;
|
|
|
|
|
|
|
|
TAILQ_REMOVE(&vq->zmbuf_list, zmbuf, next);
|
|
|
|
rte_pktmbuf_free(zmbuf->mbuf);
|
|
|
|
put_zmbuf(zmbuf);
|
|
|
|
vq->nr_zmbuf -= 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
update_used_idx(dev, vq, nr_updated);
|
|
|
|
}
|
|
|
|
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
/*
|
|
|
|
* Construct a RARP broadcast packet, and inject it to the "pkts"
|
|
|
|
* array, to looks like that guest actually send such packet.
|
|
|
|
*
|
|
|
|
* Check user_send_rarp() for more information.
|
2017-03-23 15:44:58 +00:00
|
|
|
*
|
|
|
|
* broadcast_rarp shares a cacheline in the virtio_net structure
|
|
|
|
* with some fields that are accessed during enqueue and
|
|
|
|
* rte_atomic16_cmpset() causes a write if using cmpxchg. This could
|
|
|
|
* result in false sharing between enqueue and dequeue.
|
|
|
|
*
|
|
|
|
* Prevent unnecessary false sharing by reading broadcast_rarp first
|
|
|
|
* and only performing cmpset if the read indicates it is likely to
|
|
|
|
* be set.
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
*/
|
2017-03-23 15:44:58 +00:00
|
|
|
|
|
|
|
if (unlikely(rte_atomic16_read(&dev->broadcast_rarp) &&
|
|
|
|
rte_atomic16_cmpset((volatile uint16_t *)
|
|
|
|
&dev->broadcast_rarp.cnt, 1, 0))) {
|
|
|
|
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
rarp_mbuf = rte_pktmbuf_alloc(mbuf_pool);
|
|
|
|
if (rarp_mbuf == NULL) {
|
|
|
|
RTE_LOG(ERR, VHOST_DATA,
|
|
|
|
"Failed to allocate memory for mbuf.\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (make_rarp_packet(rarp_mbuf, &dev->mac)) {
|
|
|
|
rte_pktmbuf_free(rarp_mbuf);
|
|
|
|
rarp_mbuf = NULL;
|
|
|
|
} else {
|
|
|
|
count -= 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-10-09 07:27:56 +00:00
|
|
|
free_entries = *((volatile uint16_t *)&vq->avail->idx) -
|
|
|
|
vq->last_avail_idx;
|
2016-03-10 04:32:39 +00:00
|
|
|
if (free_entries == 0)
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
goto out;
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2016-05-23 08:36:33 +00:00
|
|
|
LOG_DEBUG(VHOST_DATA, "(%d) %s\n", dev->vid, __func__);
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2016-10-09 07:27:56 +00:00
|
|
|
/* Prefetch available and used ring */
|
|
|
|
avail_idx = vq->last_avail_idx & (vq->size - 1);
|
|
|
|
used_idx = vq->last_used_idx & (vq->size - 1);
|
|
|
|
rte_prefetch0(&vq->avail->ring[avail_idx]);
|
2016-05-03 00:46:16 +00:00
|
|
|
rte_prefetch0(&vq->used->ring[used_idx]);
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2016-03-10 04:32:39 +00:00
|
|
|
count = RTE_MIN(count, MAX_PKT_BURST);
|
|
|
|
count = RTE_MIN(count, free_entries);
|
2016-04-29 20:45:51 +00:00
|
|
|
LOG_DEBUG(VHOST_DATA, "(%d) about to dequeue %u buffers\n",
|
2016-05-23 08:36:33 +00:00
|
|
|
dev->vid, count);
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2014-10-08 18:54:37 +00:00
|
|
|
/* Retrieve all of the head indexes first to avoid caching issues. */
|
2016-03-10 04:32:39 +00:00
|
|
|
for (i = 0; i < count; i++) {
|
2016-10-09 07:27:56 +00:00
|
|
|
avail_idx = (vq->last_avail_idx + i) & (vq->size - 1);
|
|
|
|
used_idx = (vq->last_used_idx + i) & (vq->size - 1);
|
|
|
|
desc_indexes[i] = vq->avail->ring[avail_idx];
|
2016-05-03 00:46:16 +00:00
|
|
|
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
if (likely(dev->dequeue_zero_copy == 0))
|
|
|
|
update_used_ring(dev, vq, used_idx, desc_indexes[i]);
|
2016-03-10 04:32:39 +00:00
|
|
|
}
|
2014-02-10 13:57:48 +00:00
|
|
|
|
2014-10-08 18:54:37 +00:00
|
|
|
/* Prefetch descriptor index. */
|
2016-03-10 04:32:39 +00:00
|
|
|
rte_prefetch0(&vq->desc[desc_indexes[0]]);
|
|
|
|
for (i = 0; i < count; i++) {
|
2016-09-27 08:42:49 +00:00
|
|
|
struct vring_desc *desc;
|
|
|
|
uint16_t sz, idx;
|
2016-03-10 04:32:39 +00:00
|
|
|
int err;
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-05-03 00:46:16 +00:00
|
|
|
if (likely(i + 1 < count))
|
2016-03-10 04:32:39 +00:00
|
|
|
rte_prefetch0(&vq->desc[desc_indexes[i + 1]]);
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2016-09-27 08:42:49 +00:00
|
|
|
if (vq->desc[desc_indexes[i]].flags & VRING_DESC_F_INDIRECT) {
|
2017-04-01 07:22:46 +00:00
|
|
|
desc = (struct vring_desc *)(uintptr_t)
|
2017-10-05 08:36:20 +00:00
|
|
|
vhost_iova_to_vva(dev, vq,
|
|
|
|
vq->desc[desc_indexes[i]].addr,
|
|
|
|
sizeof(*desc),
|
|
|
|
VHOST_ACCESS_RO);
|
2016-09-27 08:42:49 +00:00
|
|
|
if (unlikely(!desc))
|
|
|
|
break;
|
|
|
|
|
|
|
|
rte_prefetch0(desc);
|
|
|
|
sz = vq->desc[desc_indexes[i]].len / sizeof(*desc);
|
|
|
|
idx = 0;
|
|
|
|
} else {
|
|
|
|
desc = vq->desc;
|
|
|
|
sz = vq->size;
|
|
|
|
idx = desc_indexes[i];
|
|
|
|
}
|
|
|
|
|
2016-03-10 04:32:39 +00:00
|
|
|
pkts[i] = rte_pktmbuf_alloc(mbuf_pool);
|
|
|
|
if (unlikely(pkts[i] == NULL)) {
|
2014-08-15 04:58:01 +00:00
|
|
|
RTE_LOG(ERR, VHOST_DATA,
|
|
|
|
"Failed to allocate memory for mbuf.\n");
|
2015-06-04 14:43:23 +00:00
|
|
|
break;
|
2014-08-15 04:58:01 +00:00
|
|
|
}
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
|
2017-09-08 12:50:46 +00:00
|
|
|
err = copy_desc_to_mbuf(dev, vq, desc, sz, pkts[i], idx,
|
|
|
|
mbuf_pool);
|
2016-03-10 04:32:39 +00:00
|
|
|
if (unlikely(err)) {
|
|
|
|
rte_pktmbuf_free(pkts[i]);
|
2014-08-15 04:58:01 +00:00
|
|
|
break;
|
2016-03-10 04:32:39 +00:00
|
|
|
}
|
2014-08-15 04:58:01 +00:00
|
|
|
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
if (unlikely(dev->dequeue_zero_copy)) {
|
|
|
|
struct zcopy_mbuf *zmbuf;
|
|
|
|
|
|
|
|
zmbuf = get_zmbuf(vq);
|
|
|
|
if (!zmbuf) {
|
|
|
|
rte_pktmbuf_free(pkts[i]);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
zmbuf->mbuf = pkts[i];
|
|
|
|
zmbuf->desc_idx = desc_indexes[i];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Pin lock the mbuf; we will check later to see
|
|
|
|
* whether the mbuf is freed (when we are the last
|
|
|
|
* user) or not. If that's the case, we then could
|
|
|
|
* update the used ring safely.
|
|
|
|
*/
|
|
|
|
rte_mbuf_refcnt_update(pkts[i], 1);
|
|
|
|
|
|
|
|
vq->nr_zmbuf += 1;
|
|
|
|
TAILQ_INSERT_TAIL(&vq->zmbuf_list, zmbuf, next);
|
|
|
|
}
|
|
|
|
}
|
2016-10-09 07:27:56 +00:00
|
|
|
vq->last_avail_idx += i;
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
if (likely(dev->dequeue_zero_copy == 0)) {
|
2017-09-08 12:50:46 +00:00
|
|
|
do_data_copy_dequeue(vq);
|
vhost: add dequeue zero copy
The basic idea of dequeue zero copy is, instead of copying data from
the desc buf, here we let the mbuf reference the desc buf addr directly.
Doing so, however, has one major issue: we can't update the used ring
at the end of rte_vhost_dequeue_burst. Because we don't do the copy
here, an update of the used ring would let the driver to reclaim the
desc buf. As a result, DPDK might reference a stale memory region.
To update the used ring properly, this patch does several tricks:
- when mbuf references a desc buf, refcnt is added by 1.
This is to pin lock the mbuf, so that a mbuf free from the DPDK
won't actually free it, instead, refcnt is subtracted by 1.
- We chain all those mbuf together (by tailq)
And we check it every time on the rte_vhost_dequeue_burst entrance,
to see if the mbuf is freed (when refcnt equals to 1). If that
happens, it means we are the last user of this mbuf and we are
safe to update the used ring.
- "struct zcopy_mbuf" is introduced, to associate an mbuf with the
right desc idx.
Dequeue zero copy is introduced for performance reason, and some rough
tests show about 50% perfomance boost for packet size 1500B. For small
packets, (e.g. 64B), it actually slows a bit down (well, it could up to
15%). That is expected because this patch introduces some extra works,
and it outweighs the benefit from saving few bytes copy.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Qian Xu <qian.q.xu@intel.com>
2016-10-09 07:27:57 +00:00
|
|
|
vq->last_used_idx += i;
|
|
|
|
update_used_idx(dev, vq, i);
|
|
|
|
}
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
|
|
|
|
out:
|
2017-10-05 08:36:25 +00:00
|
|
|
if (dev->features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))
|
|
|
|
vhost_user_iotlb_rd_unlock(vq);
|
|
|
|
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
if (unlikely(rarp_mbuf != NULL)) {
|
|
|
|
/*
|
|
|
|
* Inject it to the head of "pkts" array, so that switch's mac
|
|
|
|
* learning table will get updated first.
|
|
|
|
*/
|
2016-03-10 04:32:39 +00:00
|
|
|
memmove(&pkts[1], pkts, i * sizeof(struct rte_mbuf *));
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
pkts[0] = rarp_mbuf;
|
2016-03-10 04:32:39 +00:00
|
|
|
i += 1;
|
vhost: broadcast RARP by injecting in receiving mbuf array
Broadcast RARP packet by injecting it to receiving mbuf array at
rte_vhost_dequeue_burst().
Commit 33226236a35e ("vhost: handle request to send RARP") iterates
all host interfaces and then broadcast it by all of them. It did
notify the switches about the new location of the migrated VM, however,
the mac learning table in the target host is wrong (at least in my
test with OVS):
$ ovs-appctl fdb/show ovsbr0
port VLAN MAC Age
1 0 b6:3c:72:71:cd:4d 10
LOCAL 0 b6:3c:72:71:cd:4e 10
LOCAL 0 52:54:00:12:34:68 9
1 0 56:f6:64:2c:bc:c0 1
Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
above, the port learned is "LOCAL", which is the "ovsbr0" port. That
is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
The wrong mac table lead all the packets to the VM go to the "ovsbr0"
in the end, which ends up with all packets being lost, until the guest
send a ARP quest (or reply) to refresh the mac learning table.
Jianfeng then came up with a solution I have thought of firstly but NAKed
by myself, concerning it has potential issues [0]. The solution is as title
stated: broadcast the RARP packet by injecting it to the receiving mbuf
arrays at rte_vhost_dequeue_burst(). The re-bring of that idea made me
think it twice; it looked like a false concern to me then. And I had done
a rough verification: it worked as expected.
[0]: http://dpdk.org/ml/archives/dev/2016-February/033527.html
Another note is that while preparing this version, I found that DPDK has
some ARP related structures and macros defined. So, use them instead of
the one from standard header files here.
Cc: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2016-02-22 14:36:11 +00:00
|
|
|
}
|
|
|
|
|
2016-03-10 04:32:39 +00:00
|
|
|
return i;
|
2014-08-15 04:58:01 +00:00
|
|
|
}
|