2017-12-19 15:49:03 +00:00
|
|
|
/* SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
* Copyright(c) 2010-2016 Intel Corporation
|
2014-02-10 13:57:48 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#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>
|
2018-01-17 13:49:25 +00:00
|
|
|
#include <rte_spinlock.h>
|
2018-01-24 10:27:25 +00:00
|
|
|
#include <rte_malloc.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
|
|
|
}
|
|
|
|
|
2018-01-24 10:27:25 +00:00
|
|
|
static __rte_always_inline struct vring_desc *
|
|
|
|
alloc_copy_ind_table(struct virtio_net *dev, struct vhost_virtqueue *vq,
|
|
|
|
struct vring_desc *desc)
|
|
|
|
{
|
|
|
|
struct vring_desc *idesc;
|
|
|
|
uint64_t src, dst;
|
|
|
|
uint64_t len, remain = desc->len;
|
|
|
|
uint64_t desc_addr = desc->addr;
|
|
|
|
|
|
|
|
idesc = rte_malloc(__func__, desc->len, 0);
|
|
|
|
if (unlikely(!idesc))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
dst = (uint64_t)(uintptr_t)idesc;
|
|
|
|
|
|
|
|
while (remain) {
|
|
|
|
len = remain;
|
|
|
|
src = vhost_iova_to_vva(dev, vq, desc_addr, &len,
|
|
|
|
VHOST_ACCESS_RO);
|
|
|
|
if (unlikely(!src || !len)) {
|
|
|
|
rte_free(idesc);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
rte_memcpy((void *)(uintptr_t)dst, (void *)(uintptr_t)src, len);
|
|
|
|
|
|
|
|
remain -= len;
|
|
|
|
dst += len;
|
|
|
|
desc_addr += len;
|
|
|
|
}
|
|
|
|
|
|
|
|
return idesc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static __rte_always_inline void
|
|
|
|
free_ind_table(struct vring_desc *idesc)
|
|
|
|
{
|
|
|
|
rte_free(idesc);
|
|
|
|
}
|
|
|
|
|
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-11-21 06:56:52 +00:00
|
|
|
} else if (m_buf->ol_flags & PKT_TX_UDP_SEG) {
|
|
|
|
net_hdr->gso_type = VIRTIO_NET_HDR_GSO_UDP;
|
|
|
|
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;
|
2018-03-01 07:47:58 +00:00
|
|
|
uint64_t desc_chunck_len;
|
2016-03-10 04:32:40 +00:00
|
|
|
struct vring_desc *desc;
|
2018-03-01 07:47:58 +00:00
|
|
|
uint64_t desc_addr, desc_gaddr;
|
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];
|
2018-03-01 07:47:58 +00:00
|
|
|
desc_chunck_len = desc->len;
|
|
|
|
desc_gaddr = desc->addr;
|
|
|
|
desc_addr = vhost_iova_to_vva(dev, vq, desc_gaddr,
|
|
|
|
&desc_chunck_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.
|
|
|
|
*/
|
2018-03-01 07:47:58 +00:00
|
|
|
if (unlikely(desc->len < dev->vhost_hlen) || !desc_addr) {
|
2017-09-08 12:50:46 +00:00
|
|
|
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);
|
|
|
|
|
2018-03-01 07:47:58 +00:00
|
|
|
if (likely(desc_chunck_len >= dev->vhost_hlen)) {
|
|
|
|
virtio_enqueue_offload(m,
|
|
|
|
(struct virtio_net_hdr *)(uintptr_t)desc_addr);
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)desc_addr, dev->vhost_hlen, 0);
|
|
|
|
vhost_log_write(dev, desc_gaddr, dev->vhost_hlen);
|
|
|
|
} else {
|
|
|
|
struct virtio_net_hdr vnet_hdr;
|
|
|
|
uint64_t remain = dev->vhost_hlen;
|
|
|
|
uint64_t len;
|
|
|
|
uint64_t src = (uint64_t)(uintptr_t)&vnet_hdr, dst;
|
|
|
|
uint64_t guest_addr = desc_gaddr;
|
|
|
|
|
|
|
|
virtio_enqueue_offload(m, &vnet_hdr);
|
|
|
|
|
|
|
|
while (remain) {
|
|
|
|
len = remain;
|
|
|
|
dst = vhost_iova_to_vva(dev, vq, guest_addr,
|
|
|
|
&len, VHOST_ACCESS_RW);
|
|
|
|
if (unlikely(!dst || !len)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
rte_memcpy((void *)(uintptr_t)dst,
|
|
|
|
(void *)(uintptr_t)src, len);
|
|
|
|
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)dst, (uint32_t)len, 0);
|
|
|
|
vhost_log_write(dev, guest_addr, len);
|
|
|
|
remain -= len;
|
|
|
|
guest_addr += len;
|
|
|
|
dst += len;
|
|
|
|
}
|
|
|
|
}
|
2016-03-10 04:32:40 +00:00
|
|
|
|
2016-05-01 23:58:52 +00:00
|
|
|
desc_avail = desc->len - dev->vhost_hlen;
|
2018-03-01 07:47:58 +00:00
|
|
|
if (unlikely(desc_chunck_len < dev->vhost_hlen)) {
|
|
|
|
desc_chunck_len = desc_avail;
|
|
|
|
desc_gaddr = desc->addr + dev->vhost_hlen;
|
|
|
|
desc_addr = vhost_iova_to_vva(dev,
|
|
|
|
vq, desc_gaddr,
|
|
|
|
&desc_chunck_len,
|
|
|
|
VHOST_ACCESS_RW);
|
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
desc_offset = 0;
|
|
|
|
} else {
|
|
|
|
desc_offset = dev->vhost_hlen;
|
|
|
|
desc_chunck_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];
|
2018-03-01 07:47:58 +00:00
|
|
|
desc_chunck_len = desc->len;
|
|
|
|
desc_gaddr = desc->addr;
|
|
|
|
desc_addr = vhost_iova_to_vva(dev, vq, desc_gaddr,
|
|
|
|
&desc_chunck_len,
|
2017-10-05 08:36:20 +00:00
|
|
|
VHOST_ACCESS_RW);
|
2018-03-01 07:47:58 +00:00
|
|
|
if (unlikely(!desc_addr)) {
|
2017-09-08 12:50:46 +00:00
|
|
|
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;
|
2018-03-01 07:47:58 +00:00
|
|
|
} else if (unlikely(desc_chunck_len == 0)) {
|
|
|
|
desc_chunck_len = desc_avail;
|
|
|
|
desc_gaddr += desc_offset;
|
|
|
|
desc_addr = vhost_iova_to_vva(dev,
|
|
|
|
vq, desc_gaddr,
|
|
|
|
&desc_chunck_len, VHOST_ACCESS_RW);
|
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
desc_offset = 0;
|
2016-03-10 04:32:40 +00:00
|
|
|
}
|
|
|
|
|
2018-03-01 07:47:58 +00:00
|
|
|
cpy_len = RTE_MIN(desc_chunck_len, 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);
|
2018-03-01 07:47:58 +00:00
|
|
|
vhost_log_write(dev, desc_gaddr + desc_offset, cpy_len);
|
2017-09-08 12:50:46 +00:00
|
|
|
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);
|
2018-03-01 07:47:58 +00:00
|
|
|
batch_copy[copy_nb].log_addr = desc_gaddr + desc_offset;
|
2017-09-08 12:50:46 +00:00
|
|
|
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;
|
2018-03-01 07:47:58 +00:00
|
|
|
desc_chunck_len -= cpy_len;
|
2016-03-10 04:32:40 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2018-02-09 17:24:00 +00:00
|
|
|
VHOST_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];
|
2018-01-17 13:49:25 +00:00
|
|
|
|
|
|
|
rte_spinlock_lock(&vq->access_lock);
|
|
|
|
|
2015-10-22 12:35:54 +00:00
|
|
|
if (unlikely(vq->enabled == 0))
|
2018-01-17 13:49:25 +00:00
|
|
|
goto out_access_unlock;
|
2015-10-22 12:35:54 +00:00
|
|
|
|
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
|
|
|
|
2018-02-09 17:24:00 +00:00
|
|
|
VHOST_LOG_DEBUG(VHOST_DATA, "(%d) start_idx %d | end_idx %d\n",
|
2016-06-13 11:52:12 +00:00
|
|
|
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++) {
|
2018-01-24 10:27:25 +00:00
|
|
|
struct vring_desc *idesc = NULL;
|
2016-03-10 04:32:40 +00:00
|
|
|
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) {
|
2018-01-23 13:26:02 +00:00
|
|
|
uint64_t dlen = vq->desc[desc_idx].len;
|
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,
|
2018-01-23 13:26:02 +00:00
|
|
|
&dlen, VHOST_ACCESS_RO);
|
2018-01-24 10:27:25 +00:00
|
|
|
if (unlikely(!descs)) {
|
2016-10-18 15:35:39 +00:00
|
|
|
count = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2018-01-24 10:27:25 +00:00
|
|
|
if (unlikely(dlen < vq->desc[desc_idx].len)) {
|
|
|
|
/*
|
|
|
|
* The indirect desc table is not contiguous
|
|
|
|
* in process VA space, we have to copy it.
|
|
|
|
*/
|
|
|
|
idesc = alloc_copy_ind_table(dev, vq,
|
|
|
|
&vq->desc[desc_idx]);
|
|
|
|
if (unlikely(!idesc))
|
|
|
|
break;
|
|
|
|
|
|
|
|
descs = idesc;
|
|
|
|
}
|
|
|
|
|
2016-10-18 15:35:39 +00:00
|
|
|
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;
|
2018-01-24 10:27:25 +00:00
|
|
|
free_ind_table(idesc);
|
2017-10-05 08:36:10 +00:00
|
|
|
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]]);
|
2018-01-24 10:27:25 +00:00
|
|
|
|
|
|
|
if (unlikely(!!idesc))
|
|
|
|
free_ind_table(idesc);
|
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
|
|
|
|
2018-01-09 11:03:48 +00:00
|
|
|
vhost_vring_call(dev, vq);
|
2017-10-05 08:36:25 +00:00
|
|
|
out:
|
|
|
|
if (dev->features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))
|
|
|
|
vhost_user_iotlb_rd_unlock(vq);
|
|
|
|
|
2018-01-17 13:49:25 +00:00
|
|
|
out_access_unlock:
|
|
|
|
rte_spinlock_unlock(&vq->access_lock);
|
|
|
|
|
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;
|
2018-01-23 13:26:02 +00:00
|
|
|
uint64_t dlen;
|
2016-10-18 15:35:38 +00:00
|
|
|
struct vring_desc *descs = vq->desc;
|
2018-01-24 10:27:25 +00:00
|
|
|
struct vring_desc *idesc = NULL;
|
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) {
|
2018-01-23 13:26:02 +00:00
|
|
|
dlen = vq->desc[idx].len;
|
2016-10-18 15:35:38 +00:00
|
|
|
descs = (struct vring_desc *)(uintptr_t)
|
2017-10-05 08:36:20 +00:00
|
|
|
vhost_iova_to_vva(dev, vq, vq->desc[idx].addr,
|
2018-01-23 13:26:02 +00:00
|
|
|
&dlen,
|
2017-10-05 08:36:20 +00:00
|
|
|
VHOST_ACCESS_RO);
|
2018-01-24 10:27:25 +00:00
|
|
|
if (unlikely(!descs))
|
2016-10-18 15:35:38 +00:00
|
|
|
return -1;
|
|
|
|
|
2018-01-24 10:27:25 +00:00
|
|
|
if (unlikely(dlen < vq->desc[idx].len)) {
|
|
|
|
/*
|
|
|
|
* The indirect desc table is not contiguous
|
|
|
|
* in process VA space, we have to copy it.
|
|
|
|
*/
|
|
|
|
idesc = alloc_copy_ind_table(dev, vq, &vq->desc[idx]);
|
|
|
|
if (unlikely(!idesc))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
descs = idesc;
|
|
|
|
}
|
|
|
|
|
2016-10-18 15:35:38 +00:00
|
|
|
idx = 0;
|
|
|
|
}
|
|
|
|
|
2016-03-14 07:35:22 +00:00
|
|
|
while (1) {
|
2018-01-24 10:27:25 +00:00
|
|
|
if (unlikely(vec_id >= BUF_VECTOR_MAX || idx >= vq->size)) {
|
|
|
|
free_ind_table(idesc);
|
2016-03-14 07:35:22 +00:00
|
|
|
return -1;
|
2018-01-24 10:27:25 +00:00
|
|
|
}
|
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
|
|
|
|
2018-01-24 10:27:25 +00:00
|
|
|
if (unlikely(!!idesc))
|
|
|
|
free_ind_table(idesc);
|
|
|
|
|
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;
|
2018-03-01 08:36:33 +00:00
|
|
|
uint64_t desc_addr, desc_gaddr;
|
2016-03-14 07:35:22 +00:00
|
|
|
uint32_t mbuf_offset, mbuf_avail;
|
|
|
|
uint32_t desc_offset, desc_avail;
|
|
|
|
uint32_t cpy_len;
|
2018-03-01 08:36:33 +00:00
|
|
|
uint64_t desc_chunck_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;
|
2018-03-01 08:36:33 +00:00
|
|
|
struct virtio_net_hdr_mrg_rxbuf tmp_hdr, *hdr = NULL;
|
2017-09-08 12:50:46 +00:00
|
|
|
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
|
|
|
|
2018-03-01 08:36:33 +00:00
|
|
|
desc_chunck_len = buf_vec[vec_idx].buf_len;
|
|
|
|
desc_gaddr = buf_vec[vec_idx].buf_addr;
|
|
|
|
desc_addr = vhost_iova_to_vva(dev, vq,
|
|
|
|
desc_gaddr,
|
|
|
|
&desc_chunck_len,
|
|
|
|
VHOST_ACCESS_RW);
|
|
|
|
if (buf_vec[vec_idx].buf_len < dev->vhost_hlen || !desc_addr) {
|
2017-09-08 12:50:46 +00:00
|
|
|
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;
|
2018-03-01 08:36:33 +00:00
|
|
|
if (unlikely(desc_chunck_len < dev->vhost_hlen))
|
|
|
|
hdr = &tmp_hdr;
|
|
|
|
else
|
|
|
|
hdr = (struct virtio_net_hdr_mrg_rxbuf *)(uintptr_t)hdr_addr;
|
|
|
|
hdr_phys_addr = desc_gaddr;
|
2016-10-14 09:34:33 +00:00
|
|
|
rte_prefetch0((void *)(uintptr_t)hdr_addr);
|
2014-08-15 04:58:01 +00:00
|
|
|
|
2018-02-09 17:24:00 +00:00
|
|
|
VHOST_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;
|
2018-03-01 08:36:33 +00:00
|
|
|
if (unlikely(desc_chunck_len < dev->vhost_hlen)) {
|
|
|
|
desc_chunck_len = desc_avail;
|
|
|
|
desc_gaddr += dev->vhost_hlen;
|
|
|
|
desc_addr = vhost_iova_to_vva(dev, vq,
|
|
|
|
desc_gaddr,
|
|
|
|
&desc_chunck_len,
|
|
|
|
VHOST_ACCESS_RW);
|
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
desc_offset = 0;
|
|
|
|
} else {
|
|
|
|
desc_offset = dev->vhost_hlen;
|
|
|
|
desc_chunck_len -= 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++;
|
2018-03-01 08:36:33 +00:00
|
|
|
desc_chunck_len = buf_vec[vec_idx].buf_len;
|
|
|
|
desc_gaddr = buf_vec[vec_idx].buf_addr;
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr =
|
|
|
|
vhost_iova_to_vva(dev, vq,
|
2018-03-01 08:36:33 +00:00
|
|
|
desc_gaddr,
|
|
|
|
&desc_chunck_len,
|
2017-10-05 08:36:20 +00:00
|
|
|
VHOST_ACCESS_RW);
|
2018-03-01 08:36:33 +00:00
|
|
|
if (unlikely(!desc_addr)) {
|
2017-09-08 12:50:46 +00:00
|
|
|
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;
|
2018-03-01 08:36:33 +00:00
|
|
|
} else if (unlikely(desc_chunck_len == 0)) {
|
|
|
|
desc_chunck_len = desc_avail;
|
|
|
|
desc_gaddr += desc_offset;
|
|
|
|
desc_addr = vhost_iova_to_vva(dev, vq,
|
|
|
|
desc_gaddr,
|
|
|
|
&desc_chunck_len, VHOST_ACCESS_RW);
|
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
desc_offset = 0;
|
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
|
|
|
virtio_enqueue_offload(hdr_mbuf, &hdr->hdr);
|
|
|
|
ASSIGN_UNLESS_EQUAL(hdr->num_buffers, num_buffers);
|
|
|
|
|
2018-03-01 08:36:33 +00:00
|
|
|
if (unlikely(hdr == &tmp_hdr)) {
|
|
|
|
uint64_t len;
|
|
|
|
uint64_t remain = dev->vhost_hlen;
|
|
|
|
uint64_t src = (uint64_t)(uintptr_t)hdr, dst;
|
|
|
|
uint64_t guest_addr = hdr_phys_addr;
|
|
|
|
|
|
|
|
while (remain) {
|
|
|
|
len = remain;
|
|
|
|
dst = vhost_iova_to_vva(dev, vq,
|
|
|
|
guest_addr, &len,
|
|
|
|
VHOST_ACCESS_RW);
|
|
|
|
if (unlikely(!dst || !len)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
rte_memcpy((void *)(uintptr_t)dst,
|
|
|
|
(void *)(uintptr_t)src,
|
|
|
|
len);
|
|
|
|
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)dst,
|
|
|
|
(uint32_t)len, 0);
|
|
|
|
vhost_log_write(dev, guest_addr, len);
|
|
|
|
|
|
|
|
remain -= len;
|
|
|
|
guest_addr += len;
|
|
|
|
dst += len;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)hdr_addr,
|
|
|
|
dev->vhost_hlen, 0);
|
|
|
|
vhost_log_write(dev, hdr_phys_addr,
|
|
|
|
dev->vhost_hlen);
|
|
|
|
}
|
2016-10-14 09:34:33 +00:00
|
|
|
|
|
|
|
hdr_addr = 0;
|
|
|
|
}
|
|
|
|
|
2018-03-01 08:36:33 +00:00
|
|
|
cpy_len = RTE_MIN(desc_chunck_len, 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);
|
2018-03-01 08:36:33 +00:00
|
|
|
vhost_log_write(dev, desc_gaddr + desc_offset, cpy_len);
|
2017-09-08 12:50:46 +00:00
|
|
|
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);
|
2018-03-01 08:36:33 +00:00
|
|
|
batch_copy[copy_nb].log_addr = desc_gaddr + desc_offset;
|
2017-09-08 12:50:46 +00:00
|
|
|
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;
|
2018-03-01 08:36:33 +00:00
|
|
|
desc_chunck_len -= cpy_len;
|
2016-03-14 07:35:22 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2018-02-09 17:24:00 +00:00
|
|
|
VHOST_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];
|
2018-01-17 13:49:25 +00:00
|
|
|
|
|
|
|
rte_spinlock_lock(&vq->access_lock);
|
|
|
|
|
2015-10-22 12:35:54 +00:00
|
|
|
if (unlikely(vq->enabled == 0))
|
2018-01-17 13:49:25 +00:00
|
|
|
goto out_access_unlock;
|
2015-10-22 12:35:54 +00:00
|
|
|
|
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)) {
|
2018-02-09 17:24:00 +00:00
|
|
|
VHOST_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
|
|
|
|
2018-02-09 17:24:00 +00:00
|
|
|
VHOST_LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
|
2016-10-14 09:34:36 +00:00
|
|
|
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);
|
2018-01-09 11:03:48 +00:00
|
|
|
vhost_vring_call(dev, vq);
|
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);
|
|
|
|
|
2018-01-17 13:49:25 +00:00
|
|
|
out_access_unlock:
|
|
|
|
rte_spinlock_unlock(&vq->access_lock);
|
|
|
|
|
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;
|
|
|
|
|
2018-01-31 17:46:50 +00:00
|
|
|
if (unlikely(!(dev->flags & VIRTIO_DEV_BUILTIN_VIRTIO_NET))) {
|
|
|
|
RTE_LOG(ERR, VHOST_DATA,
|
|
|
|
"(%d) %s: built-in vhost net backend is disabled.\n",
|
|
|
|
dev->vid, __func__);
|
|
|
|
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;
|
2017-11-21 06:56:52 +00:00
|
|
|
case VIRTIO_NET_HDR_GSO_UDP:
|
|
|
|
m->ol_flags |= PKT_TX_UDP_SEG;
|
|
|
|
m->tso_segsz = hdr->gso_size;
|
|
|
|
m->l4_len = sizeof(struct udp_hdr);
|
|
|
|
break;
|
2016-02-05 07:31:38 +00:00
|
|
|
default:
|
|
|
|
RTE_LOG(WARNING, VHOST_DATA,
|
|
|
|
"unsupported gso type %u.\n", hdr->gso_type);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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;
|
2018-01-24 16:19:29 +00:00
|
|
|
uint64_t desc_addr, desc_gaddr;
|
2016-03-10 04:32:39 +00:00
|
|
|
uint32_t desc_avail, desc_offset;
|
|
|
|
uint32_t mbuf_avail, mbuf_offset;
|
|
|
|
uint32_t cpy_len;
|
2018-01-24 16:19:29 +00:00
|
|
|
uint64_t desc_chunck_len;
|
2016-03-10 04:32:39 +00:00
|
|
|
struct rte_mbuf *cur = m, *prev = m;
|
2018-01-24 16:19:29 +00:00
|
|
|
struct virtio_net_hdr tmp_hdr;
|
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
|
|
|
|
2018-01-24 16:19:29 +00:00
|
|
|
desc_chunck_len = desc->len;
|
|
|
|
desc_gaddr = desc->addr;
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr = vhost_iova_to_vva(dev,
|
2018-01-24 16:19:29 +00:00
|
|
|
vq, desc_gaddr,
|
|
|
|
&desc_chunck_len,
|
2017-10-05 08:36:20 +00:00
|
|
|
VHOST_ACCESS_RO);
|
2018-01-24 16:19:29 +00:00
|
|
|
if (unlikely(!desc_addr)) {
|
2017-09-08 12:50:46 +00:00
|
|
|
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)) {
|
2018-01-24 16:19:29 +00:00
|
|
|
if (unlikely(desc_chunck_len < sizeof(struct virtio_net_hdr))) {
|
|
|
|
uint64_t len = desc_chunck_len;
|
|
|
|
uint64_t remain = sizeof(struct virtio_net_hdr);
|
|
|
|
uint64_t src = desc_addr;
|
|
|
|
uint64_t dst = (uint64_t)(uintptr_t)&tmp_hdr;
|
|
|
|
uint64_t guest_addr = desc_gaddr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* No luck, the virtio-net header doesn't fit
|
|
|
|
* in a contiguous virtual area.
|
|
|
|
*/
|
|
|
|
while (remain) {
|
|
|
|
len = remain;
|
|
|
|
src = vhost_iova_to_vva(dev, vq,
|
|
|
|
guest_addr, &len,
|
|
|
|
VHOST_ACCESS_RO);
|
|
|
|
if (unlikely(!src || !len)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
rte_memcpy((void *)(uintptr_t)dst,
|
|
|
|
(void *)(uintptr_t)src, len);
|
|
|
|
|
|
|
|
guest_addr += len;
|
|
|
|
remain -= len;
|
|
|
|
dst += len;
|
|
|
|
}
|
|
|
|
|
|
|
|
hdr = &tmp_hdr;
|
|
|
|
} else {
|
|
|
|
hdr = (struct virtio_net_hdr *)((uintptr_t)desc_addr);
|
|
|
|
rte_prefetch0(hdr);
|
|
|
|
}
|
2016-10-14 08:07:07 +00:00
|
|
|
}
|
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
|
|
|
|
2018-01-24 16:19:29 +00:00
|
|
|
desc_chunck_len = desc->len;
|
|
|
|
desc_gaddr = desc->addr;
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr = vhost_iova_to_vva(dev,
|
2018-01-24 16:19:29 +00:00
|
|
|
vq, desc_gaddr,
|
|
|
|
&desc_chunck_len,
|
2017-10-05 08:36:20 +00:00
|
|
|
VHOST_ACCESS_RO);
|
2018-01-24 16:19:29 +00:00
|
|
|
if (unlikely(!desc_addr)) {
|
2017-09-08 12:50:46 +00:00
|
|
|
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;
|
2018-01-24 16:19:29 +00:00
|
|
|
|
|
|
|
if (unlikely(desc_chunck_len < dev->vhost_hlen)) {
|
|
|
|
desc_chunck_len = desc_avail;
|
|
|
|
desc_gaddr += dev->vhost_hlen;
|
|
|
|
desc_addr = vhost_iova_to_vva(dev,
|
|
|
|
vq, desc_gaddr,
|
|
|
|
&desc_chunck_len,
|
|
|
|
VHOST_ACCESS_RO);
|
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
desc_offset = 0;
|
|
|
|
} else {
|
|
|
|
desc_offset = dev->vhost_hlen;
|
|
|
|
desc_chunck_len -= dev->vhost_hlen;
|
|
|
|
}
|
2016-05-03 00:46:17 +00:00
|
|
|
}
|
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));
|
|
|
|
|
2018-01-24 16:19:29 +00:00
|
|
|
PRINT_PACKET(dev, (uintptr_t)(desc_addr + desc_offset),
|
|
|
|
(uint32_t)desc_chunck_len, 0);
|
2016-10-14 08:07:07 +00:00
|
|
|
|
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;
|
|
|
|
|
2018-01-24 16:19:29 +00:00
|
|
|
cpy_len = RTE_MIN(desc_chunck_len, 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,
|
2018-01-24 16:19:29 +00:00
|
|
|
desc_gaddr + desc_offset, cpy_len)))) {
|
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
|
|
|
cur->data_len = cpy_len;
|
|
|
|
cur->data_off = 0;
|
2017-12-13 16:50:56 +00:00
|
|
|
cur->buf_addr = (void *)(uintptr_t)(desc_addr
|
|
|
|
+ desc_offset);
|
2017-10-20 12:31:32 +00:00
|
|
|
cur->buf_iova = hpa;
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* 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 ||
|
2017-10-24 03:12:30 +00:00
|
|
|
copy_nb >= vq->size ||
|
2018-01-24 16:19:29 +00:00
|
|
|
(hdr && cur == m) ||
|
|
|
|
desc->len != desc_chunck_len)) {
|
2017-09-08 12:50:46 +00:00
|
|
|
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;
|
2018-01-24 16:19:29 +00:00
|
|
|
desc_chunck_len -= cpy_len;
|
2016-05-03 00:46:17 +00:00
|
|
|
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
|
|
|
|
2018-01-24 16:19:29 +00:00
|
|
|
desc_chunck_len = desc->len;
|
|
|
|
desc_gaddr = desc->addr;
|
2017-10-05 08:36:20 +00:00
|
|
|
desc_addr = vhost_iova_to_vva(dev,
|
2018-01-24 16:19:29 +00:00
|
|
|
vq, desc_gaddr,
|
|
|
|
&desc_chunck_len,
|
|
|
|
VHOST_ACCESS_RO);
|
|
|
|
if (unlikely(!desc_addr)) {
|
2017-09-08 12:50:46 +00:00
|
|
|
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;
|
|
|
|
|
2018-01-24 16:19:29 +00:00
|
|
|
PRINT_PACKET(dev, (uintptr_t)desc_addr,
|
|
|
|
(uint32_t)desc_chunck_len, 0);
|
|
|
|
} else if (unlikely(desc_chunck_len == 0)) {
|
|
|
|
desc_chunck_len = desc_avail;
|
|
|
|
desc_gaddr += desc_offset;
|
|
|
|
desc_addr = vhost_iova_to_vva(dev, vq,
|
|
|
|
desc_gaddr,
|
|
|
|
&desc_chunck_len,
|
|
|
|
VHOST_ACCESS_RO);
|
|
|
|
if (unlikely(!desc_addr)) {
|
|
|
|
error = -1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
desc_offset = 0;
|
|
|
|
|
|
|
|
PRINT_PACKET(dev, (uintptr_t)desc_addr,
|
|
|
|
(uint32_t)desc_chunck_len, 0);
|
2016-03-10 04:32:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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));
|
2018-01-09 11:03:48 +00:00
|
|
|
vhost_vring_call(dev, 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
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2018-01-17 15:45:53 +00:00
|
|
|
static __rte_always_inline void
|
|
|
|
restore_mbuf(struct rte_mbuf *m)
|
|
|
|
{
|
|
|
|
uint32_t mbuf_size, priv_size;
|
|
|
|
|
|
|
|
while (m) {
|
|
|
|
priv_size = rte_pktmbuf_priv_size(m->pool);
|
|
|
|
mbuf_size = sizeof(struct rte_mbuf) + priv_size;
|
|
|
|
/* start of buffer is after mbuf structure and priv data */
|
|
|
|
|
|
|
|
m->buf_addr = (char *)m + mbuf_size;
|
|
|
|
m->buf_iova = rte_mempool_virt2iova(m) + mbuf_size;
|
|
|
|
m = m->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
2018-01-31 17:46:50 +00:00
|
|
|
if (unlikely(!(dev->flags & VIRTIO_DEV_BUILTIN_VIRTIO_NET))) {
|
|
|
|
RTE_LOG(ERR, VHOST_DATA,
|
|
|
|
"(%d) %s: built-in vhost net backend is disabled.\n",
|
|
|
|
dev->vid, __func__);
|
|
|
|
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];
|
2018-01-17 13:49:25 +00:00
|
|
|
|
|
|
|
if (unlikely(rte_spinlock_trylock(&vq->access_lock) == 0))
|
2015-10-22 12:35:54 +00:00
|
|
|
return 0;
|
|
|
|
|
2018-01-17 13:49:25 +00:00
|
|
|
if (unlikely(vq->enabled == 0))
|
|
|
|
goto out_access_unlock;
|
|
|
|
|
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);
|
2018-01-17 15:45:53 +00:00
|
|
|
restore_mbuf(zmbuf->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
|
|
|
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))) {
|
|
|
|
|
2018-01-18 02:32:24 +00:00
|
|
|
rarp_mbuf = rte_net_make_rarp_packet(mbuf_pool, &dev->mac);
|
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 (rarp_mbuf == NULL) {
|
|
|
|
RTE_LOG(ERR, VHOST_DATA,
|
2018-01-18 02:32:24 +00:00
|
|
|
"Failed to make RARP packet.\n");
|
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
|
|
|
return 0;
|
|
|
|
}
|
2018-01-18 02:32:24 +00:00
|
|
|
count -= 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-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
|
|
|
|
2018-02-09 17:24:00 +00:00
|
|
|
VHOST_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);
|
2018-02-09 17:24:00 +00:00
|
|
|
VHOST_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++) {
|
2018-01-24 10:27:25 +00:00
|
|
|
struct vring_desc *desc, *idesc = NULL;
|
2016-09-27 08:42:49 +00:00
|
|
|
uint16_t sz, idx;
|
2018-01-23 13:26:02 +00:00
|
|
|
uint64_t dlen;
|
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) {
|
2018-01-23 13:26:02 +00:00
|
|
|
dlen = vq->desc[desc_indexes[i]].len;
|
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,
|
2018-01-23 13:26:02 +00:00
|
|
|
&dlen,
|
2017-10-05 08:36:20 +00:00
|
|
|
VHOST_ACCESS_RO);
|
2018-01-24 10:27:25 +00:00
|
|
|
if (unlikely(!desc))
|
2016-09-27 08:42:49 +00:00
|
|
|
break;
|
|
|
|
|
2018-01-24 10:27:25 +00:00
|
|
|
if (unlikely(dlen < vq->desc[desc_indexes[i]].len)) {
|
|
|
|
/*
|
|
|
|
* The indirect desc table is not contiguous
|
|
|
|
* in process VA space, we have to copy it.
|
|
|
|
*/
|
|
|
|
idesc = alloc_copy_ind_table(dev, vq,
|
|
|
|
&vq->desc[desc_indexes[i]]);
|
|
|
|
if (unlikely(!idesc))
|
|
|
|
break;
|
|
|
|
|
|
|
|
desc = idesc;
|
|
|
|
}
|
|
|
|
|
2016-09-27 08:42:49 +00:00
|
|
|
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");
|
2018-01-24 10:27:25 +00:00
|
|
|
free_ind_table(idesc);
|
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]);
|
2018-01-24 10:27:25 +00:00
|
|
|
free_ind_table(idesc);
|
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]);
|
2018-01-24 10:27:25 +00:00
|
|
|
free_ind_table(idesc);
|
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
|
|
|
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);
|
|
|
|
}
|
2018-01-24 10:27:25 +00:00
|
|
|
|
|
|
|
if (unlikely(!!idesc))
|
|
|
|
free_ind_table(idesc);
|
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-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);
|
|
|
|
|
2018-01-17 13:49:25 +00:00
|
|
|
out_access_unlock:
|
|
|
|
rte_spinlock_unlock(&vq->access_lock);
|
|
|
|
|
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
|
|
|
}
|