[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
Hello, We also notice these conflicts, we just planned to fix it in our new feature development. The proposal is like: #ifndef _NETINET_IN_H #ifndef _NETINET_IN_H_ #define IPPROTO_IP 0 ... ... #define IPPROTO_MAX 256 #endif #endif Do you think it is a good idea? > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Antti Kantee > Sent: Friday, July 25, 2014 6:56 AM > To: Matthew Hall; dev at dpdk.org > Subject: Re: [dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, > and rte_ip.h > > On 24/07/14 07:59, Matthew Hall wrote: > > Hello, > > > > I ran into some weird symbol conflicts between system netinet/in.h and DPDK > > rte_ip.h. They have a lot of duplicated definitions for stuff like > > IPPROTO_IP > > and so on. This breaks when you want to use inet_pton from arpa/inet.h, > > because it includes netinet/in.h to define struct in_addr. > > I would namespace the definitions in DPDK, i.e. make them > DPDK_IPPROTO_FOO etc. > > > Thus with all the conflicts it's impossible to use a DPDK IP struct instead > > of > > all the system's sockaddr stuff, to store a value from the system copy of > > inet_pton. This would be a common operation if, for example, you want to > > configure all the IP addresses on your box from a JSON file, which is what I > > was doing. > > > > The DPDK kludged around it internally by using a file called > > cmdline_parse_ipaddr.c with private copies of these functions. But it in my > > opinion very unwisely marked all of the functions as static except for > > cmdline_parse_ipaddr, which only works on the DPDK's proprietary argument > > handling, and not with anything the user might have which is a different > > format. > > In my experience from years of fighting with more or less this exact > same problem -- the fight is now thankfully over but the scars remain -- > you either want to expose a complete set of types and provide support > for everything, or you want to expose nothing. Approaches where you use > cute definitions and reuse some host routines is like asking for an > audience with Tyranthraxus when armed with a kitten. It's that doubly > so if you don't have to and do it anyway. > > > So, it would be a big help for users if the macros in librte_net files would > > check if the symbols already existed, or if they had subheader files > > available > > to grab only non conflicting symbols, or if they would make a proper .h and > > factor all the inet_pton and inet_ntop inside the cmdline lib into a place > > where users can access them. It would also be a help if they had a less ugly > > equivalent to struct sockaddr, which let you work with IP addresses a bit > > more > > easily, such as something like this: > > Again, I recommend steering away from any tightrope approaches that > "know" which types are non-conflicting, or pick out half-and-half from > the host and IP stack. "Do, or do not, there is no half-and-half"
[dpdk-dev] [PATCH v2] virtio: Support mergeable buffer in virtio PMD
v2 change:
- Resolve conflicts wiht the tip code;
- And resolve 2 issues:
-- fix mbuf leak when discard a uncompleted packet.
-- refine pkt.data to point to actual payload data start point.
v1 change:
This patch supports mergeable buffer feature in DPDK based virtio PMD, which can
receive jumbo frame with larger size, like 3K, 4K or even 9K.
Signed-off-by: Changchun Ouyang
---
lib/librte_pmd_virtio/virtio_ethdev.c | 20 ++--
lib/librte_pmd_virtio/virtio_ethdev.h | 3 +
lib/librte_pmd_virtio/virtio_rxtx.c | 206 +-
3 files changed, 194 insertions(+), 35 deletions(-)
diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c
b/lib/librte_pmd_virtio/virtio_ethdev.c
index b9f5529..535d798 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -337,7 +337,7 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
snprintf(vq_name, sizeof(vq_name), "port%d_tvq%d_hdrzone",
dev->data->port_id, queue_idx);
vq->virtio_net_hdr_mz = rte_memzone_reserve_aligned(vq_name,
- vq_size * sizeof(struct virtio_net_hdr),
+ vq_size * hw->vtnet_hdr_size,
socket_id, 0, CACHE_LINE_SIZE);
if (vq->virtio_net_hdr_mz == NULL) {
rte_free(vq);
@@ -346,7 +346,7 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
vq->virtio_net_hdr_mem =
vq->virtio_net_hdr_mz->phys_addr;
memset(vq->virtio_net_hdr_mz->addr, 0,
- vq_size * sizeof(struct virtio_net_hdr));
+ vq_size * hw->vtnet_hdr_size);
} else if (queue_type == VTNET_CQ) {
/* Allocate a page for control vq command, data and status */
snprintf(vq_name, sizeof(vq_name), "port%d_cvq_hdrzone",
@@ -571,9 +571,6 @@ virtio_negotiate_features(struct virtio_hw *hw)
mask |= VIRTIO_NET_F_GUEST_TSO4 | VIRTIO_NET_F_GUEST_TSO6 |
VIRTIO_NET_F_GUEST_ECN;
mask |= VTNET_LRO_FEATURES;
- /* rx_mbuf should not be in multiple merged segments */
- mask |= VIRTIO_NET_F_MRG_RXBUF;
-
/* not negotiating INDIRECT descriptor table support */
mask |= VIRTIO_RING_F_INDIRECT_DESC;
@@ -746,7 +743,6 @@ eth_virtio_dev_init(__rte_unused struct eth_driver *eth_drv,
}
eth_dev->dev_ops = &virtio_eth_dev_ops;
- eth_dev->rx_pkt_burst = &virtio_recv_pkts;
eth_dev->tx_pkt_burst = &virtio_xmit_pkts;
if (rte_eal_process_type() == RTE_PROC_SECONDARY)
@@ -801,10 +797,13 @@ eth_virtio_dev_init(__rte_unused struct eth_driver
*eth_drv,
virtio_negotiate_features(hw);
/* Setting up rx_header size for the device */
- if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF))
+ if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
+ eth_dev->rx_pkt_burst = &virtio_recv_mergeable_pkts;
hw->vtnet_hdr_size = sizeof(struct virtio_net_hdr_mrg_rxbuf);
- else
+ } else {
+ eth_dev->rx_pkt_burst = &virtio_recv_pkts;
hw->vtnet_hdr_size = sizeof(struct virtio_net_hdr);
+ }
/* Allocate memory for storing MAC addresses */
eth_dev->data->mac_addrs = rte_zmalloc("virtio", ETHER_ADDR_LEN, 0);
@@ -1009,7 +1008,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)
while ((buf = (struct rte_mbuf *)virtqueue_detatch_unused(
dev->data->rx_queues[i])) != NULL) {
- rte_pktmbuf_free_seg(buf);
+ rte_pktmbuf_free(buf);
mbuf_num++;
}
@@ -1028,7 +1027,8 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)
mbuf_num = 0;
while ((buf = (struct rte_mbuf *)virtqueue_detatch_unused(
dev->data->tx_queues[i])) != NULL) {
- rte_pktmbuf_free_seg(buf);
+ rte_pktmbuf_free(buf);
+
mbuf_num++;
}
diff --git a/lib/librte_pmd_virtio/virtio_ethdev.h
b/lib/librte_pmd_virtio/virtio_ethdev.h
index 858e644..d2e1eed 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.h
+++ b/lib/librte_pmd_virtio/virtio_ethdev.h
@@ -104,6 +104,9 @@ int virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
uint16_t tx_queue_id,
uint16_t virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
+uint16_t virtio_recv_mergeable_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts);
+
uint16_t virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);
diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c
b/lib/librte_pmd_virtio/virtio_rxtx.c
index fcd8bd1..3d81b34 100644
--- a/lib/librte_pmd_virtio/virtio_rxtx.c
+++ b/l
[dpdk-dev] [PATCH v2] virtio: Support mergeable buffer in virtio PMD
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ouyang Changchun
> Sent: Friday, July 25, 2014 2:03 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] virtio: Support mergeable buffer in virtio PMD
>
> v2 change:
> - Resolve conflicts wiht the tip code;
> - And resolve 2 issues:
>-- fix mbuf leak when discard a uncompleted packet.
>-- refine pkt.data to point to actual payload data start point.
>
> v1 change:
> This patch supports mergeable buffer feature in DPDK based virtio PMD, which
> can
> receive jumbo frame with larger size, like 3K, 4K or even 9K.
>
> Signed-off-by: Changchun Ouyang
> ---
> lib/librte_pmd_virtio/virtio_ethdev.c | 20 ++--
> lib/librte_pmd_virtio/virtio_ethdev.h | 3 +
> lib/librte_pmd_virtio/virtio_rxtx.c | 206 +---
> --
> 3 files changed, 194 insertions(+), 35 deletions(-)
>
> diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c
> b/lib/librte_pmd_virtio/virtio_ethdev.c
> index b9f5529..535d798 100644
> --- a/lib/librte_pmd_virtio/virtio_ethdev.c
> +++ b/lib/librte_pmd_virtio/virtio_ethdev.c
> @@ -337,7 +337,7 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
> snprintf(vq_name, sizeof(vq_name), "port%d_tvq%d_hdrzone",
> dev->data->port_id, queue_idx);
> vq->virtio_net_hdr_mz =
> rte_memzone_reserve_aligned(vq_name,
> - vq_size * sizeof(struct virtio_net_hdr),
> + vq_size * hw->vtnet_hdr_size,
> socket_id, 0, CACHE_LINE_SIZE);
> if (vq->virtio_net_hdr_mz == NULL) {
> rte_free(vq);
> @@ -346,7 +346,7 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
> vq->virtio_net_hdr_mem =
> vq->virtio_net_hdr_mz->phys_addr;
> memset(vq->virtio_net_hdr_mz->addr, 0,
> - vq_size * sizeof(struct virtio_net_hdr));
> + vq_size * hw->vtnet_hdr_size);
> } else if (queue_type == VTNET_CQ) {
> /* Allocate a page for control vq command, data and status */
> snprintf(vq_name, sizeof(vq_name), "port%d_cvq_hdrzone",
> @@ -571,9 +571,6 @@ virtio_negotiate_features(struct virtio_hw *hw)
> mask |= VIRTIO_NET_F_GUEST_TSO4 | VIRTIO_NET_F_GUEST_TSO6 |
> VIRTIO_NET_F_GUEST_ECN;
> mask |= VTNET_LRO_FEATURES;
>
> - /* rx_mbuf should not be in multiple merged segments */
> - mask |= VIRTIO_NET_F_MRG_RXBUF;
> -
> /* not negotiating INDIRECT descriptor table support */
> mask |= VIRTIO_RING_F_INDIRECT_DESC;
>
> @@ -746,7 +743,6 @@ eth_virtio_dev_init(__rte_unused struct eth_driver
> *eth_drv,
> }
>
> eth_dev->dev_ops = &virtio_eth_dev_ops;
> - eth_dev->rx_pkt_burst = &virtio_recv_pkts;
> eth_dev->tx_pkt_burst = &virtio_xmit_pkts;
>
> if (rte_eal_process_type() == RTE_PROC_SECONDARY)
> @@ -801,10 +797,13 @@ eth_virtio_dev_init(__rte_unused struct eth_driver
> *eth_drv,
> virtio_negotiate_features(hw);
>
> /* Setting up rx_header size for the device */
> - if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF))
> + if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
> + eth_dev->rx_pkt_burst = &virtio_recv_mergeable_pkts;
> hw->vtnet_hdr_size = sizeof(struct virtio_net_hdr_mrg_rxbuf);
> - else
> + } else {
> + eth_dev->rx_pkt_burst = &virtio_recv_pkts;
> hw->vtnet_hdr_size = sizeof(struct virtio_net_hdr);
> + }
>
> /* Allocate memory for storing MAC addresses */
> eth_dev->data->mac_addrs = rte_zmalloc("virtio", ETHER_ADDR_LEN,
> 0);
> @@ -1009,7 +1008,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev
> *dev)
>
> while ((buf = (struct rte_mbuf *)virtqueue_detatch_unused(
> dev->data->rx_queues[i])) != NULL) {
> - rte_pktmbuf_free_seg(buf);
> + rte_pktmbuf_free(buf);
> mbuf_num++;
> }
>
> @@ -1028,7 +1027,8 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev
> *dev)
> mbuf_num = 0;
> while ((buf = (struct rte_mbuf *)virtqueue_detatch_unused(
> dev->data->tx_queues[i])) != NULL) {
> - rte_pktmbuf_free_seg(buf);
> + rte_pktmbuf_free(buf);
> +
> mbuf_num++;
> }
>
> diff --git a/lib/librte_pmd_virtio/virtio_ethdev.h
> b/lib/librte_pmd_virtio/virtio_ethdev.h
> index 858e644..d2e1eed 100644
> --- a/lib/librte_pmd_virtio/virtio_ethdev.h
> +++ b/lib/librte_pmd_virtio/virtio_ethdev.h
> @@ -104,6 +104,9 @@ int virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
> uint16_t tx_queue_id,
> uint16_t virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
> uint16_t nb_pkts);
>
> +uint16_t virtio_recv_mergeable_p
[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
> > I don't know if it will work right on both Linux and BSD and/or if they also > 100% agree with the libc / glibc values compiled into the > system's .so files. That's the risk that you run if you don't have more > complete support in the DPDK itself for these features. Looking at linux and freebsd netinet/in.h files - I think it should work. But I suppose we can test it on both freebsd and linux before submitting a patch. > -- > Sent from my mobile device. > > On July 24, 2014 6:12:18 PM PDT, "Wu, Jingjing" > wrote: > >Hello, > > > >We also notice these conflicts, we just planned to fix it in our new > >feature development. The proposal is like: > > > >#ifndef _NETINET_IN_H > >#ifndef _NETINET_IN_H_ > > > >#define IPPROTO_IP 0 > > ... ... > >#define IPPROTO_MAX 256 > > > >#endif > >#endif > > > >Do you think it is a good idea? > > > >> -Original Message- > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Antti Kantee > >> Sent: Friday, July 25, 2014 6:56 AM > >> To: Matthew Hall; dev at dpdk.org > >> Subject: Re: [dpdk-dev] symbol conflicts between netinet/in.h, > >arpa/inet.h, and rte_ip.h > >> > >> On 24/07/14 07:59, Matthew Hall wrote: > >> > Hello, > >> > > >> > I ran into some weird symbol conflicts between system netinet/in.h > >and DPDK > >> > rte_ip.h. They have a lot of duplicated definitions for stuff like > >IPPROTO_IP > >> > and so on. This breaks when you want to use inet_pton from > >arpa/inet.h, > >> > because it includes netinet/in.h to define struct in_addr. > >> > >> I would namespace the definitions in DPDK, i.e. make them > >> DPDK_IPPROTO_FOO etc. > >> > >> > Thus with all the conflicts it's impossible to use a DPDK IP struct > >instead of > >> > all the system's sockaddr stuff, to store a value from the system > >copy of > >> > inet_pton. This would be a common operation if, for example, you > >want to > >> > configure all the IP addresses on your box from a JSON file, which > >is what I > >> > was doing. > >> > > >> > The DPDK kludged around it internally by using a file called > >> > cmdline_parse_ipaddr.c with private copies of these functions. But > >it in my > >> > opinion very unwisely marked all of the functions as static except > >for > >> > cmdline_parse_ipaddr, which only works on the DPDK's proprietary > >argument > >> > handling, and not with anything the user might have which is a > >different > >> > format. > >> > >> In my experience from years of fighting with more or less this exact > >> same problem -- the fight is now thankfully over but the scars remain > >-- > >> you either want to expose a complete set of types and provide support > >> for everything, or you want to expose nothing. Approaches where you > >use > >> cute definitions and reuse some host routines is like asking for an > >> audience with Tyranthraxus when armed with a kitten. It's that > >doubly > >> so if you don't have to and do it anyway. > >> > >> > So, it would be a big help for users if the macros in librte_net > >files would > >> > check if the symbols already existed, or if they had subheader > >files available > >> > to grab only non conflicting symbols, or if they would make a > >proper .h and > >> > factor all the inet_pton and inet_ntop inside the cmdline lib into > >a place > >> > where users can access them. It would also be a help if they had a > >less ugly > >> > equivalent to struct sockaddr, which let you work with IP addresses > >a bit more > >> > easily, such as something like this: > >> > >> Again, I recommend steering away from any tightrope approaches that > >> "know" which types are non-conflicting, or pick out half-and-half > >from > >> the host and IP stack. "Do, or do not, there is no half-and-half"
[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
Hi all, 2014-07-24 22:55, Antti Kantee: > On 24/07/14 07:59, Matthew Hall wrote: > > I ran into some weird symbol conflicts between system netinet/in.h and DPDK > > rte_ip.h. They have a lot of duplicated definitions for stuff like > > IPPROTO_IP > > and so on. This breaks when you want to use inet_pton from arpa/inet.h, > > because it includes netinet/in.h to define struct in_addr. [...] > Again, I recommend steering away from any tightrope approaches that > "know" which types are non-conflicting, or pick out half-and-half from > the host and IP stack. "Do, or do not, there is no half-and-half" The general problem here is that DPDK is conflicting with libc. So the obvious question would be: "why DPDK needs to redefine libc stuff"? I don't see any obvious answer since bare metal is planned to be removed. (see http://dpdk.org/ml/archives/dev/2014-June/003868.html) Objections? -- Thomas
[dpdk-dev] [PATCH v2] lib/librte_vhost: vhost library support to facilitate integration with vswitch.
Acked-by: Tommy Long -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Huawei Xie Sent: Friday, July 18, 2014 10:56 AM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH v2] lib/librte_vhost: vhost library support to facilitate integration with vswitch. Signed-off-by: Huawei Xie --- config/common_linuxapp |7 + lib/Makefile |1 + lib/librte_vhost/Makefile| 48 ++ lib/librte_vhost/eventfd_link/Makefile | 39 + lib/librte_vhost/eventfd_link/eventfd_link.c | 205 ++ lib/librte_vhost/eventfd_link/eventfd_link.h | 79 ++ lib/librte_vhost/rte_virtio_net.h| 192 + lib/librte_vhost/vhost-net-cdev.c| 363 ++ lib/librte_vhost/vhost-net-cdev.h| 112 +++ lib/librte_vhost/vhost_rxtx.c| 292 lib/librte_vhost/virtio-net.c| 1002 ++ 11 files changed, 2340 insertions(+) create mode 100644 lib/librte_vhost/Makefile create mode 100644 lib/librte_vhost/eventfd_link/Makefile create mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.c create mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.h create mode 100644 lib/librte_vhost/rte_virtio_net.h create mode 100644 lib/librte_vhost/vhost-net-cdev.c create mode 100644 lib/librte_vhost/vhost-net-cdev.h create mode 100644 lib/librte_vhost/vhost_rxtx.c create mode 100644 lib/librte_vhost/virtio-net.c diff --git a/config/common_linuxapp b/config/common_linuxapp index 7bf5d80..5b58278 100644 --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -390,6 +390,13 @@ CONFIG_RTE_KNI_VHOST_DEBUG_RX=n CONFIG_RTE_KNI_VHOST_DEBUG_TX=n # +# Compile vhost library +# fuse, fuse-devel, kernel-modules-extra packages are needed +# +CONFIG_RTE_LIBRTE_VHOST=n +CONFIG_RTE_LIBRTE_VHOST_DEBUG=n + +# #Compile Xen domain0 support # CONFIG_RTE_LIBRTE_XEN_DOM0=n diff --git a/lib/Makefile b/lib/Makefile index 10c5bb3..007c174 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -60,6 +60,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_METER) += librte_meter DIRS-$(CONFIG_RTE_LIBRTE_SCHED) += librte_sched DIRS-$(CONFIG_RTE_LIBRTE_KVARGS) += librte_kvargs DIRS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += librte_distributor +DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost DIRS-$(CONFIG_RTE_LIBRTE_PORT) += librte_port DIRS-$(CONFIG_RTE_LIBRTE_TABLE) += librte_table DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += librte_pipeline diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile new file mode 100644 index 000..f79778b --- /dev/null +++ b/lib/librte_vhost/Makefile @@ -0,0 +1,48 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +include $(RTE_SDK)/mk/rte.vars.mk + +# library name +LIB = librte_vhost.a + +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -D_FILE_OFFSET_BITS=64 -lfuse +LDFLAGS += -lfuse +# all source are stored in SRCS-y +SRCS-$(CONFIG_RTE_LIBRTE_VHOST) := vhost-net-cdev.c virtio-net.c vhost_rxtx.c + +# install includes +SYMLINK-$(CONFIG_RTE_LIBRTE_VHOST)-include += rte_virtio_net.h + +# this lib needs eal +DEPDIRS-$(CONFIG_RTE_LIBRTE_VHOST) += lib/librte_eal lib/librte_mbuf + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_vhost/eventfd_link/Makefile b/lib/librte_vhost/eventfd_link/Makefile new file mode 100644 index 000..5f
[dpdk-dev] About round trip latency with DPDK
Thanks! I have found the problem. It is that I used clock_gettime() to measure the latency. With rte_rdtsc(), the round trip latency is measured to be less than 10 microseconds. Thanks very much, Kai On Thu, Jul 24, 2014 at 8:48 AM, Wodkowski, PawelX < pawelx.wodkowski at intel.com> wrote: > Refer to DPDK getting started guide paragraph 5.4. It might help. > Also it might be easier to do write simple application that send a packet > on port 1 and rx it on port 2 in separate threads on separate cores (simple > physical loop). You can then add timestamp and send packet back and see how > long it will take TX to RX and RX to TX process. > > Pawel Wodkowski > -- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please > contact the sender and delete all copies. > > >
[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
On 25/07/14 10:43, Thomas Monjalon wrote: >> On 24/07/14 07:59, Matthew Hall wrote: >>> I ran into some weird symbol conflicts between system netinet/in.h and DPDK >>> rte_ip.h. They have a lot of duplicated definitions for stuff like >>> IPPROTO_IP >>> and so on. This breaks when you want to use inet_pton from arpa/inet.h, >>> because it includes netinet/in.h to define struct in_addr. > [...] >> Again, I recommend steering away from any tightrope approaches that >> "know" which types are non-conflicting, or pick out half-and-half from >> the host and IP stack. "Do, or do not, there is no half-and-half" > > The general problem here is that DPDK is conflicting with libc. > So the obvious question would be: "why DPDK needs to redefine libc stuff"? > I don't see any obvious answer since bare metal is planned to be removed. > (see http://dpdk.org/ml/archives/dev/2014-June/003868.html) One reason is if you want DPDK to be a portable network programming environment. Especially in that case you do not want definitions based on hackish assumptions of some particular version of some particular host implementation. However, I'm not trying to argue if DPDK should or shouldn't be that, just that you should either dramatically improve the current implementation or nuke it.
[dpdk-dev] Regarding new feature development in dpdk-acl
Hi All, I am trying to add new acl rule support to filter the packets based on TCP flags. I have followed the structure updates as per DPDK Programmers guide. I have attached the code diff along with this mail. Some how packet filtering is not happening with our modifications. Input configuration file used is (Here we are trying to restrict SYN+FIN flag) @20.0.0.0/24 40.0.0.0/24 0 : 65535 0 : 65535 6/0xfe 0x3/0xFF R20.0.0.0/24 40.0.0.0/24 0 : 65535 0 : 65535 6/0xfe 0x0/0x00 1 R40.0.0.0/24 20.0.0.0/24 0 : 65535 0 : 65535 6/0xfe 0x0/0x00 1 Could you please share your thoughts on this problem. Warm Regards, Santhosh Kumar Bendalam, Assistant Consultant, Tata Consultancy Services Limited =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[dpdk-dev] Regarding new feature development in dpdk-acl
Missed the patch. Please find the patch.
diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c
index 9b2c21b..8a5dde8 100644
--- a/examples/l3fwd-acl/main.c
+++ b/examples/l3fwd-acl/main.c
@@ -85,6 +85,8 @@
#define MBUF_SIZE (2048 + sizeof(struct rte_mbuf) + RTE_PKTMBUF_HEADROOM)
+#define L3FWDACL_DEBUG
+
/*
* This expression is used to calculate the number of mbufs needed
* depending on user input, taking into account memory for rx and tx hardware
@@ -135,6 +137,16 @@
static uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT;
static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
+/* TCP header flags */
+#define TCPHDR_FIN 0x01
+#define TCPHDR_SYN 0x02
+#define TCPHDR_RST 0x04
+#define TCPHDR_PSH 0x08
+#define TCPHDR_ACK 0x10
+#define TCPHDR_URG 0x20
+#define TCPHDR_ECE 0x40
+#define TCPHDR_CWR 0x80
+
/* ethernet addresses of ports */
static struct ether_addr ports_eth_addr[RTE_MAX_ETHPORTS];
@@ -314,6 +326,7 @@ enum {
DST_FIELD_IPV4,
SRCP_FIELD_IPV4,
DSTP_FIELD_IPV4,
+PROTO_FIELD_FLAGS,
NUM_FIELDS_IPV4
};
@@ -358,6 +371,15 @@ struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
offsetof(struct ipv4_hdr, next_proto_id) +
sizeof(uint16_t),
},
+{
+.type = RTE_ACL_FIELD_TYPE_BITMASK,
+.size = sizeof(uint8_t),
+.field_index = PROTO_FIELD_FLAGS,
+.input_index = RTE_ACL_IPV4VLAN_PROTO_FLAGS,
+.offset = sizeof(struct ipv4_hdr) - offsetof(struct ipv4_hdr,
next_proto_id)
++ sizeof(uint16_t) + sizeof(uint16_t) + sizeof
(uint32_t)
++ sizeof (uint32_t) + sizeof(uint8_t),
+},
};
#define IPV6_ADDR_LEN 16
@@ -376,6 +398,7 @@ enum {
DST4_FIELD_IPV6,
SRCP_FIELD_IPV6,
DSTP_FIELD_IPV6,
+ PROTO_FIELD_FLAGS_IPV6,
NUM_FIELDS_IPV6
};
@@ -467,6 +490,15 @@ struct rte_acl_field_def ipv6_defs[NUM_FIELDS_IPV6] = {
.offset = sizeof(struct ipv6_hdr) -
offsetof(struct ipv6_hdr, proto) + sizeof(uint16_t),
},
+{
+.type = RTE_ACL_FIELD_TYPE_BITMASK,
+.size = sizeof(uint8_t),
+.field_index = PROTO_FIELD_FLAGS_IPV6,
+.input_index = PROTO_FIELD_FLAGS_IPV6,
+.offset = sizeof(struct ipv6_hdr) - offsetof(struct ipv6_hdr,
proto)
+ + sizeof(uint16_t) + sizeof(uint16_t) + sizeof (uint32_t)
++ sizeof (uint32_t) + sizeof(uint8_t),
+},
};
enum {
@@ -479,6 +511,7 @@ enum {
CB_FLD_DST_PORT_DLM,
CB_FLD_DST_PORT_HIGH,
CB_FLD_PROTO,
+CB_FLD_PROTO_FLAGS,
CB_FLD_USERDATA,
CB_FLD_NUM,
};
@@ -536,6 +569,8 @@ print_one_ipv4_rule(struct acl4_rule *rule, int extra)
rule->field[DSTP_FIELD_IPV4].mask_range.u16,
rule->field[PROTO_FIELD_IPV4].value.u8,
rule->field[PROTO_FIELD_IPV4].mask_range.u8);
+
+printf(" Proto flags: %hu ", rule->field[PROTO_FIELD_FLAGS].value.u8);
if (extra)
printf("0x%x-0x%x-0x%x ",
rule->data.category_mask,
@@ -589,6 +624,9 @@ print_one_ipv6_rule(struct acl6_rule *rule, int extra)
rule->field[DSTP_FIELD_IPV6].mask_range.u16,
rule->field[PROTO_FIELD_IPV6].value.u8,
rule->field[PROTO_FIELD_IPV6].mask_range.u8);
+
+printf(" Proto flags: %hu ", rule->field[PROTO_FIELD_FLAGS].value.u8);
+
if (extra)
printf("0x%x-0x%x-0x%x ",
rule->data.category_mask,
@@ -700,14 +738,19 @@ prepare_one_packet(struct rte_mbuf **pkts_in, struct
acl_search_t *acl,
{
struct ipv4_hdr *ipv4_hdr;
struct rte_mbuf *pkt = pkts_in[index];
-
+struct tcp_hdr *tcp_hdr;
int type = pkt->ol_flags & (PKT_RX_IPV4_HDR | PKT_RX_IPV6_HDR);
-
- if (type == PKT_RX_IPV4_HDR) {
+printf ("\n bendalam pkt->ol_flags: %d\n", pkt->ol_flags);
+printf("\n From prepare_one_packet -1\n");
+ //if (type == PKT_RX_IPV4_HDR) {
+ if (1) {
ipv4_hdr = (struct ipv4_hdr *)(rte_pktmbuf_mtod(pkt,
unsigned char *) + sizeof(struct ether_hdr));
+tcp_hdr = (struct tcp_hdr *)(rte_pktmbuf_mtod(pkt, unsigned
char *) +
+ sizeof(struct ether_hdr) + sizeof(struct
ipv4_hdr));
+
/* Check to make sure the packet is valid (RFC1812) */
if (is_valid_ipv4_pkt(ipv4_hdr, pkt->pkt.pkt_len) >= 0) {
@@ -715,10 +758,28 @@ prepare_one_packet(struct rte_mbuf **pkts_in, struct
acl_search_t *acl,
--(ipv4_hdr->time_to_live);
++(ipv4_hdr->hdr_checksum);
+printf("\n From prepare_one_packet -2\n");
+#if 0
+if(tcp_hdr->tcp_flags & TCPHDR_SYN)
+{
+
+ printf("\n tcp Flag is SYN: %x
\n",tcp_hdr->tcp_flags);
+rte_pktmbuf_free(pkt);
+return;
+}
+else
+{
+ printf("\n other tcp Flags are %x
\n",tcp_hdr->tcp_flags);
+
+}
+#endif
/* Fill acl structure */
acl->data_ipv4[acl->num_ipv4] = MBUF_IPV4_2PROTO(pkt);
[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
If the bare metal mode is getting yanked, then I think we can go with Antti's advice and just yank the conflicting symbols and use the system versions. -- Sent from my mobile device. On July 25, 2014 7:40:02 AM PDT, Antti Kantee wrote: >On 25/07/14 10:43, Thomas Monjalon wrote: >>> On 24/07/14 07:59, Matthew Hall wrote: I ran into some weird symbol conflicts between system netinet/in.h >and DPDK rte_ip.h. They have a lot of duplicated definitions for stuff like >IPPROTO_IP and so on. This breaks when you want to use inet_pton from >arpa/inet.h, because it includes netinet/in.h to define struct in_addr. >> [...] >>> Again, I recommend steering away from any tightrope approaches that >>> "know" which types are non-conflicting, or pick out half-and-half >from >>> the host and IP stack. "Do, or do not, there is no half-and-half" >> >> The general problem here is that DPDK is conflicting with libc. >> So the obvious question would be: "why DPDK needs to redefine libc >stuff"? >> I don't see any obvious answer since bare metal is planned to be >removed. >> (see http://dpdk.org/ml/archives/dev/2014-June/003868.html) > >One reason is if you want DPDK to be a portable network programming >environment. Especially in that case you do not want definitions based > >on hackish assumptions of some particular version of some particular >host implementation. However, I'm not trying to argue if DPDK should >or >shouldn't be that, just that you should either dramatically improve the > >current implementation or nuke it.
[dpdk-dev] [igb_uio PATCH 0/3] igb_uio: fixed typos and pci lock/unlock calls
On Thu, 24 Jul 2014 23:50:43 +0200 Thomas Monjalon wrote: > 2014-07-22 15:07, Thomas Monjalon: > > The compilation with old kernels should be fixed now. > > If some distributions have backported the new PCI config locking functions, > > the compilation may fail. Please report such errors. > > Compilation with RHEL6 is broken because of some backported functions, > some unknown MSIX values and some MSI functions missing. > > include/linux/pci.h:1572: note: previous declaration of ?pci_num_vf? was here > include/linux/pci.h:868: note: previous declaration of > ?pci_intx_mask_supported? was here > include/linux/pci.h:869: note: previous declaration of > ?pci_check_and_mask_intx? was here > igb_uio.c:294: error: ?PCI_MSIX_ENTRY_SIZE? undeclared (first use in this > function) > igb_uio.c:295: error: ?PCI_MSIX_ENTRY_VECTOR_CTRL? undeclared (first use in > this function) > igb_uio.c:298: error: ?PCI_MSIX_ENTRY_CTRL_MASKBIT? undeclared (first use in > this function) > igb_uio.c:312: error: implicit declaration of function ?irq_data_get_msi? > igb_uio.c:350: error: implicit declaration of function ?irq_get_irq_data? > > If someone has time to fix it, patch is welcome. > > Thanks I will fix for Debian Squeeze, don't do RHEL
[dpdk-dev] [PATCH 1/2] igb_uio: fix compability on old kernel
Add more compatibility wrappers, and split out all the wrapper
code to a separate file. Builds on Debian Squeeze (2.6.32) which
is oldest version of kernel current DPDK supports.
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/linuxapp/igb_uio/compat.h | 103 ++
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 81 ---
2 files changed, 104 insertions(+), 80 deletions(-)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ b/lib/librte_eal/linuxapp/igb_uio/compat.h 2014-07-25 10:29:58.664127988
-0700
@@ -0,0 +1,103 @@
+/*
+ * Minimal wrappers to allow compiling igb_uio on older kernels.
+ */
+
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 3, 0)
+#define pci_cfg_access_lock pci_block_user_cfg_access
+#define pci_cfg_access_unlock pci_unblock_user_cfg_access
+#endif
+
+#ifndef PCI_MSIX_ENTRY_SIZE
+#define PCI_MSIX_ENTRY_SIZE 16
+#define PCI_MSIX_ENTRY_LOWER_ADDR 0
+#define PCI_MSIX_ENTRY_UPPER_ADDR 4
+#define PCI_MSIX_ENTRY_DATA8
+#define PCI_MSIX_ENTRY_VECTOR_CTRL 12
+#define PCI_MSIX_ENTRY_CTRL_MASKBIT 1
+#endif
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34)
+static int pci_num_vf(struct pci_dev *dev)
+{
+ struct iov {
+ int pos;
+ int nres;
+ u32 cap;
+ u16 ctrl;
+ u16 total;
+ u16 initial;
+ u16 nr_virtfn;
+ } *iov = (struct iov *)dev->sriov;
+
+ if (!dev->is_physfn)
+ return 0;
+
+ return iov->nr_virtfn;
+}
+#endif
+
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 3, 0)
+
+/* Check if INTX works to control irq's.
+ * Set's INTX_DISABLE flag and reads it back
+ */
+static bool pci_intx_mask_supported(struct pci_dev *pdev)
+{
+ bool mask_supported = false;
+ uint16_t orig, new;
+
+ pci_block_user_cfg_access(pdev);
+ pci_read_config_word(pdev, PCI_COMMAND, &orig);
+ pci_write_config_word(pdev, PCI_COMMAND,
+ orig ^ PCI_COMMAND_INTX_DISABLE);
+ pci_read_config_word(pdev, PCI_COMMAND, &new);
+
+ if ((new ^ orig) & ~PCI_COMMAND_INTX_DISABLE) {
+ dev_err(&pdev->dev, "Command register changed from "
+ "0x%x to 0x%x: driver or hardware bug?\n", orig, new);
+ } else if ((new ^ orig) & PCI_COMMAND_INTX_DISABLE) {
+ mask_supported = true;
+ pci_write_config_word(pdev, PCI_COMMAND, orig);
+ }
+ pci_unblock_user_cfg_access(pdev);
+
+ return mask_supported;
+}
+
+static bool pci_check_and_mask_intx(struct pci_dev *pdev)
+{
+ bool pending;
+ uint32_t status;
+
+ pci_block_user_cfg_access(pdev);
+ pci_read_config_dword(pdev, PCI_COMMAND, &status);
+
+ /* interrupt is not ours, goes to out */
+ pending = (((status >> 16) & PCI_STATUS_INTERRUPT) != 0);
+ if (pending) {
+ uint16_t old, new;
+
+ old = status;
+ if (status != 0)
+ new = old & (~PCI_COMMAND_INTX_DISABLE);
+ else
+ new = old | PCI_COMMAND_INTX_DISABLE;
+
+ if (old != new)
+ pci_write_config_word(pdev, PCI_COMMAND, new);
+ }
+ pci_unblock_user_cfg_access(pdev);
+
+ return pending;
+}
+#endif
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 37)
+/* Compatability wrapper for new kernel API for IRQ */
+#define irq_data irq_desc
+#define irq_get_irq_data(irq) irq_to_desc(irq)
+#define irq_data_get_msi(data) get_irq_desc_msi(data)
+#endif
+
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c 2014-07-25 10:29:58.668128002
-0700
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c 2014-07-25 10:29:58.664127988
-0700
@@ -37,10 +37,7 @@
#endif
#include
-#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 3, 0)
-#define pci_cfg_access_lock pci_block_user_cfg_access
-#define pci_cfg_access_unlock pci_unblock_user_cfg_access
-#endif
+#include "compat.h"
#ifdef RTE_PCI_CONFIG
#define PCI_SYS_FILE_BUF_SIZE 10
@@ -70,26 +67,6 @@ igbuio_get_uio_pci_dev(struct uio_info *
}
/* sriov sysfs */
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34)
-static int pci_num_vf(struct pci_dev *dev)
-{
- struct iov {
- int pos;
- int nres;
- u32 cap;
- u16 ctrl;
- u16 total;
- u16 initial;
- u16 nr_virtfn;
- } *iov = (struct iov *)dev->sriov;
-
- if (!dev->is_physfn)
- return 0;
-
- return iov->nr_virtfn;
-}
-#endif
-
static ssize_t
show_max_vfs(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -228,62 +205,6 @@ static struct attribute *dev_attrs[] = {
static const struct attribute_group dev_attr_grp = {
.attrs = dev_attrs,
};
-
-#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 3, 0)
-/* Check if INTX works to control irq's.
- *
[dpdk-dev] [PATCH 2/2] igb_uio: handle no IRQ fallback
Fix a couple of issues with my earlier igb_uio stuff:
1. With MSI (like MSI-X) actual IRQ number is not known until
after the pci_enable_msi() is done.
2. If INTX fails, fall back to running without IRQ.
This allows usermode PCI to recover and run without out IRQ
for cases where PCI INTX support is broken (aka VMWare).
Signed-off-by: Stephen Hemminger
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c 2014-07-25 10:30:07.740159856
-0700
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c 2014-07-25 10:30:07.736159842
-0700
@@ -506,7 +506,6 @@ igbuio_pci_probe(struct pci_dev *dev, co
udev->info.version = "0.1";
udev->info.handler = igbuio_pci_irqhandler;
udev->info.irqcontrol = igbuio_pci_irqcontrol;
- udev->info.irq = dev->irq;
#ifdef CONFIG_XEN_DOM0
/* check if the driver run on Xen Dom0 */
if (xen_initial_domain())
@@ -516,9 +515,6 @@ igbuio_pci_probe(struct pci_dev *dev, co
udev->pdev = dev;
switch (igbuio_intr_mode_preferred) {
- case RTE_INTR_MODE_NONE:
- udev->info.irq = 0;
- break;
case RTE_INTR_MODE_MSIX:
/* Only 1 msi-x vector needed */
msix_entry.entry = 0;
@@ -532,6 +528,7 @@ igbuio_pci_probe(struct pci_dev *dev, co
case RTE_INTR_MODE_MSI:
if (pci_enable_msi(dev) == 0) {
dev_dbg(&dev->dev, "using MSI");
+ udev->info.irq = dev->irq;
udev->mode = RTE_INTR_MODE_MSI;
break;
}
@@ -540,13 +537,17 @@ igbuio_pci_probe(struct pci_dev *dev, co
if (pci_intx_mask_supported(dev)) {
dev_dbg(&dev->dev, "using INTX");
udev->info.irq_flags = IRQF_SHARED;
+ udev->info.irq = dev->irq;
udev->mode = RTE_INTR_MODE_LEGACY;
- } else {
- dev_err(&dev->dev, "PCI INTX mask not supported\n");
- err = -EIO;
- goto fail_release_iomem;
+ break;
}
+ dev_notice(&dev->dev, "PCI INTX mask not supported\n");
+ /* fall back to no IRQ */
+ case RTE_INTR_MODE_NONE:
+ udev->mode = RTE_INTR_MODE_NONE;
+ udev->info.irq = 0;
break;
+
default:
dev_err(&dev->dev, "invalid IRQ mode %u",
igbuio_intr_mode_preferred);
[dpdk-dev] [PATCH] vmxnet3: initialize receive mode correctly
The driver must listen to broadcast packets, like other devices. Otherwise protocols like ARP won't work! Signed-off-by: Stephen Hemminger --- a/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c 2014-07-25 10:49:18.720201127 -0700 +++ b/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c 2014-07-25 10:49:18.720201127 -0700 @@ -522,7 +522,7 @@ vmxnet3_dev_start(struct rte_eth_dev *de } /* Setting proper Rx Mode and issue Rx Mode Update command */ - vmxnet3_dev_set_rxmode(hw, VMXNET3_RXM_UCAST | VMXNET3_RXM_ALL_MULTI, 1); + vmxnet3_dev_set_rxmode(hw, VMXNET3_RXM_UCAST | VMXNET3_RXM_BCAST, 1); /* * Don't need to handle events for now
