[dpdk-dev] dpdk_nic_bind giving error
I?m running on centos with kernel 3.18.3 and built the dpdk with gcc 4.7 and running with python 3.3 When trying to get status or even trying to bind to the eth0 port, I get the following error : [root at linux-dt dpdk-1.8.0]# tools/dpdk_nic_bind.py --status Traceback (most recent call last): File "tools/dpdk_nic_bind.py", line 536, in main() File "tools/dpdk_nic_bind.py", line 532, in main get_nic_details() File "tools/dpdk_nic_bind.py", line 225, in get_nic_details dev_lines = check_output(["lspci", "-Dvmmn"]).splitlines() File "tools/dpdk_nic_bind.py", line 120, in check_output stderr=stderr).communicate()[0] File "/usr/lib64/python2.6/subprocess.py", line 642, in __init__ errread, errwrite) File "/usr/lib64/python2.6/subprocess.py", line 1234, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory What am I doing wrong? This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Thank you in advance for your cooperation.
[dpdk-dev] dpdk_nic_bind giving error
On Fri, Jan 23, 2015 at 10:26:34PM +, Vipin Agrawal wrote: > I?m running on centos with kernel 3.18.3 and built the dpdk with gcc 4.7 and > running with python 3.3 > > When trying to get status or even trying to bind to the eth0 port, I get the > following error : > > [root at linux-dt dpdk-1.8.0]# tools/dpdk_nic_bind.py --status > Traceback (most recent call last): > File "tools/dpdk_nic_bind.py", line 536, in > main() > File "tools/dpdk_nic_bind.py", line 532, in main > get_nic_details() > File "tools/dpdk_nic_bind.py", line 225, in get_nic_details > dev_lines = check_output(["lspci", "-Dvmmn"]).splitlines() > File "tools/dpdk_nic_bind.py", line 120, in check_output > stderr=stderr).communicate()[0] > File "/usr/lib64/python2.6/subprocess.py", line 642, in __init__ > errread, errwrite) > File "/usr/lib64/python2.6/subprocess.py", line 1234, in _execute_child > raise child_exception > OSError: [Errno 2] No such file or directory > > > What am I doing wrong? > > Looks like you don't have pci-utils installed. The script can't find the lspci utility Neil > > > > This message is for the designated recipient only and may contain privileged, > proprietary, or otherwise confidential information. If you have received it > in error, please notify the sender immediately and delete the original. Any > other use of the e-mail by you is prohibited. Thank you in advance for your > cooperation. > >
[dpdk-dev] which 40G card support DPDK or DPDK 2.0
Hello: I am sorry if this question has been asked before, or this is not right list to ask, I searched the list archive, did not see any answer. Any one can share information about which Mellanox 40G NIC on the mark can/will support DPDK or DPDK 2.0? The DPDK supported NIC page only list mlx4 (ConnectX-3, ConnectX-3 Pro)? we are in the process to acquire hardware to start DPDK related projects. Thanks Jim Chen iCAIR/Northwestern University
[dpdk-dev] [RFC 09/16] testpmd: move csum_show in a function
Hi Jijiang,
On 01/23/2015 12:03 PM, Liu, Jijiang wrote:
> + /* display warnings if configuration is not supported by the NIC */
> + rte_eth_dev_info_get(port_id, _info);
> + if ((ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM) &&
> + (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_IPV4_CKSUM) == 0) {
> + printf("Warning: hardware IP checksum enabled but not "
> + "supported by port %d\n", port_id);
> + }
> + if ((ol_flags & TESTPMD_TX_OFFLOAD_UDP_CKSUM) &&
> + (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_UDP_CKSUM) == 0) {
> + printf("Warning: hardware UDP checksum enabled but not "
> + "supported by port %d\n", port_id);
> + }
> + if ((ol_flags & TESTPMD_TX_OFFLOAD_TCP_CKSUM) &&
> + (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_CKSUM) == 0) {
> + printf("Warning: hardware TCP checksum enabled but not "
> + "supported by port %d\n", port_id);
> + }
> + if ((ol_flags & TESTPMD_TX_OFFLOAD_SCTP_CKSUM) &&
> + (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_SCTP_CKSUM) == 0) {
> + printf("Warning: hardware SCTP checksum enabled but not "
> + "supported by port %d\n", port_id);
> + }
>
> The ESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM check is missed here.
Yes, it should be added in this patch:
ethdev: add outer IP offload capability flag
I'll do it for the next version.
Regards,
Olivier
[dpdk-dev] [RFC 11/16] testpmd: rename vxlan in outer_ip in csum commands
Hi Jijiang,
On 01/23/2015 12:21 PM, Liu, Jijiang wrote:
>> static void
>> pkt_burst_checksum_forward(struct fwd_stream *fs) @@ -432,18 +435,18 @@
>> pkt_burst_checksum_forward(struct fwd_stream *fs)
>> /* step 4: fill the mbuf meta data (flags and header lengths) */
>>
>> if (tunnel == 1) {
>> -if (testpmd_ol_flags &
>> TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) {
>> +if (testpmd_ol_flags &
>> TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM) {
>> m->outer_l2_len = outer_l2_len;
>> m->outer_l3_len = outer_l3_len;
>> m->l2_len = l4_tun_len + l2_len;
>> m->l3_len = l3_len;
>
> There should be m->l4_len = l4_len here.
Right, thank you for reporting it.
I'll fix that (but not in this patch which is just a renaming
of another part of the code).
Regards,
Olivier
[dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user support
>> >> Can you mmap the region if gpa is 0? When i run VM with two numa node (qemu >> will create two hugepage file) found that always failed to mmap with the >> region >> which gpa is 0. >> >> BTW can we ensure the memory regions cover with all the memory of hugepage >> for VM? >> > We had discussed this. Seemed a qemu bug. > Do you have update on this? > Yes,because qemu not send all hugepage file fd to vhost-user.I have send the patch bug no body reply. > > Thanks Haifeng for your comments. > Next time, could you help cut the code not commented? > They are too long. It is really hard for me to find your comment. > > > . > OK:) -- Regards, Haifeng
[dpdk-dev] [PATCH RFC v2 00/12] lib/librte_vhost: vhost-user support
Hi, Xie could you test vhost-user with follow numa node xml: 2097152 I cann't receive data from VM with above xml. On 2014/12/11 5:37, Huawei Xie wrote: > This patchset refines vhost library to support both vhost-cuse and vhost-user. > > > Huawei Xie (12): > create vhost_cuse directory and move vhost-net-cdev.c to vhost_cuse > directory > rename vhost-net-cdev.h as vhost-net.h > move eventfd_copy logic out from virtio-net.c to vhost-net-cdev.c > exact copy of host_memory_map from virtio-net.c to new file > virtio-net-cdev.c > host_memory_map refine: map partial memory of target process into current > process > cuse_set_memory_table is the VHOST_SET_MEMORY_TABLE message handler for cuse > fd management for vhost user > vhost-user support > minor fix > vhost-user memory region map/unmap > kick/callfd fix > cleanup when vhost user connection is closed > > lib/librte_vhost/Makefile | 5 +- > lib/librte_vhost/rte_virtio_net.h | 2 + > lib/librte_vhost/vhost-net-cdev.c | 389 -- > lib/librte_vhost/vhost-net-cdev.h | 113 --- > lib/librte_vhost/vhost-net.h | 117 +++ > lib/librte_vhost/vhost_cuse/vhost-net-cdev.c | 452 > ++ > lib/librte_vhost/vhost_cuse/virtio-net-cdev.c | 349 > lib/librte_vhost/vhost_cuse/virtio-net-cdev.h | 45 +++ > lib/librte_vhost/vhost_rxtx.c | 2 +- > lib/librte_vhost/vhost_user/fd_man.c | 205 > lib/librte_vhost/vhost_user/fd_man.h | 64 > lib/librte_vhost/vhost_user/vhost-net-user.c | 423 > lib/librte_vhost/vhost_user/vhost-net-user.h | 107 ++ > lib/librte_vhost/vhost_user/virtio-net-user.c | 313 ++ > lib/librte_vhost/vhost_user/virtio-net-user.h | 49 +++ > lib/librte_vhost/virtio-net.c | 394 ++ > lib/librte_vhost/virtio-net.h | 43 +++ > 17 files changed, 2199 insertions(+), 873 deletions(-) > delete mode 100644 lib/librte_vhost/vhost-net-cdev.c > delete mode 100644 lib/librte_vhost/vhost-net-cdev.h > create mode 100644 lib/librte_vhost/vhost-net.h > create mode 100644 lib/librte_vhost/vhost_cuse/vhost-net-cdev.c > create mode 100644 lib/librte_vhost/vhost_cuse/virtio-net-cdev.c > create mode 100644 lib/librte_vhost/vhost_cuse/virtio-net-cdev.h > create mode 100644 lib/librte_vhost/vhost_user/fd_man.c > create mode 100644 lib/librte_vhost/vhost_user/fd_man.h > create mode 100644 lib/librte_vhost/vhost_user/vhost-net-user.c > create mode 100644 lib/librte_vhost/vhost_user/vhost-net-user.h > create mode 100644 lib/librte_vhost/vhost_user/virtio-net-user.c > create mode 100644 lib/librte_vhost/vhost_user/virtio-net-user.h > create mode 100644 lib/librte_vhost/virtio-net.h > -- Regards, Haifeng
[dpdk-dev] Segmentation fault in ixgbe_rxtx_vec.c:444 with 1.8.0
Hi Bruce,
yes, you are absolutely right. That resolves the problem.
I was really happy to see that DPDK 1.8 includes proper default
configurations for each driver and I made use of this. But unfortunately
I was not aware that the default configuration did include the
ETH_TXQ_FLAGS_NOMULTSEGS flag for ixgbe and i40e.
I now use rte_eth_dev_info_get to get the default config for the port
and then modify the txq_flags to not not include ETH_TXQ_FLAGS_NOMULTSEGS.
With your fix this now works for CONFIG_RTE_IXGBE_INC_VECTOR=y, too.
Sorry for missing this and thanks for the quick help.
Best regards,
Martin
On 23.01.15 12:52, Bruce Richardson wrote:
> On Fri, Jan 23, 2015 at 12:37:09PM +0100, Martin Weiser wrote:
>> Hi Bruce,
>>
>> I now had the chance to reproduce the issue we are seeing with a DPDK
>> example app.
>> I started out with a vanilla DPDK 1.8.0 and only made the following changes:
>>
>> diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
>> index e684234..48e6b7c 100644
>> --- a/examples/l2fwd/main.c
>> +++ b/examples/l2fwd/main.c
>> @@ -118,8 +118,9 @@ static const struct rte_eth_conf port_conf = {
>> .header_split = 0, /**< Header Split disabled */
>> .hw_ip_checksum = 0, /**< IP checksum offload disabled */
>> .hw_vlan_filter = 0, /**< VLAN filtering disabled */
>> - .jumbo_frame= 0, /**< Jumbo Frame Support disabled */
>> + .jumbo_frame= 1, /**< Jumbo Frame Support disabled */
>> .hw_strip_crc = 0, /**< CRC stripped by hardware */
>> + .max_rx_pkt_len = 9000,
>> },
>> .txmode = {
>> .mq_mode = ETH_MQ_TX_NONE,
>> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
>> b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
>> index b54cb19..dfaccee 100644
>> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
>> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
>> @@ -402,10 +402,10 @@ reassemble_packets(struct igb_rx_queue *rxq,
>> struct rte_mbuf **rx_bufs,
>> struct rte_mbuf *pkts[RTE_IXGBE_VPMD_RX_BURST]; /*finished pkts*/
>> struct rte_mbuf *start = rxq->pkt_first_seg;
>> struct rte_mbuf *end = rxq->pkt_last_seg;
>> - unsigned pkt_idx = 0, buf_idx = 0;
>> + unsigned pkt_idx, buf_idx;
>>
>>
>> - while (buf_idx < nb_bufs) {
>> + for (buf_idx = 0, pkt_idx = 0; buf_idx < nb_bufs; buf_idx++) {
>> if (end != NULL) {
>> /* processing a split packet */
>> end->next = rx_bufs[buf_idx];
>> @@ -448,7 +448,6 @@ reassemble_packets(struct igb_rx_queue *rxq, struct
>> rte_mbuf **rx_bufs,
>> rx_bufs[buf_idx]->data_len += rxq->crc_len;
>> rx_bufs[buf_idx]->pkt_len += rxq->crc_len;
>> }
>> - buf_idx++;
>> }
>>
>> /* save the partial packet for next time */
>>
>>
>> This includes your previously posted fix and makes a small modification
>> to the l2fwd example app to enable jumbo frames of up to 9000 bytes.
>> The system is equipped with a two port Intel 82599 card and both ports
>> are hooked up to a packet generator. The packet generator produces
>> simple Ethernet/IPv4/UDP packets.
>> I started the l2fwd app with the following command line:
>>
>> $ ./build/l2fwd -c f -n 4 -- -q 8 -p 3
>>
>> Both build variants that I have tested (CONFIG_RTE_IXGBE_INC_VECTOR=y
>> and CONFIG_RTE_IXGBE_INC_VECTOR=n) now give me the same result:
>> As long as the packet size is <= 2048 bytes the application behaves
>> normally and all packets are forwarded as expected.
>> As soon as the packet size exceeds 2048 bytes the application will only
>> forward some packets and then stop forwarding altogether. Even small
>> packets will not be forwarded anymore.
>>
>> If you want me to try out anything else just let me know.
>>
>>
>> Best regards,
>> Martin
>>
> I think the txq flags are at fault here. The default txq flags setting for
> the l2fwd sample application includes the flag ETH_TXQ_FLAGS_NOMULTSEGS which
> disables support for sending packets with multiple segments i.e. jumbo frames
> in this case. If you change l2fwd to explicitly pass a txqflags parameter in
> as part of the port setup (as was the case in previous releases), and set
> txqflags
> to 0, does the problem go away?
>
> /Bruce
>
>>
>> On 21.01.15 14:49, Bruce Richardson wrote:
>>> On Tue, Jan 20, 2015 at 11:39:03AM +0100, Martin Weiser wrote:
Hi again,
I did some further testing and it seems like this issue is linked to
jumbo frames. I think a similar issue has already been reported by
Prashant Upadhyaya with the subject 'Packet Rx issue with DPDK1.8'.
In our application we use the following rxmode port configuration:
.mq_mode= ETH_MQ_RX_RSS,
.split_hdr_size = 0,
.header_split = 0,
.hw_ip_checksum = 1,
.hw_vlan_filter = 0,
.jumbo_frame= 1,
[dpdk-dev] [PATCH] maintainers: start a Linux-style file
2015-01-23 09:18, Neil Horman: > One question, the security issues list, is that active already and in use? It is "in use" since the beginning of dpdk.org. But traffic is very very low. > Can we document the membership of that list so we know who's handling security > issues? Only me but you are welcome: http://dpdk.org/ml/listinfo/maintainers -- Thomas
[dpdk-dev] DPDK & BPF
Hello, I would like your opinion. I try to fill a "little" 1 Gbps link. In my testing environment, I have no smart card able to parse the headers for me. So by design, i am slow. But fast enough for that link. But, is it easy to put a filter like BPF on top of DPDK ? I am not sure where to start to make this happen. In my understanding, bpf will read the nic's raw packets and apply the filters and let them flow to the socket. That avoids copy to the socket and should increase overall performance. Where to put dpdk ? right after the filtering, but how to coordinate them ? This is the point I miss. Even better, maybe DPDK has a filtering feature (not seen in the doc)? Thanks
[dpdk-dev] [PATCH] maintainers: start a Linux-style file
This MAINTAINERS file is inspired from the Linux one. Almost all files are split into areas in order to identify maintainers of each DPDK area. Note that a maintainer is not a git tree manager. Candidates are welcome to send a patch to sign up for one or several areas. There is a script to check covering, especially when adding or moving files. Signed-off-by: Thomas Monjalon --- MAINTAINERS | 388 +++ scripts/check-maintainers.sh | 85 ++ 2 files changed, 473 insertions(+) create mode 100644 MAINTAINERS create mode 100755 scripts/check-maintainers.sh diff --git a/MAINTAINERS b/MAINTAINERS new file mode 100644 index 000..1f7d04a --- /dev/null +++ b/MAINTAINERS @@ -0,0 +1,388 @@ +DPDK Maintainers + + +The intention of this file is to provide a set of names that we can rely on +for helping in patch reviews and questions. +These names are additional recipients for emails sent to dev at dpdk.org. +Please avoid private emails. + +Descriptions of section entries: + + M: Maintainer's Full Name + T: Git tree location. + F: Files and directories with wildcard patterns. + A trailing slash includes all files and subdirectory files. + A wildcard includes all files but not subdirectories. + One pattern per line. Multiple F: lines acceptable. + X: Files and directories exclusion, same rules as F: + K: Keyword regex pattern to match content. + One regex pattern per line. Multiple K: lines acceptable. + + +General Project Administration +-- +M: Thomas Monjalon +T: git://dpdk.org/dpdk +F: MAINTAINERS +F: scripts/check-maintainers.sh + + +Security Issues +--- +M: maintainers at dpdk.org + + +Documentation (with overlaps) +- +F: doc/ + + +Build System + +F: GNUmakefile +F: Makefile +F: config/ +F: mk/ +F: pkg/ +F: scripts/depdirs-rule.sh +F: scripts/gen-build-mk.sh +F: scripts/gen-config-h.sh +F: scripts/relpath.sh + + +Environment Abstraction Layer +- + +EAL API and common code +M: Thomas Monjalon +F: lib/librte_eal/common/* +F: lib/librte_eal/common/include/* +F: lib/librte_eal/common/include/generic/ +F: app/test/test_alarm.c +F: app/test/test_atomic.c +F: app/test/test_byteorder.c +F: app/test/test_common.c +F: app/test/test_cpuflags.c +F: app/test/test_cycles.c +F: app/test/test_debug.c +F: app/test/test_devargs.c +F: app/test/test_eal* +F: app/test/test_errno.c +F: app/test/test_func_reentrancy.c +F: app/test/test_interrupts.c +F: app/test/test_logs.c +F: app/test/test_memcpy* +F: app/test/test_memory.c +F: app/test/test_memzone.c +F: app/test/test_pci.c +F: app/test/test_per_lcore.c +F: app/test/test_prefetch.c +F: app/test/test_rwlock.c +F: app/test/test_spinlock.c +F: app/test/test_string_fns.c +F: app/test/test_tailq.c +F: app/test/test_version.c + +Secondary process +K: RTE_PROC_ +F: doc/guides/prog_guide/multi_proc_support.rst +F: app/test/test_mp_secondary.c +F: examples/multi_process/ +F: doc/guides/sample_app_ug/multi_process.rst + +IBM Power +F: lib/librte_eal/common/include/arch/ppc_64/ + +Intel x86 +F: lib/librte_eal/common/include/arch/x86/ + +Linux EAL (with overlaps) +F: lib/librte_eal/linuxapp/Makefile +F: lib/librte_eal/linuxapp/eal/ +F: doc/guides/linux_gsg/ + +Linux UIO +F: lib/librte_eal/linuxapp/igb_uio/ +F: lib/librte_eal/linuxapp/eal/*uio* + +Linux VFIO +F: lib/librte_eal/linuxapp/eal/*vfio* + +Linux Xen +F: lib/librte_eal/linuxapp/xen_dom0/ +F: lib/librte_eal/linuxapp/eal/*xen* +F: lib/librte_eal/linuxapp/eal/include/exec-env/rte_dom0_common.h +F: lib/librte_mempool/rte_dom0_mempool.c +F: lib/librte_pmd_xenvirt/ +F: app/test-pmd/mempool_* +F: examples/vhost_xen/ +F: doc/guides/prog_guide/intel_dpdk_xen_based_packet_switch_sol.rst + +FreeBSD EAL (with overlaps) +F: lib/librte_eal/bsdapp/Makefile +F: lib/librte_eal/bsdapp/eal/ +F: doc/guides/freebsd_gsg/ + +FreeBSD contigmem +F: lib/librte_eal/bsdapp/contigmem/ + +FreeBSD UIO +F: lib/librte_eal/bsdapp/nic_uio/ + + +Core Libraries +-- + +Memory management +F: lib/librte_malloc/ +F: doc/guides/prog_guide/malloc_lib.rst +F: app/test/test_malloc.c +F: lib/librte_mempool/ +F: doc/guides/prog_guide/mempool_lib.rst +F: app/test/test_mempool* +F: app/test/test_func_reentrancy.c + +Ring queue +F: lib/librte_ring/ +F: app/test/test_ring* +F: app/test/test_func_reentrancy.c + +Packet buffer +F: lib/librte_mbuf/ +F: doc/guides/prog_guide/mbuf_lib.rst +F: app/test/test_mbuf.c + +Ethernet API +M: Thomas Monjalon +F: lib/librte_ether/ + + +Drivers +--- + +Link bonding +F: lib/librte_pmd_bond/ +F: doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst +F: app/test/test_link_bonding.c + +Linux KNI +F: lib/librte_eal/linuxapp/kni/ +F: lib/librte_kni/ +F: doc/guides/prog_guide/kernel_nic_interface.rst +F: app/test/test_kni.c +F: examples/kni/ +F: doc/guides/sample_app_ug/kernel_nic_interface.rst +
[dpdk-dev] [PATCH 3/3] lib/eal:igb_uio driver change
Replace the CONFIG_XEN_DOM0 with the CONFIG_XEN and RTE_LIBRTE_XEN_DOM0 in the
driver in order to mmap IO memory correctly.
Signed-off-by: Jijiang Liu
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index ba1364b..7f643be 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -32,7 +32,7 @@
#include
#include
-#ifdef CONFIG_XEN_DOM0
+#ifdef CONFIG_XEN
#include
#endif
#include
@@ -279,7 +279,7 @@ igbuio_pci_irqhandler(int irq, struct uio_info *info)
return IRQ_HANDLED;
}
-#ifdef CONFIG_XEN_DOM0
+#ifdef RTE_LIBRTE_XEN_DOM0
static int
igbuio_dom0_mmap_phys(struct uio_info *info, struct vm_area_struct *vma)
{
@@ -287,9 +287,7 @@ igbuio_dom0_mmap_phys(struct uio_info *info, struct
vm_area_struct *vma)
idx = (int)vma->vm_pgoff;
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-#ifdef HAVE_PTE_MASK_PAGE_IOMAP
vma->vm_page_prot.pgprot |= _PAGE_IOMAP;
-#endif
return remap_pfn_range(vma,
vma->vm_start,
@@ -487,7 +485,7 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
udev->info.version = "0.1";
udev->info.handler = igbuio_pci_irqhandler;
udev->info.irqcontrol = igbuio_pci_irqcontrol;
-#ifdef CONFIG_XEN_DOM0
+#ifdef RTE_LIBRTE_XEN_DOM0
/* check if the driver run on Xen Dom0 */
if (xen_initial_domain())
udev->info.mmap = igbuio_dom0_pci_mmap;
--
1.7.7.6
[dpdk-dev] [PATCH 1/3] compilation:fix compilation issues of using gcc-4.3.4
Fixed a compilation issue when using gcc-4.3.4 in SUSE Linux 11 SP3.
Signe-off-by: Jijiang Liu
---
app/test/test.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/app/test/test.h b/app/test/test.h
index 896f7db..8b76ccf 100644
--- a/app/test/test.h
+++ b/app/test/test.h
@@ -149,7 +149,7 @@ struct test_command {
void add_test_command(struct test_command *t);
#define REGISTER_TEST_COMMAND(t) \
-static void testfn_##t(void);\
+void testfn_##t(void);\
void __attribute__((constructor, used)) testfn_##t(void)\
{\
add_test_command();\
--
1.7.7.6
[dpdk-dev] [PATCH 0/3] dpdk/xen:support DPDK running on Xen Dom0 of SUSE Linux
Because SUSE linux kernel doesn't not fully follow Linux kernel in main branch,
there are some diffirences between them, and DPDK can't run on Xen Dom0 of SUSE
Linux. Recently, some customers want us to support this, so we provide this
patch set for it.
Now this patch set V1 is not compatible with Linux kernel in main branch, this
purpose of sending the patch set is to help those customers who have an urgent
need;we probably cooperate with SUSE to eliminate the gap in the future.
The patch set was validated with the following SW version:
SUSE 11 SP3 (Linux Kernel: 3.0.76-0.11-xen)
Hypervisor: XEN 4.2
GCC: gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)
DPDK: 1.8
In addition, users have to a small change in the source codes in SUSE 11 SP3
Linux kernel for this patch set:
comment the 'CONFIG_XEN' define out in ./include/linux/msi.h, or esle there
will be some compilation errors.
//#ifndef CONFIG_XEN
struct msi_msg {
u32 address_lo; /* low 32 bits of msi message address */
u32 address_hi; /* high 32 bits of msi message address */
u32 data; /* 16 bits of msi message data */
};
...
//#else /* CONFIG_XEN */
//struct pci_dev;
//struct msi_desc;
//#endif /* CONFIG_XEN */
Jijiang Liu (3):
fix compilation issue
Dom0 driver change
igb_uio driver change
app/test/test.h |2 +-
config/common_linuxapp |2 +-
lib/librte_eal/linuxapp/igb_uio/igb_uio.c |8 +++-
lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c | 10 ++
4 files changed, 11 insertions(+), 11 deletions(-)
--
1.7.7.6
[dpdk-dev] [PATCH] MAINTAINERS: claim responsibility for Linux AF_PACKET PMD
On Fri, Jan 23, 2015 at 01:12:25PM -0500, John W. Linville wrote: > Signed-off-by: John W. Linville > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 1f7d04a9ec2b..5fccdbb1618c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -174,6 +174,7 @@ F: examples/kni/ > F: doc/guides/sample_app_ug/kernel_nic_interface.rst > > Linux AF_PACKET > +M: John W. Linville > F: lib/librte_pmd_af_packet/ > > Cisco enic > -- > 2.1.0 > > Works just as well for me Acked-by: Neil Horman Thanks John! Neil
[dpdk-dev] [PATCH] MAINTAINERS: claim responsibility for Linux AF_PACKET PMD
Signed-off-by: John W. Linville --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1f7d04a9ec2b..5fccdbb1618c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -174,6 +174,7 @@ F: examples/kni/ F: doc/guides/sample_app_ug/kernel_nic_interface.rst Linux AF_PACKET +M: John W. Linville F: lib/librte_pmd_af_packet/ Cisco enic -- 2.1.0
[dpdk-dev] Segmentation fault in ixgbe_rxtx_vec.c:444 with 1.8.0
Hi Bruce,
I now had the chance to reproduce the issue we are seeing with a DPDK
example app.
I started out with a vanilla DPDK 1.8.0 and only made the following changes:
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index e684234..48e6b7c 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -118,8 +118,9 @@ static const struct rte_eth_conf port_conf = {
.header_split = 0, /**< Header Split disabled */
.hw_ip_checksum = 0, /**< IP checksum offload disabled */
.hw_vlan_filter = 0, /**< VLAN filtering disabled */
- .jumbo_frame= 0, /**< Jumbo Frame Support disabled */
+ .jumbo_frame= 1, /**< Jumbo Frame Support disabled */
.hw_strip_crc = 0, /**< CRC stripped by hardware */
+ .max_rx_pkt_len = 9000,
},
.txmode = {
.mq_mode = ETH_MQ_TX_NONE,
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
index b54cb19..dfaccee 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
@@ -402,10 +402,10 @@ reassemble_packets(struct igb_rx_queue *rxq,
struct rte_mbuf **rx_bufs,
struct rte_mbuf *pkts[RTE_IXGBE_VPMD_RX_BURST]; /*finished pkts*/
struct rte_mbuf *start = rxq->pkt_first_seg;
struct rte_mbuf *end = rxq->pkt_last_seg;
- unsigned pkt_idx = 0, buf_idx = 0;
+ unsigned pkt_idx, buf_idx;
- while (buf_idx < nb_bufs) {
+ for (buf_idx = 0, pkt_idx = 0; buf_idx < nb_bufs; buf_idx++) {
if (end != NULL) {
/* processing a split packet */
end->next = rx_bufs[buf_idx];
@@ -448,7 +448,6 @@ reassemble_packets(struct igb_rx_queue *rxq, struct
rte_mbuf **rx_bufs,
rx_bufs[buf_idx]->data_len += rxq->crc_len;
rx_bufs[buf_idx]->pkt_len += rxq->crc_len;
}
- buf_idx++;
}
/* save the partial packet for next time */
This includes your previously posted fix and makes a small modification
to the l2fwd example app to enable jumbo frames of up to 9000 bytes.
The system is equipped with a two port Intel 82599 card and both ports
are hooked up to a packet generator. The packet generator produces
simple Ethernet/IPv4/UDP packets.
I started the l2fwd app with the following command line:
$ ./build/l2fwd -c f -n 4 -- -q 8 -p 3
Both build variants that I have tested (CONFIG_RTE_IXGBE_INC_VECTOR=y
and CONFIG_RTE_IXGBE_INC_VECTOR=n) now give me the same result:
As long as the packet size is <= 2048 bytes the application behaves
normally and all packets are forwarded as expected.
As soon as the packet size exceeds 2048 bytes the application will only
forward some packets and then stop forwarding altogether. Even small
packets will not be forwarded anymore.
If you want me to try out anything else just let me know.
Best regards,
Martin
On 21.01.15 14:49, Bruce Richardson wrote:
> On Tue, Jan 20, 2015 at 11:39:03AM +0100, Martin Weiser wrote:
>> Hi again,
>>
>> I did some further testing and it seems like this issue is linked to
>> jumbo frames. I think a similar issue has already been reported by
>> Prashant Upadhyaya with the subject 'Packet Rx issue with DPDK1.8'.
>> In our application we use the following rxmode port configuration:
>>
>> .mq_mode= ETH_MQ_RX_RSS,
>> .split_hdr_size = 0,
>> .header_split = 0,
>> .hw_ip_checksum = 1,
>> .hw_vlan_filter = 0,
>> .jumbo_frame= 1,
>> .hw_strip_crc = 1,
>> .max_rx_pkt_len = 9000,
>>
>> and the mbuf size is calculated like the following:
>>
>> (2048 + sizeof(struct rte_mbuf) + RTE_PKTMBUF_HEADROOM)
>>
>> This works fine with DPDK 1.7 and jumbo frames are split into buffer
>> chains and can be forwarded on another port without a problem.
>> With DPDK 1.8 and the default configuration (CONFIG_RTE_IXGBE_INC_VECTOR
>> enabled) the application sometimes crashes like described in my first
>> mail and sometimes packet receiving stops with subsequently arriving
>> packets counted as rx errors. When CONFIG_RTE_IXGBE_INC_VECTOR is
>> disabled the packet processing also comes to a halt as soon as jumbo
>> frames arrive with a the slightly different effect that now
>> rte_eth_tx_burst refuses to send any previously received packets.
>>
>> Is there anything special to consider regarding jumbo frames when moving
>> from DPDK 1.7 to 1.8 that we might have missed?
>>
>> Martin
>>
>>
>>
>> On 19.01.15 11:26, Martin Weiser wrote:
>>> Hi everybody,
>>>
>>> we quite recently updated one of our applications to DPDK 1.8.0 and are
>>> now seeing a segmentation fault in ixgbe_rxtx_vec.c:444 after a few minutes.
>>> I just did some quick debugging and I only have a very limited
>>> understanding of the code in question but it seems that the 'continue'
>>> in line 445 without increasing 'buf_idx' might cause the problem. In one
>>> debugging session when the
[dpdk-dev] [PATCH v4 06/11] eal/linux/pci: Add functions for unmapping igb_uio resources
Hi Michael, On 2015/01/23 11:54, Qiu, Michael wrote: > On 1/22/2015 6:16 PM, Tetsuya Mukawa wrote: >> Hi Michael, >> >> On 2015/01/22 17:12, Qiu, Michael wrote: >>> On 1/21/2015 6:01 PM, Tetsuya Mukawa wrote: Hi Michael, On 2015/01/20 18:23, Qiu, Michael wrote: > On 1/19/2015 6:42 PM, Tetsuya Mukawa wrote: >> The patch adds functions for unmapping igb_uio resources. The patch is >> only >> for Linux and igb_uio environment. VFIO and BSD are not supported. >> >> v4: >> - Add paramerter checking. >> - Add header file to determine if hotplug can be enabled. >> >> Signed-off-by: Tetsuya Mukawa >> --- >> lib/librte_eal/common/Makefile | 1 + >> lib/librte_eal/common/include/rte_dev_hotplug.h | 44 + >> lib/librte_eal/linuxapp/eal/eal_pci.c | 38 +++ >> lib/librte_eal/linuxapp/eal/eal_pci_init.h | 8 +++ >> lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 65 >> + >> 5 files changed, 156 insertions(+) >> create mode 100644 lib/librte_eal/common/include/rte_dev_hotplug.h >> >> diff --git a/lib/librte_eal/common/Makefile >> b/lib/librte_eal/common/Makefile >> index 52c1a5f..db7cc93 100644 >> --- a/lib/librte_eal/common/Makefile >> +++ b/lib/librte_eal/common/Makefile >> @@ -41,6 +41,7 @@ INC += rte_eal_memconfig.h rte_malloc_heap.h >> INC += rte_hexdump.h rte_devargs.h rte_dev.h >> INC += rte_common_vect.h >> INC += rte_pci_dev_feature_defs.h rte_pci_dev_features.h >> +INC += rte_dev_hotplug.h >> >> ifeq ($(CONFIG_RTE_INSECURE_FUNCTION_WARNING),y) >> INC += rte_warnings.h >> diff --git a/lib/librte_eal/common/include/rte_dev_hotplug.h >> b/lib/librte_eal/common/include/rte_dev_hotplug.h >> new file mode 100644 >> index 000..b333e0f >> --- /dev/null >> +++ b/lib/librte_eal/common/include/rte_dev_hotplug.h >> @@ -0,0 +1,44 @@ >> +/*- >> + * BSD LICENSE >> + * >> + * Copyright(c) 2015 IGEL Co.,LTd. >> + * 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 IGEL Co.,Ltd. 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. >> + */ >> + >> +#ifndef _RTE_DEV_HOTPLUG_H_ >> +#define _RTE_DEV_HOTPLUG_H_ >> + >> +/* >> + * determine if hotplug can be enabled on the system >> + */ >> +#if defined(RTE_LIBRTE_EAL_HOTPLUG) && defined(RTE_LIBRTE_EAL_LINUXAPP) > As you said, VFIO should not work with it, so does it need to add the > vfio check here? Could I have a advice of you? First I guess it's the best to include "eal_vfio.h" here, and add checking of VFIO_PRESENT macro. >>> I have a question, will your hotplug feature support freebsd ? >>> >>> If not, how about to put it in "lib/librte_eal/linuxapp/eal/" ? Also >>> include attach or detach affairs. >> I appreciate your comments. >> >> So far, FreeBSD doesn't support PCI hotplug. So I didn't implement code >> for FreeBSD. >> But in the future, I want to implement it when FreeBSD supports it. >> Also my hotplug implementation depends on legacy code already >> implemented in common layer. >> Anyway, for me
[dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user support
On 2015/1/23 11:40, Xie, Huawei wrote: > > >> -Original Message- >> From: Linhaifeng [mailto:haifeng.lin at huawei.com] >> Sent: Thursday, December 11, 2014 1:36 PM >> To: Xie, Huawei; dev at dpdk.org >> Cc: haifeng.lin at intel.com >> Subject: Re: [dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user >> support >> >> >> >> On 2014/12/11 5:37, Huawei Xie wrote: >>> vhost-user support >>> >>> >>> Signed-off-by: Huawei Xie >>> --- >>> lib/librte_vhost/Makefile | 5 +- >>> + case VHOST_USER_SET_LOG_FD: >> >> should close fd for fd leak when receive VHOST_USER_SET_LOG_FD msg? > Ok, would at least close the fd though we don't support. > Do you know how to test this? reboot VM many times then watch the number of fd with command 'ls /proc/pidof vhost/fd |wc -l' >> >>> + RTE_LOG(INFO, VHOST_CONFIG, "not implemented.\n"); >>> + >>> + case VHOST_USER_SET_VRING_ERR: >> >> should close fd for fd leak? > Would do. >> >>> + RTE_LOG(INFO, VHOST_CONFIG, "not implemented\n"); >>> + break; >>> +#endif >>> >> >> -- >> Regards, >> Haifeng > > > -- Regards, Haifeng
[dpdk-dev] Segmentation fault in ixgbe_rxtx_vec.c:444 with 1.8.0
On Fri, Jan 23, 2015 at 12:37:09PM +0100, Martin Weiser wrote:
> Hi Bruce,
>
> I now had the chance to reproduce the issue we are seeing with a DPDK
> example app.
> I started out with a vanilla DPDK 1.8.0 and only made the following changes:
>
> diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
> index e684234..48e6b7c 100644
> --- a/examples/l2fwd/main.c
> +++ b/examples/l2fwd/main.c
> @@ -118,8 +118,9 @@ static const struct rte_eth_conf port_conf = {
> .header_split = 0, /**< Header Split disabled */
> .hw_ip_checksum = 0, /**< IP checksum offload disabled */
> .hw_vlan_filter = 0, /**< VLAN filtering disabled */
> - .jumbo_frame= 0, /**< Jumbo Frame Support disabled */
> + .jumbo_frame= 1, /**< Jumbo Frame Support disabled */
> .hw_strip_crc = 0, /**< CRC stripped by hardware */
> + .max_rx_pkt_len = 9000,
> },
> .txmode = {
> .mq_mode = ETH_MQ_TX_NONE,
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
> b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
> index b54cb19..dfaccee 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
> @@ -402,10 +402,10 @@ reassemble_packets(struct igb_rx_queue *rxq,
> struct rte_mbuf **rx_bufs,
> struct rte_mbuf *pkts[RTE_IXGBE_VPMD_RX_BURST]; /*finished pkts*/
> struct rte_mbuf *start = rxq->pkt_first_seg;
> struct rte_mbuf *end = rxq->pkt_last_seg;
> - unsigned pkt_idx = 0, buf_idx = 0;
> + unsigned pkt_idx, buf_idx;
>
>
> - while (buf_idx < nb_bufs) {
> + for (buf_idx = 0, pkt_idx = 0; buf_idx < nb_bufs; buf_idx++) {
> if (end != NULL) {
> /* processing a split packet */
> end->next = rx_bufs[buf_idx];
> @@ -448,7 +448,6 @@ reassemble_packets(struct igb_rx_queue *rxq, struct
> rte_mbuf **rx_bufs,
> rx_bufs[buf_idx]->data_len += rxq->crc_len;
> rx_bufs[buf_idx]->pkt_len += rxq->crc_len;
> }
> - buf_idx++;
> }
>
> /* save the partial packet for next time */
>
>
> This includes your previously posted fix and makes a small modification
> to the l2fwd example app to enable jumbo frames of up to 9000 bytes.
> The system is equipped with a two port Intel 82599 card and both ports
> are hooked up to a packet generator. The packet generator produces
> simple Ethernet/IPv4/UDP packets.
> I started the l2fwd app with the following command line:
>
> $ ./build/l2fwd -c f -n 4 -- -q 8 -p 3
>
> Both build variants that I have tested (CONFIG_RTE_IXGBE_INC_VECTOR=y
> and CONFIG_RTE_IXGBE_INC_VECTOR=n) now give me the same result:
> As long as the packet size is <= 2048 bytes the application behaves
> normally and all packets are forwarded as expected.
> As soon as the packet size exceeds 2048 bytes the application will only
> forward some packets and then stop forwarding altogether. Even small
> packets will not be forwarded anymore.
>
> If you want me to try out anything else just let me know.
>
>
> Best regards,
> Martin
>
I think the txq flags are at fault here. The default txq flags setting for
the l2fwd sample application includes the flag ETH_TXQ_FLAGS_NOMULTSEGS which
disables support for sending packets with multiple segments i.e. jumbo frames
in this case. If you change l2fwd to explicitly pass a txqflags parameter in
as part of the port setup (as was the case in previous releases), and set
txqflags
to 0, does the problem go away?
/Bruce
>
>
> On 21.01.15 14:49, Bruce Richardson wrote:
> > On Tue, Jan 20, 2015 at 11:39:03AM +0100, Martin Weiser wrote:
> >> Hi again,
> >>
> >> I did some further testing and it seems like this issue is linked to
> >> jumbo frames. I think a similar issue has already been reported by
> >> Prashant Upadhyaya with the subject 'Packet Rx issue with DPDK1.8'.
> >> In our application we use the following rxmode port configuration:
> >>
> >> .mq_mode= ETH_MQ_RX_RSS,
> >> .split_hdr_size = 0,
> >> .header_split = 0,
> >> .hw_ip_checksum = 1,
> >> .hw_vlan_filter = 0,
> >> .jumbo_frame= 1,
> >> .hw_strip_crc = 1,
> >> .max_rx_pkt_len = 9000,
> >>
> >> and the mbuf size is calculated like the following:
> >>
> >> (2048 + sizeof(struct rte_mbuf) + RTE_PKTMBUF_HEADROOM)
> >>
> >> This works fine with DPDK 1.7 and jumbo frames are split into buffer
> >> chains and can be forwarded on another port without a problem.
> >> With DPDK 1.8 and the default configuration (CONFIG_RTE_IXGBE_INC_VECTOR
> >> enabled) the application sometimes crashes like described in my first
> >> mail and sometimes packet receiving stops with subsequently arriving
> >> packets counted as rx errors. When CONFIG_RTE_IXGBE_INC_VECTOR is
> >> disabled the packet processing also comes to a halt as soon as jumbo
> >> frames arrive with a the slightly
[dpdk-dev] [PATCH] testpmd: check return value of rte_eth_dev_vlan_filter()
This patch modifies testpmd behavior when setting:
rx_vlan add all vf_port (enabling all vlanids
to be passed thru rx filter on VF).
Rx_vlan_all_filter_set() function,
checks if the next vlanid can be enabled by the driver.
Number of vlanids is limited by the NIC and thus the NIC
do not allow to enable more vlanids than it can allocate
in VFTA table.
Signed-off by: Michal Jastrzebski
---
app/test-pmd/config.c | 14 --
app/test-pmd/testpmd.h|2 +-
lib/librte_ether/rte_ethdev.c |4 ++--
3 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 97b6525..6ef6cb0 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1643,21 +1643,22 @@ rx_vlan_filter_set(portid_t port_id, int on)
"diag=%d\n", port_id, on, diag);
}
-void
+int
rx_vft_set(portid_t port_id, uint16_t vlan_id, int on)
{
int diag;
if (port_id_is_invalid(port_id))
- return;
+ return 1;
if (vlan_id_is_invalid(vlan_id))
- return;
+ return 1;
diag = rte_eth_dev_vlan_filter(port_id, vlan_id, on);
if (diag == 0)
- return;
+ return 0;
printf("rte_eth_dev_vlan_filter(port_pi=%d, vlan_id=%d, on=%d) failed "
"diag=%d\n",
port_id, vlan_id, on, diag);
+ return -1;
}
void
@@ -1667,8 +1668,9 @@ rx_vlan_all_filter_set(portid_t port_id, int on)
if (port_id_is_invalid(port_id))
return;
- for (vlan_id = 0; vlan_id < 4096; vlan_id++)
- rx_vft_set(port_id, vlan_id, on);
+ for (vlan_id = 0; vlan_id < 4096; vlan_id++){
+ if ( rx_vft_set(port_id, vlan_id, on) ) break;
+ }
}
void
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index f8b0740..ee03a07 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -489,7 +489,7 @@ void rx_vlan_strip_set_on_queue(portid_t port_id, uint16_t
queue_id, int on);
void rx_vlan_filter_set(portid_t port_id, int on);
void rx_vlan_all_filter_set(portid_t port_id, int on);
-void rx_vft_set(portid_t port_id, uint16_t vlan_id, int on);
+int rx_vft_set(portid_t port_id, uint16_t vlan_id, int on);
void vlan_extend_set(portid_t port_id, int on);
void vlan_tpid_set(portid_t port_id, uint16_t tp_id);
void tx_vlan_set(portid_t port_id, uint16_t vlan_id);
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 95f2ceb..2e720f7 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1478,8 +1478,8 @@ rte_eth_dev_vlan_filter(uint8_t port_id, uint16_t
vlan_id, int on)
return (-EINVAL);
}
FUNC_PTR_OR_ERR_RET(*dev->dev_ops->vlan_filter_set, -ENOTSUP);
- (*dev->dev_ops->vlan_filter_set)(dev, vlan_id, on);
- return (0);
+
+ return (*dev->dev_ops->vlan_filter_set)(dev, vlan_id, on);
}
int
--
1.7.9.5
[dpdk-dev] [RFC 11/16] testpmd: rename vxlan in outer_ip in csum commands
Hi,
> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Thursday, January 22, 2015 7:37 AM
> To: dev at dpdk.org
> Cc: olivier.matz at 6wind.com; Ananyev, Konstantin; Liu, Jijiang
> Subject: [RFC 11/16] testpmd: rename vxlan in outer_ip in csum commands
>
> The tx_checksum command concerns outer IP checksum, not VxLAN checksum.
> Actually there is no checkum in VxLAN header, there is one checksum in outer
> IP
> header, and one checksum in outer UDP header. This option only controls the
> outer IP checksum.
>
> Signed-off-by: Olivier Matz
> ---
> app/test-pmd/cmdline.c | 16 app/test-pmd/csumonly.c | 25
> ++--- app/test-pmd/testpmd.h | 4 ++--
> 3 files changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> 1d294bc..451c728 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -316,12 +316,12 @@ static void cmd_help_long_parsed(void
> *parsed_result,
> "Disable hardware insertion of a VLAN header in"
> " packets sent on a port.\n\n"
>
> - "csum set (ip|udp|tcp|sctp|vxlan) (hw|sw) (port_id)\n"
> + "csum set (ip|udp|tcp|sctp|outer-ip) (hw|sw)
> (port_id)\n"
> "Select hardware or software calculation of the"
> " checksum with when transmitting a packet using the"
> " csum forward engine.\n"
> "ip|udp|tcp|sctp always concern the inner layer.\n"
> - "vxlan concerns the outer IP and UDP layer (in"
> + "outer-ip concerns the outer IP layer (in"
> " case the packet is recognized as a vxlan packet by"
> " the forward engine)\n"
> "Please check the NIC datasheet for HW limits.\n\n"
> @@ -2887,8 +2887,8 @@ csum_show(int port_id)
> (ol_flags & TESTPMD_TX_OFFLOAD_TCP_CKSUM) ? "hw" : "sw");
> printf("SCTP checksum offload is %s\n",
> (ol_flags & TESTPMD_TX_OFFLOAD_SCTP_CKSUM) ? "hw" :
> "sw");
> - printf("VxLAN checksum offload is %s\n",
> - (ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) ? "hw" :
> "sw");
> + printf("Outer-Ip checksum offload is %s\n",
> + (ol_flags & TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM) ? "hw" :
> "sw");
>
> /* display warnings if configuration is not supported by the NIC */
> rte_eth_dev_info_get(port_id, _info); @@ -2942,8 +2942,8 @@
> cmd_csum_parsed(void *parsed_result,
> mask = TESTPMD_TX_OFFLOAD_TCP_CKSUM;
> } else if (!strcmp(res->proto, "sctp")) {
> mask = TESTPMD_TX_OFFLOAD_SCTP_CKSUM;
> - } else if (!strcmp(res->proto, "vxlan")) {
> - mask = TESTPMD_TX_OFFLOAD_VXLAN_CKSUM;
> + } else if (!strcmp(res->proto, "outer-ip")) {
> + mask = TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM;
> }
>
> if (hw)
> @@ -2962,7 +2962,7 @@ cmdline_parse_token_string_t cmd_csum_mode =
> mode, "set");
> cmdline_parse_token_string_t cmd_csum_proto =
> TOKEN_STRING_INITIALIZER(struct cmd_csum_result,
> - proto, "ip#tcp#udp#sctp#vxlan");
> + proto, "ip#tcp#udp#sctp#outer-ip");
> cmdline_parse_token_string_t cmd_csum_hwsw =
> TOKEN_STRING_INITIALIZER(struct cmd_csum_result,
> hwsw, "hw#sw");
> @@ -2974,7 +2974,7 @@ cmdline_parse_inst_t cmd_csum_set = {
> .f = cmd_csum_parsed,
> .data = NULL,
> .help_str = "enable/disable hardware calculation of L3/L4 checksum
> when "
> - "using csum forward engine: csum set ip|tcp|udp|sctp|vxlan
> hw|sw ",
> + "using csum forward engine: csum set ip|tcp|udp|sctp|outer-ip
> hw|sw
> +",
> .tokens = {
> (void *)_csum_csum,
> (void *)_csum_mode,
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c index
> 858eb47..3921643 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -259,13 +259,16 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t
> outer_ethertype,
> ipv4_hdr->hdr_checksum = 0;
> ol_flags |= PKT_TX_OUTER_IPV4;
>
> - if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
> + if (testpmd_ol_flags &
> TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM)
> ol_flags |= PKT_TX_OUTER_IP_CKSUM;
> else
> ipv4_hdr->hdr_checksum = rte_ipv4_cksum(ipv4_hdr);
> - } else if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
> + } else if (testpmd_ol_flags &
> TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM)
> ol_flags |= PKT_TX_OUTER_IPV6;
>
> + /* outer UDP checksum is always
[dpdk-dev] [RFC 09/16] testpmd: move csum_show in a function
Hi,
-Original Message-
From: Olivier Matz [mailto:olivier.m...@6wind.com]
Sent: Thursday, January 22, 2015 7:36 AM
To: dev at dpdk.org
Cc: olivier.matz at 6wind.com; Ananyev, Konstantin; Liu, Jijiang
Subject: [RFC 09/16] testpmd: move csum_show in a function
No functional changes in this commit, we just move the code that displays the
csum forward engine configuration in a function.
This makes the next commit easier to read as it will also use this function.
Signed-off-by: Olivier Matz
---
app/test-pmd/cmdline.c | 82 +++---
1 file changed, 45 insertions(+), 37 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
1aecbbb..260a273 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -2867,14 +2867,56 @@ struct cmd_csum_result { };
static void
+csum_show(int port_id)
+{
+ struct rte_eth_dev_info dev_info;
+ uint16_t ol_flags;
+
+ ol_flags = ports[port_id].tx_ol_flags;
+ printf("IP checksum offload is %s\n",
+ (ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM) ? "hw" : "sw");
+ printf("UDP checksum offload is %s\n",
+ (ol_flags & TESTPMD_TX_OFFLOAD_UDP_CKSUM) ? "hw" : "sw");
+ printf("TCP checksum offload is %s\n",
+ (ol_flags & TESTPMD_TX_OFFLOAD_TCP_CKSUM) ? "hw" : "sw");
+ printf("SCTP checksum offload is %s\n",
+ (ol_flags & TESTPMD_TX_OFFLOAD_SCTP_CKSUM) ? "hw" : "sw");
+ printf("VxLAN checksum offload is %s\n",
+ (ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) ? "hw" : "sw");
+
+ /* display warnings if configuration is not supported by the NIC */
+ rte_eth_dev_info_get(port_id, _info);
+ if ((ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM) &&
+ (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_IPV4_CKSUM) == 0) {
+ printf("Warning: hardware IP checksum enabled but not "
+ "supported by port %d\n", port_id);
+ }
+ if ((ol_flags & TESTPMD_TX_OFFLOAD_UDP_CKSUM) &&
+ (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_UDP_CKSUM) == 0) {
+ printf("Warning: hardware UDP checksum enabled but not "
+ "supported by port %d\n", port_id);
+ }
+ if ((ol_flags & TESTPMD_TX_OFFLOAD_TCP_CKSUM) &&
+ (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_CKSUM) == 0) {
+ printf("Warning: hardware TCP checksum enabled but not "
+ "supported by port %d\n", port_id);
+ }
+ if ((ol_flags & TESTPMD_TX_OFFLOAD_SCTP_CKSUM) &&
+ (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_SCTP_CKSUM) == 0) {
+ printf("Warning: hardware SCTP checksum enabled but not "
+ "supported by port %d\n", port_id);
+ }
The ESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM check is missed here.
+
+}
+
+static void
cmd_csum_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
__attribute__((unused)) void *data) {
struct cmd_csum_result *res = parsed_result;
int hw = 0;
- uint16_t ol_flags, mask = 0;
- struct rte_eth_dev_info dev_info;
+ uint16_t mask = 0;
if (port_id_is_invalid(res->port_id)) {
printf("invalid port %d\n", res->port_id); @@ -2903,41 +2945,7
@@ cmd_csum_parsed(void *parsed_result,
else
ports[res->port_id].tx_ol_flags &= (~mask);
}
-
- ol_flags = ports[res->port_id].tx_ol_flags;
- printf("IP checksum offload is %s\n",
- (ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM) ? "hw" : "sw");
- printf("UDP checksum offload is %s\n",
- (ol_flags & TESTPMD_TX_OFFLOAD_UDP_CKSUM) ? "hw" : "sw");
- printf("TCP checksum offload is %s\n",
- (ol_flags & TESTPMD_TX_OFFLOAD_TCP_CKSUM) ? "hw" : "sw");
- printf("SCTP checksum offload is %s\n",
- (ol_flags & TESTPMD_TX_OFFLOAD_SCTP_CKSUM) ? "hw" : "sw");
- printf("VxLAN checksum offload is %s\n",
- (ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) ? "hw" : "sw");
-
- /* display warnings if configuration is not supported by the NIC */
- rte_eth_dev_info_get(res->port_id, _info);
- if ((ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM) &&
- (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_IPV4_CKSUM) == 0) {
- printf("Warning: hardware IP checksum enabled but not "
- "supported by port %d\n", res->port_id);
- }
- if ((ol_flags & TESTPMD_TX_OFFLOAD_UDP_CKSUM) &&
- (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_UDP_CKSUM) == 0) {
- printf("Warning: hardware UDP checksum enabled but not "
- "supported by port %d\n", res->port_id);
- }
- if ((ol_flags & TESTPMD_TX_OFFLOAD_TCP_CKSUM) &&
-
[dpdk-dev] some questions about rte_memcpy
On 2015/1/22 23:21, Bruce Richardson wrote:
> This (size_c) is a run-time constant, not a compile-time constant. To trigger
> the
> memcpy optimizations inside the compiler, the size value must be constant at
> compile time.
Hi, Bruce
You are right. When use compile-time constant memcpy is faster.Thank you for
all.
Here is my test result:
rte_memcpy(constant) size:8 time:876
rte_memcpy(variable) size:8 time:2824
rte_memcpy(constant) size:16 time:868
rte_memcpy(variable) size:16 time:4436
rte_memcpy(constant) size:32 time:856
rte_memcpy(variable) size:32 time:3264
rte_memcpy(constant) size:48 time:872
rte_memcpy(variable) size:48 time:3972
rte_memcpy(constant) size:64 time:856
rte_memcpy(variable) size:64 time:3644
rte_memcpy(constant) size:128 time:868
rte_memcpy(variable) size:128 time:4720
rte_memcpy(constant) size:256 time:868
rte_memcpy(variable) size:256 time:9624
Here is my test program(Who know how to use a loop to test 'constant memcpy'?):
#include
#include
#include
int main(int narg, char** args)
{
int i,t;
char buf[256];
int tests[7] = {8,16,32,48,64,128,256};
char
buf8[8],buf16[16],buf32[32],buf48[48],buf64[64],buf128[128],buf256[256];
uint64_t start, end;
int times = 999;
uint64_t result_c[7];
if (narg < 2) {
printf("usage:./rte_memcpy_test times\n");
return -1;
}
times = atoi(args[1]);
start = rte_rdtsc();
for(t = 0; t < times; t++) {
rte_memcpy(buf8, buf8, sizeof buf8);
}
end = rte_rdtsc();
result_c[0] = end - start;
start = rte_rdtsc();
for(t = 0; t < times; t++) {
rte_memcpy(buf16, buf16, sizeof buf16);
}
end = rte_rdtsc();
result_c[1] = end - start;
start = rte_rdtsc();
for(t = 0; t < times; t++) {
rte_memcpy(buf32, buf32, sizeof buf32);
}
end = rte_rdtsc();
result_c[2] = end - start;
start = rte_rdtsc();
for(t = 0; t < times; t++) {
rte_memcpy(buf48, buf48, sizeof buf48);
}
end = rte_rdtsc();
result_c[3] = end - start;
start = rte_rdtsc();
for(t = 0; t < times; t++) {
rte_memcpy(buf64, buf64, sizeof buf64);
}
end = rte_rdtsc();
result_c[4] = end - start;
start = rte_rdtsc();
for(t = 0; t < times; t++) {
rte_memcpy(buf128, buf128, sizeof buf128);
}
end = rte_rdtsc();
result_c[5] = end - start;
start = rte_rdtsc();
for(t = 0; t < times; t++) {
rte_memcpy(buf256, buf256, sizeof buf256);
}
end = rte_rdtsc();
result_c[6] = end - start;
for (i = 0; i < (sizeof tests / sizeof tests[0]); i++) {
start = rte_rdtsc();
for(t = 0; t < times; t++) {
rte_memcpy(buf, buf, tests[i]);
}
end = rte_rdtsc();
printf("rte_memcpy(constant) size:%d time:%llu\n", tests[i],
result_c[i]);
printf("rte_memcpy(variable) size:%d time:%llu\n", tests[i],
end - start);
}
return 0;
}
--
Regards,
Haifeng
[dpdk-dev] [RFC 00/16] enhance checksum offload API
Hi Stephen, On 01/22/2015 02:01 AM, Stephen Hemminger wrote: > On Thu, 22 Jan 2015 00:36:19 +0100 > Olivier Matz wrote: > >> The goal of this series is to clarify and simplify the mbuf offload API. >> Several issues are solved: > > If you are doing this could you invert the meaning of the checksum > flags? Right now the flags are fine for Intel hardware but are useless > for devices that have less checksum support. > > It would work better if instead of two states: > * Checksum known bad=> PKT_RX_L4_CKSUM_BAD == 1 > * Checksum (maybe) good => PKT_RX_L4_CKSUM_BAD == 0 > The bit was changed to only flag good checksum: > * Checksum known good => PKT_RX_L4_CKSUM_GOOD == 1 > * Checksum status unknown => PKT_RX_L4_CKSUM_GOOD == 0 > > That way code code fallback to software checksum if hardware was incapable > of handling the packet. It does mean packets with bad checksums get checked > twice, but thats ok. I agree that current rx checksum flags in dpdk could be enhanced. Your proposition is indeed already much better that what we currently have. I'm ok to submit a patch for this before the 2.0 release. However, I think we could do even better with 2 flags. The first idea is to have one bit saying "the hw verified the checksum" and a second one saying "it is good or bad". The second idea is to use flags like PKT_RX_L4_TCP or PKT_RX_L4_UDP to replace the first bit of the first idea, like it's done for IPv4. Therefore, the value of the flag PKT_RX_L4_CKSUM_GOOD should only be checked if the L4 protocol is recognized. Another thing that could be also useful for virtual driver is a way to say: "the packet integrity is correct but the checksum field in the packet may be wrong". This can happen for instance in this case: - a guest transmits on a vdev without calculating the checksums (gaining cpu time) - the host receives it, it does not check the rx checksums (because it knows the packet integrity is correct, the packet comes from memory not from a network) - then if the host wants to forward it, it has to schedule a tx checksum on a real hw. Let me know if you have any comment. However, I think this will conflicts with the packet_type feature that is proposed by Helin: http://dpdk.org/ml/archives/dev/2015-January/011156.html Regards, Olivier
[dpdk-dev] [PATCH] maintainers: start a Linux-style file
On Fri, Jan 23, 2015 at 03:46:08PM +0100, Thomas Monjalon wrote: > 2015-01-23 09:18, Neil Horman: > > One question, the security issues list, is that active already and in use? > > It is "in use" since the beginning of dpdk.org. But traffic is very very low. > > > Can we document the membership of that list so we know who's handling > > security > > issues? > > Only me but you are welcome: > http://dpdk.org/ml/listinfo/maintainers > > -- > Thomas> Thanks! Neil
[dpdk-dev] [PATCH] mk: add support for ICC 15 compiler
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Daniel Mrzyglod > Sent: Thursday, January 22, 2015 9:54 AM > > This patch add Support for ICC 15. > > ICC 15 changed inline-max-size and inline-max-total-size default values, so > for ICC 15 flags -no-inline-max-size -no-inline-max-total-size must be added. > > additionally disable compile error for: > 13368 - loop was not vectorized with "vector always assert" > 15527 - loop was not vectorized: function call to fprintf cannot be vectorize > > Signed-off-by: Daniel Mrzyglod > --- > mk/toolchain/icc/rte.vars.mk | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/mk/toolchain/icc/rte.vars.mk b/mk/toolchain/icc/rte.vars.mk > index 5503fb0..e39d710 100644 > --- a/mk/toolchain/icc/rte.vars.mk > +++ b/mk/toolchain/icc/rte.vars.mk > @@ -66,11 +66,18 @@ TOOLCHAIN_ASFLAGS = > # Turn off some ICC warnings - > # Remark #271 : trailing comma is nonstandard > # Warning #1478 : function "" (declared at line N of > "") > +# error #13368: loop was not vectorized with "vector always assert" > +# error #15527: loop was not vectorized: function call to fprintf cannot be > vectorize > # was declared "deprecated" > WERROR_FLAGS := -Wall -Werror-all -w2 -diag-disable 271 -diag-warning > 1478 > +WERROR_FLAGS += -diag-disable 13368 -diag-disable 15527 > > # process cpu flags > include $(RTE_SDK)/mk/toolchain/$(RTE_TOOLCHAIN)/rte.toolchain- > compat.mk > +# disable max-inline params boundaries for ICC 15 compiler ifeq > +($(shell test $(ICC_MAJOR_VERSION) -eq 15 && echo 1), 1) > + TOOLCHAIN_CFLAGS += -no-inline-max-size -no-inline-max-total-size > +endif > > export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF export > TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS > -- > 2.1.0 Acked-by: Sergio Gonzalez Monroy
[dpdk-dev] [RFC PATCH 0/5] Introduce low-latency one-shot rx interrupt into DPDK with polling/interrupt switch control example
Thanks Ivan for your time spending on reviewing the patchset. Will fix those issues When submitting official patchset. > -Original Message- > From: Ivan Boule [mailto:ivan.boule at 6wind.com] > Sent: Friday, January 23, 2015 5:22 PM > To: Zhou, Danny; dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC PATCH 0/5] Introduce low-latency one-shot rx > interrupt into DPDK with polling/interrupt switch > control example > > Hello Danny, > > > On 01/20/2015 10:53 AM, Danny Zhou wrote: > > DPDK interrupt notification/handling mechanism is based on UIO with > > below limitation: > > 1) It is designed to handle LSC interrupt only with inefficient > > suspended pthread wakeup procedure (e.g. UIO wakes up LSC interrupt > > handling thread which then wakes up DPDK polling thread). In this way, > > it introduces non-deterministic wakeup latency for DPDK polling thread > > as well as packet latency if it is used to handle Rx interrupt. > > 2) UIO only supports a single interrupt vector which has to been shared > > by LSC interrupt and interrupts assigned to dedicated rx queues. > > > > This patchset includes below features: > > 1) Enable one-shot rx queue interrupt in ixgbe PMD for PF as well as VF. > > 2) Build on top of the VFIO mechanism instead of UIO, so it could support > > up to 64 interrupt vectors for rx queue interrupts. > > 3) Have 1 DPDK polling thread handle per Rx queue interrupt with a > > dedicated VFIO eventfd, which eliminates non-deterministic pthread wakeup > > latency in user space. > > 4) Demonstrate interrupts control APIs and userspace NAIP-like > > polling/interrupt switch algorithms in L3fwd-power example. > > In the patch 3/5: > > - the function eal_intr_process_rx_interrupts() systematically returns > 0. It should be declared as "void" (and get rid of the return 0). > > - the function eal_intr_handle_rx_interrupts() loops again when > epoll_wait() returns with errno == EINTR. >It should also return in this case. > > - the function rte_eal_wait_rx_intr() should not invoke rte_panic() but > instead return "-errno" upon system call failure. > > With these fixes: > Acked-By: Ivan Boule > > -- > Ivan Boule > 6WIND Development Engineer
[dpdk-dev] [RFC 04/16] i40e: remove the use of PKT_TX_UDP_TUNNEL_PKT flag
Hi Helin,
On 01/23/2015 09:47 AM, Zhang, Helin wrote:
>>> diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c
>>> b/lib/librte_pmd_i40e/i40e_rxtx.c index 9acdeee..0786255 100644
>>> --- a/lib/librte_pmd_i40e/i40e_rxtx.c
>>> +++ b/lib/librte_pmd_i40e/i40e_rxtx.c
>>> @@ -482,7 +482,7 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
>>> }
>>>
>>> /* UDP tunneling packet TX checksum offload */
>>> - if (unlikely(ol_flags & PKT_TX_UDP_TUNNEL_PKT)) {
>>> + if (unlikely(ol_flags & PKT_TX_OUTER_IP_CKSUM)) {
>>
>> This way will disable FVL TX checksum offload capability of inner IP and
>> inner
>> L4 using B.1 method.
>>
>> Again, the B.1 in
>> http://dpdk.org/ml/archives/dev/2014-December/009213.html should be
>> supported and allowed.
>>
>> Helin, you are i40e maintainer, what's your point?
>
> Can we list all the possible checksum cases (with or without hardware
> offloads)?
> 1. Outer IP (hw csum) + inner IP (hw csum) + L4 (hw csum)
> 2. Outer IP (hw csum) + inner IP (hw csum) + L4 (sw csum)
> 3. Outer IP (hw csum) + inner IP (sw csum) + L4 (hw csum)
case 6 in [1]
> 4. Outer IP (hw csum) + inner IP (sw csum) + L4 (sw csum)
case 1 in [1]
> 5. Outer IP (sw csum) + inner IP (hw csum) + L4 (hw csum)
> 6. Outer IP (sw csum) + inner IP (hw csum) + L4 (sw csum)
> 7. Outer IP (sw csum) + inner IP (sw csum) + L4 (hw csum)
case 3 and 4 in [1]
> 8. Outer IP (sw csum) + inner IP (sw csum) + L4 (sw csum)
no hardware offload
Removing the PKT_TX_UDP_TUNNEL_PKT does not prevent to do an
operation from the user point of view. In i40e, there are 2
ways to calculate the inner checksums. The idea is to have only
one in the mbuf API, and to let the driver decide how to talk to
the hardware, but it's not the user problem.
Regards,
Olivier
[1] http://dpdk.org/ml/archives/dev/2015-January/011127.html
[dpdk-dev] make config on cents 6.6 with 3.5 kernel and 4.7 gcc not finding config target
On Thu, Jan 22, 2015 at 10:42:26PM +, Vipin Agrawal wrote: > I was able to build it without any issues earlier yesterday but all of a > sudden, it started to give me this error. All I did was add the boot options > in grub.con : default_hugepagesz=1G hugepagesz=1G hugepages=4 hpet_mmap > > Even after removing them, this problem still persists. > > [root at localhost dpdk-1.8.0]# make config T=x86_64-default-linuxapp-gcc This should have "native" instead of "default" in the target specifier. Regards, /Bruce
[dpdk-dev] [PATCH] maintainers: start a Linux-style file
On Fri, Jan 23, 2015 at 01:54:13PM +0100, Thomas Monjalon wrote: > This MAINTAINERS file is inspired from the Linux one. > > Almost all files are split into areas in order to identify maintainers of > each DPDK area. Note that a maintainer is not a git tree manager. > Candidates are welcome to send a patch to sign up for one or several areas. > > There is a script to check covering, especially when adding or moving files. > > Signed-off-by: Thomas Monjalon > --- > MAINTAINERS | 388 > +++ > scripts/check-maintainers.sh | 85 ++ > 2 files changed, 473 insertions(+) > create mode 100644 MAINTAINERS > create mode 100755 scripts/check-maintainers.sh > Acked-by: Neil Horman feel free to add me in as the AF_PACKET pmd maintainer if Linville doesn't want the official title. One question, the security issues list, is that active already and in use? Can we document the membership of that list so we know who's handling security issues?
[dpdk-dev] [RFC 04/16] i40e: remove the use of PKT_TX_UDP_TUNNEL_PKT flag
Hi guys
> -Original Message-
> From: Liu, Jijiang
> Sent: Friday, January 23, 2015 4:06 PM
> To: Olivier Matz; Zhang, Helin
> Cc: Ananyev, Konstantin; dev at dpdk.org
> Subject: RE: [RFC 04/16] i40e: remove the use of PKT_TX_UDP_TUNNEL_PKT
> flag
>
> Hi,
>
> > -Original Message-
> > From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> > Sent: Thursday, January 22, 2015 7:36 AM
> > To: dev at dpdk.org
> > Cc: olivier.matz at 6wind.com; Ananyev, Konstantin; Liu, Jijiang
> > Subject: [RFC 04/16] i40e: remove the use of PKT_TX_UDP_TUNNEL_PKT
> > flag
> >
> > The definition of the flag in rte_mbuf.h was:
> > TX packet is an UDP tunneled packet. It must be specified when using
> > outer checksum offload (PKT_TX_OUTER_IP_CKSUM)
> >
> > This flag was used to tell the NIC that the offload type is UDP
> > (I40E_TXD_CTX_UDP_TUNNELING flag). In the datasheet, it says it's
> > required to specify the tunnel type in the register. However, some
> > tests (see [1]) showed that it also works without this flag.
> >
> > Moreover, it is not explained how the hardware use this information.
> > From a network perspective, this information is useless for
> > calculating the outer IP checksum as it does not depend on the payload.
> >
> > Having this flag in the API would force the application to specify the
> > tunnel type for something that looks only useful for this PMD. It will
> > limit the number of possible tunnel types (we would need a flag for
> > each tunnel type) and therefore prevent to support outer IP checksum for
> proprietary tunnels.
> >
> > Finally, if a hardware advertises "I support outer IP checksum", it
> > must be supported for any payload types.
> >
> > [1] http://dpdk.org/ml/archives/dev/2015-January/011380.html
> >
> > Signed-off-by: Olivier Matz
> > ---
> > lib/librte_pmd_i40e/i40e_rxtx.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c
> > b/lib/librte_pmd_i40e/i40e_rxtx.c index 9acdeee..0786255 100644
> > --- a/lib/librte_pmd_i40e/i40e_rxtx.c
> > +++ b/lib/librte_pmd_i40e/i40e_rxtx.c
> > @@ -482,7 +482,7 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
> > }
> >
> > /* UDP tunneling packet TX checksum offload */
> > - if (unlikely(ol_flags & PKT_TX_UDP_TUNNEL_PKT)) {
> > + if (unlikely(ol_flags & PKT_TX_OUTER_IP_CKSUM)) {
>
> This way will disable FVL TX checksum offload capability of inner IP and
> inner
> L4 using B.1 method.
>
> Again, the B.1 in
> http://dpdk.org/ml/archives/dev/2014-December/009213.html should be
> supported and allowed.
>
> Helin, you are i40e maintainer, what's your point?
Can we list all the possible checksum cases (with or without hardware offloads)?
1. Outer IP (hw csum) + inner IP (hw csum) + L4 (hw csum)
2. Outer IP (hw csum) + inner IP (hw csum) + L4 (sw csum)
3. Outer IP (hw csum) + inner IP (sw csum) + L4 (hw csum)
4. Outer IP (hw csum) + inner IP (sw csum) + L4 (sw csum)
5. Outer IP (sw csum) + inner IP (hw csum) + L4 (hw csum)
6. Outer IP (sw csum) + inner IP (hw csum) + L4 (sw csum)
7. Outer IP (sw csum) + inner IP (sw csum) + L4 (hw csum)
8. Outer IP (sw csum) + inner IP (sw csum) + L4 (sw csum)
Does any hardware support all of these cases? If yes, I think we should to have
a solution
to support all of them.
>
>
> > *td_offset |= (outer_l2_len >> 1)
> > << I40E_TX_DESC_LENGTH_MACLEN_SHIFT; @@ -497,7
> +497,6 @@
> > i40e_txd_enable_checksum(uint64_t ol_flags,
> > /* Now set the ctx descriptor fields */
> > *cd_tunneling |= (outer_l3_len >> 2) <<
> > I40E_TXD_CTX_QW0_EXT_IPLEN_SHIFT |
> > - I40E_TXD_CTX_UDP_TUNNELING |
> > (l2_len >> 1) <<
> > I40E_TXD_CTX_QW0_NATLEN_SHIFT;
> >
>
>
>
> > @@ -1165,8 +1164,7 @@ i40e_calc_context_desc(uint64_t flags) {
> > uint64_t mask = 0ULL;
> >
> > - if (flags | PKT_TX_UDP_TUNNEL_PKT)
> > - mask |= PKT_TX_UDP_TUNNEL_PKT;
> > + mask |= PKT_TX_OUTER_IP_CKSUM;
> >
> > #ifdef RTE_LIBRTE_IEEE1588
> > mask |= PKT_TX_IEEE1588_TMST;
> > --
> > 2.1.3
[dpdk-dev] [RFC 04/16] i40e: remove the use of PKT_TX_UDP_TUNNEL_PKT flag
Hi,
> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Thursday, January 22, 2015 7:36 AM
> To: dev at dpdk.org
> Cc: olivier.matz at 6wind.com; Ananyev, Konstantin; Liu, Jijiang
> Subject: [RFC 04/16] i40e: remove the use of PKT_TX_UDP_TUNNEL_PKT flag
>
> The definition of the flag in rte_mbuf.h was:
> TX packet is an UDP tunneled packet. It must be specified when using
> outer checksum offload (PKT_TX_OUTER_IP_CKSUM)
>
> This flag was used to tell the NIC that the offload type is UDP
> (I40E_TXD_CTX_UDP_TUNNELING flag). In the datasheet, it says it's required
> to specify the tunnel type in the register. However, some tests (see [1])
> showed that it also works without this flag.
>
> Moreover, it is not explained how the hardware use this information. From a
> network perspective, this information is useless for calculating the outer IP
> checksum as it does not depend on the payload.
>
> Having this flag in the API would force the application to specify the tunnel
> type for something that looks only useful for this PMD. It will limit the
> number of possible tunnel types (we would need a flag for each tunnel type)
> and therefore prevent to support outer IP checksum for proprietary tunnels.
>
> Finally, if a hardware advertises "I support outer IP checksum", it must be
> supported for any payload types.
>
> [1] http://dpdk.org/ml/archives/dev/2015-January/011380.html
>
> Signed-off-by: Olivier Matz
> ---
> lib/librte_pmd_i40e/i40e_rxtx.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
> index 9acdeee..0786255 100644
> --- a/lib/librte_pmd_i40e/i40e_rxtx.c
> +++ b/lib/librte_pmd_i40e/i40e_rxtx.c
> @@ -482,7 +482,7 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
> }
>
> /* UDP tunneling packet TX checksum offload */
> - if (unlikely(ol_flags & PKT_TX_UDP_TUNNEL_PKT)) {
> + if (unlikely(ol_flags & PKT_TX_OUTER_IP_CKSUM)) {
This way will disable FVL TX checksum offload capability of inner IP and inner
L4 using B.1 method.
Again, the B.1 in http://dpdk.org/ml/archives/dev/2014-December/009213.html
should be supported and allowed.
Helin, you are i40e maintainer, what's your point?
> *td_offset |= (outer_l2_len >> 1)
> << I40E_TX_DESC_LENGTH_MACLEN_SHIFT;
> @@ -497,7 +497,6 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
> /* Now set the ctx descriptor fields */
> *cd_tunneling |= (outer_l3_len >> 2) <<
> I40E_TXD_CTX_QW0_EXT_IPLEN_SHIFT |
> - I40E_TXD_CTX_UDP_TUNNELING |
> (l2_len >> 1) <<
> I40E_TXD_CTX_QW0_NATLEN_SHIFT;
>
> @@ -1165,8 +1164,7 @@ i40e_calc_context_desc(uint64_t flags) {
> uint64_t mask = 0ULL;
>
> - if (flags | PKT_TX_UDP_TUNNEL_PKT)
> - mask |= PKT_TX_UDP_TUNNEL_PKT;
> + mask |= PKT_TX_OUTER_IP_CKSUM;
>
> #ifdef RTE_LIBRTE_IEEE1588
> mask |= PKT_TX_IEEE1588_TMST;
> --
> 2.1.3
[dpdk-dev] [RFC 00/16] enhance checksum offload API
> > - remove the PKT_TX_UDP_TUNNEL_PKT flag: it is useless from an API point > of view. It was added because i40e need this info for some reason. We > have 3 solutions: > > - remove the flag and adapt the driver to the API (the choice I made > for this series). > I'm checking the L4TUN flag with relevant guys who is responsible for FVL HW. Please waiting...
[dpdk-dev] [PATCH 0/4] DPDK memcpy optimization
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson > Sent: Wednesday, January 21, 2015 9:26 PM > To: Marc Sune > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/4] DPDK memcpy optimization > > On Wed, Jan 21, 2015 at 02:21:25PM +0100, Marc Sune wrote: > > > > On 21/01/15 14:02, Bruce Richardson wrote: > > >On Wed, Jan 21, 2015 at 01:36:41PM +0100, Marc Sune wrote: > > >>On 21/01/15 04:44, Wang, Zhihong wrote: > > -Original Message- > > From: Richardson, Bruce > > Sent: Wednesday, January 21, 2015 12:15 AM > > To: Neil Horman > > Cc: Wang, Zhihong; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/4] DPDK memcpy optimization > > > > On Tue, Jan 20, 2015 at 10:11:18AM -0500, Neil Horman wrote: > > >On Tue, Jan 20, 2015 at 03:01:44AM +, Wang, Zhihong wrote: > > >>>-Original Message- > > >>>From: Neil Horman [mailto:nhorman at tuxdriver.com] > > >>>Sent: Monday, January 19, 2015 9:02 PM > > >>>To: Wang, Zhihong > > >>>Cc: dev at dpdk.org > > >>>Subject: Re: [dpdk-dev] [PATCH 0/4] DPDK memcpy optimization > > >>> > > >>>On Mon, Jan 19, 2015 at 09:53:30AM +0800, > > >>>zhihong.wang at intel.com > > wrote: > > This patch set optimizes memcpy for DPDK for both SSE and AVX > > platforms. > > It also extends memcpy test coverage with unaligned cases and > > more test > > >>>points. > > Optimization techniques are summarized below: > > > > 1. Utilize full cache bandwidth > > > > 2. Enforce aligned stores > > > > 3. Apply load address alignment based on architecture features > > > > 4. Make load/store address available as early as possible > > > > 5. General optimization techniques like inlining, branch > > reducing, prefetch pattern access > > > > Zhihong Wang (4): > > Disabled VTA for memcpy test in app/test/Makefile > > Removed unnecessary test cases in test_memcpy.c > > Extended test coverage in test_memcpy_perf.c > > Optimized memcpy in arch/x86/rte_memcpy.h for both SSE > and AVX > > platforms > > > > app/test/Makefile | 6 + > > app/test/test_memcpy.c | 52 +- > > app/test/test_memcpy_perf.c| 238 +--- > > .../common/include/arch/x86/rte_memcpy.h | 664 > > >>>+++-- > > 4 files changed, 656 insertions(+), 304 deletions(-) > > > > -- > > 1.9.3 > > > > > > >>>Are you able to compile this with gcc 4.9.2? The compilation > > >>>of test_memcpy_perf is taking forever for me. It appears hung. > > >>>Neil > > >>Neil, > > >> > > >>Thanks for reporting this! > > >>It should compile but will take quite some time if the CPU > > >>doesn't support > > AVX2, the reason is that: > > >>1. The SSE & AVX memcpy implementation is more complicated > than > > AVX2 > > >>version thus the compiler takes more time to compile and optimize > 2. > > >>The new test_memcpy_perf.c contains 126 constants memcpy calls > > >>for better test case coverage, that's quite a lot > > >> > > >>I've just tested this patch on an Ivy Bridge machine with GCC 4.9.2: > > >>1. The whole compile process takes 9'41" with the original > > >>test_memcpy_perf.c (63 + 63 = 126 constant memcpy calls) 2. It > > >>takes only 2'41" after I reduce the constant memcpy call number > > >>to 12 + 12 = 24 > > >> > > >>I'll reduce memcpy call in the next version of patch. > > >> > > >ok, thank you. I'm all for optimzation, but I think a compile > > >that takes almost > > >10 minutes for a single file is going to generate some raised > > >eyebrows when end users start tinkering with it > > > > > >Neil > > > > > >>Zhihong (John) > > >> > > Even two minutes is a very long time to compile, IMHO. The whole > > of DPDK doesn't take that long to compile right now, and that's > > with a couple of huge header files with routing tables in it. Any > > chance you could cut compile time down to a few seconds while still > having reasonable tests? > > Also, when there is AVX2 present on the system, what is the > > compile time like for that code? > > > > /Bruce > > >>>Neil, Bruce, > > >>> > > >>>Some data first. > > >>> > > >>>Sandy Bridge without AVX2: > > >>>1. original w/ 10 constant memcpy: 2'25" > > >>>2. patch w/ 12 constant memcpy: 2'41" > > >>>3. patch w/ 63 constant memcpy: 9'41" > > >>> > > >>>Haswell with AVX2: > > >>>1. original w/ 10 constant memcpy: 1'57" > > >>>2. patch w/ 12 constant memcpy: 1'56" > > >>>3. patch w/ 63
[dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user support
> -Original Message- > From: Linhaifeng [mailto:haifeng.lin at huawei.com] > Sent: Thursday, December 11, 2014 1:36 PM > To: Xie, Huawei; dev at dpdk.org > Cc: haifeng.lin at intel.com > Subject: Re: [dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user > support > > > > On 2014/12/11 5:37, Huawei Xie wrote: > > vhost-user support > > > > > > Signed-off-by: Huawei Xie > > --- > > lib/librte_vhost/Makefile | 5 +- > > + case VHOST_USER_SET_LOG_FD: > > should close fd for fd leak when receive VHOST_USER_SET_LOG_FD msg? Ok, would at least close the fd though we don't support. Do you know how to test this? > > > + RTE_LOG(INFO, VHOST_CONFIG, "not implemented.\n"); > > + > > + case VHOST_USER_SET_VRING_ERR: > > should close fd for fd leak? Would do. > > > + RTE_LOG(INFO, VHOST_CONFIG, "not implemented\n"); > > + break; > > +#endif > > > > -- > Regards, > Haifeng
[dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user support
> -Original Message-
> From: Linhaifeng [mailto:haifeng.lin at huawei.com]
> Sent: Thursday, December 11, 2014 2:04 PM
> To: Xie, Huawei; dev at dpdk.org
> Cc: haifeng.lin at intel.com
> Subject: Re: [dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user
> support
>
>
>
> On 2014/12/11 5:37, Huawei Xie wrote:
> > vhost-user support
> >
> >
> > Signed-off-by: Huawei Xie
> > ---
> > lib/librte_vhost/Makefile | 5 +-
> > lib/librte_vhost/vhost-net.h | 4 +
> > lib/librte_vhost/vhost_cuse/virtio-net-cdev.c | 9 +
> > lib/librte_vhost/vhost_user/vhost-net-user.c | 422
> ++
> > +
> > +static struct vhost_server *g_vhost_server;
>
> Only support one vhost-user port ?
The newer patch supports multiple vhost-user port.
Will send next week.
>
> > +
> > +static const char *vhost_message_str[VHOST_USER_MAX] = {
>
> why not use vserver_new_vq_conn(int fd, void* dat) ?
>
>
Since currently we only pass memory address and 32bit number, will change to
void *.
> > +{
> > + struct vhost_server *vserver = (void *)(uintptr_t)dat;
> regions[VHOST_MEMORY_MAX_NREGIONS];
> > + uint64_t mapped_address, base_address = 0;
> > +
> > + for (idx = 0; idx < memory.nregions; idx++) {
> > + if (memory.regions[idx].guest_phys_addr == 0)
> > + base_address = memory.regions[idx].userspace_addr;
> > + }
> > + if (base_address == 0) {
>
> when will base_address is 0? how to test to run this code?
base_address with 0 is the requirement for vhost-cuse implementation.
Normally it is the region [0, 0xA).
In this version, we would keep this and not fix this. In future, will remove
this.
>
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "couldn't find the mem region whose GPA is 0.\n");
> > + return -1;
> > + }
> > +
> > + for (idx = 0; idx < memory.nregions; idx++) {
> > + regions[idx].guest_phys_address =
> > + memory.regions[idx].guest_phys_addr;
> > + regions[idx].guest_phys_address_end =
> > + memory.regions[idx].guest_phys_addr +
> > + memory.regions[idx].memory_size;
> > + regions[idx].memory_size = memory.regions[idx].memory_size;
> > + regions[idx].userspace_address =
> > + memory.regions[idx].userspace_addr;
> > +
> > + /* This is ugly */
> > + mapped_address = (uint64_t)(uintptr_t)mmap(NULL,
> > + regions[idx].memory_size +
> > + memory.regions[idx].mmap_offset,
> > + PROT_READ | PROT_WRITE, MAP_SHARED,
> > + pmsg->fds[idx],
> > + 0);
>
> Can you mmap the region if gpa is 0? When i run VM with two numa node (qemu
> will create two hugepage file) found that always failed to mmap with the
> region
> which gpa is 0.
>
> BTW can we ensure the memory regions cover with all the memory of hugepage
> for VM?
>
We had discussed this. Seemed a qemu bug.
Do you have update on this?
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "mapped region %d to %p\n",
> > +struct virtio_net_device_ops const *notify_ops;
> > +struct virtio_net * get_device(struct vhost_device_ctx ctx);
> > +
> > +#endif
> >
>
> --
> Regards,
> Haifeng
Thanks Haifeng for your comments.
Next time, could you help cut the code not commented?
They are too long. It is really hard for me to find your comment.
[dpdk-dev] [PATCH 0/4] DPDK memcpy optimization
> -Original Message- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Wednesday, January 21, 2015 8:38 PM > To: Ananyev, Konstantin > Cc: Wang, Zhihong; Richardson, Bruce; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/4] DPDK memcpy optimization > > On Wed, Jan 21, 2015 at 12:02:57PM +, Ananyev, Konstantin wrote: > > > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wang, Zhihong > > > Sent: Wednesday, January 21, 2015 3:44 AM > > > To: Richardson, Bruce; Neil Horman > > > Cc: dev at dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 0/4] DPDK memcpy optimization > > > > > > > > > > > > > -Original Message- > > > > From: Richardson, Bruce > > > > Sent: Wednesday, January 21, 2015 12:15 AM > > > > To: Neil Horman > > > > Cc: Wang, Zhihong; dev at dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCH 0/4] DPDK memcpy optimization > > > > > > > > On Tue, Jan 20, 2015 at 10:11:18AM -0500, Neil Horman wrote: > > > > > On Tue, Jan 20, 2015 at 03:01:44AM +, Wang, Zhihong wrote: > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > > > > > Sent: Monday, January 19, 2015 9:02 PM > > > > > > > To: Wang, Zhihong > > > > > > > Cc: dev at dpdk.org > > > > > > > Subject: Re: [dpdk-dev] [PATCH 0/4] DPDK memcpy optimization > > > > > > > > > > > > > > On Mon, Jan 19, 2015 at 09:53:30AM +0800, > > > > > > > zhihong.wang at intel.com > > > > wrote: > > > > > > > > This patch set optimizes memcpy for DPDK for both SSE and > > > > > > > > AVX > > > > platforms. > > > > > > > > It also extends memcpy test coverage with unaligned cases > > > > > > > > and more test > > > > > > > points. > > > > > > > > > > > > > > > > Optimization techniques are summarized below: > > > > > > > > > > > > > > > > 1. Utilize full cache bandwidth > > > > > > > > > > > > > > > > 2. Enforce aligned stores > > > > > > > > > > > > > > > > 3. Apply load address alignment based on architecture > > > > > > > > features > > > > > > > > > > > > > > > > 4. Make load/store address available as early as possible > > > > > > > > > > > > > > > > 5. General optimization techniques like inlining, branch > > > > > > > > reducing, prefetch pattern access > > > > > > > > > > > > > > > > Zhihong Wang (4): > > > > > > > > Disabled VTA for memcpy test in app/test/Makefile > > > > > > > > Removed unnecessary test cases in test_memcpy.c > > > > > > > > Extended test coverage in test_memcpy_perf.c > > > > > > > > Optimized memcpy in arch/x86/rte_memcpy.h for both SSE > and AVX > > > > > > > > platforms > > > > > > > > > > > > > > > > app/test/Makefile | 6 + > > > > > > > > app/test/test_memcpy.c | 52 +- > > > > > > > > app/test/test_memcpy_perf.c| 238 > > > > > > > > +--- > > > > > > > > .../common/include/arch/x86/rte_memcpy.h | 664 > > > > > > > +++-- > > > > > > > > 4 files changed, 656 insertions(+), 304 deletions(-) > > > > > > > > > > > > > > > > -- > > > > > > > > 1.9.3 > > > > > > > > > > > > > > > > > > > > > > > Are you able to compile this with gcc 4.9.2? The > > > > > > > compilation of test_memcpy_perf is taking forever for me. It > appears hung. > > > > > > > Neil > > > > > > > > > > > > > > > > > > Neil, > > > > > > > > > > > > Thanks for reporting this! > > > > > > It should compile but will take quite some time if the CPU > > > > > > doesn't support > > > > AVX2, the reason is that: > > > > > > 1. The SSE & AVX memcpy implementation is more complicated > > > > > > than > > > > AVX2 > > > > > > version thus the compiler takes more time to compile and optimize > 2. > > > > > > The new test_memcpy_perf.c contains 126 constants memcpy calls > > > > > > for better test case coverage, that's quite a lot > > > > > > > > > > > > I've just tested this patch on an Ivy Bridge machine with GCC 4.9.2: > > > > > > 1. The whole compile process takes 9'41" with the original > > > > > > test_memcpy_perf.c (63 + 63 = 126 constant memcpy calls) 2. It > > > > > > takes only 2'41" after I reduce the constant memcpy call > > > > > > number to 12 + 12 = 24 > > > > > > > > > > > > I'll reduce memcpy call in the next version of patch. > > > > > > > > > > > ok, thank you. I'm all for optimzation, but I think a compile > > > > > that takes almost > > > > > 10 minutes for a single file is going to generate some raised > > > > > eyebrows when end users start tinkering with it > > > > > > > > > > Neil > > > > > > > > > > > Zhihong (John) > > > > > > > > > > Even two minutes is a very long time to compile, IMHO. The whole > > > > of DPDK doesn't take that long to compile right now, and that's > > > > with a couple of huge header files with routing tables in it. Any > > > > chance you could cut compile time down to a few seconds while still > having reasonable tests? > > > > Also, when
[dpdk-dev] [PATCH v2 3/5] vhost: enable promisc mode and config VMDQ offload register for multicast feature
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, January 15, 2015 12:37 AM > To: dev at dpdk.org > Cc: Xie, Huawei; Ouyang, Changchun > Subject: Re: [dpdk-dev] [PATCH v2 3/5] vhost: enable promisc mode and config > VMDQ offload register for multicast feature > > Hi Huawei, > > 2015-01-08 10:07, Xie, Huawei: > > CTRL_RX is dependent on CTRL_VQ. > > CTRL_VQ should be enabled if CTRL_RX is enabled. > > Observed that virtio-net driver will crash if CTRL_VQ isn't enabled in > > vhost-user > case. > > /* Caller should know better */ > > BUG_ON(!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ) || > > (out + in > VIRTNET_SEND_COMMAND_SG_MAX)); > > Do you plan to send a patch? In the vhost-user patch, will temporarily turn this on. However, we don't create any control queues in vhost. Will investigate the root cause later. > > -- > Thomas
[dpdk-dev] [PATCH v4 06/11] eal/linux/pci: Add functions for unmapping igb_uio resources
On 1/22/2015 6:16 PM, Tetsuya Mukawa wrote: > Hi Michael, > > On 2015/01/22 17:12, Qiu, Michael wrote: >> On 1/21/2015 6:01 PM, Tetsuya Mukawa wrote: >>> Hi Michael, >>> >>> On 2015/01/20 18:23, Qiu, Michael wrote: On 1/19/2015 6:42 PM, Tetsuya Mukawa wrote: > The patch adds functions for unmapping igb_uio resources. The patch is > only > for Linux and igb_uio environment. VFIO and BSD are not supported. > > v4: > - Add paramerter checking. > - Add header file to determine if hotplug can be enabled. > > Signed-off-by: Tetsuya Mukawa > --- > lib/librte_eal/common/Makefile | 1 + > lib/librte_eal/common/include/rte_dev_hotplug.h | 44 + > lib/librte_eal/linuxapp/eal/eal_pci.c | 38 +++ > lib/librte_eal/linuxapp/eal/eal_pci_init.h | 8 +++ > lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 65 > + > 5 files changed, 156 insertions(+) > create mode 100644 lib/librte_eal/common/include/rte_dev_hotplug.h > > diff --git a/lib/librte_eal/common/Makefile > b/lib/librte_eal/common/Makefile > index 52c1a5f..db7cc93 100644 > --- a/lib/librte_eal/common/Makefile > +++ b/lib/librte_eal/common/Makefile > @@ -41,6 +41,7 @@ INC += rte_eal_memconfig.h rte_malloc_heap.h > INC += rte_hexdump.h rte_devargs.h rte_dev.h > INC += rte_common_vect.h > INC += rte_pci_dev_feature_defs.h rte_pci_dev_features.h > +INC += rte_dev_hotplug.h > > ifeq ($(CONFIG_RTE_INSECURE_FUNCTION_WARNING),y) > INC += rte_warnings.h > diff --git a/lib/librte_eal/common/include/rte_dev_hotplug.h > b/lib/librte_eal/common/include/rte_dev_hotplug.h > new file mode 100644 > index 000..b333e0f > --- /dev/null > +++ b/lib/librte_eal/common/include/rte_dev_hotplug.h > @@ -0,0 +1,44 @@ > +/*- > + * BSD LICENSE > + * > + * Copyright(c) 2015 IGEL Co.,LTd. > + * 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 IGEL Co.,Ltd. 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. > + */ > + > +#ifndef _RTE_DEV_HOTPLUG_H_ > +#define _RTE_DEV_HOTPLUG_H_ > + > +/* > + * determine if hotplug can be enabled on the system > + */ > +#if defined(RTE_LIBRTE_EAL_HOTPLUG) && defined(RTE_LIBRTE_EAL_LINUXAPP) As you said, VFIO should not work with it, so does it need to add the vfio check here? >>> Could I have a advice of you? >>> First I guess it's the best to include "eal_vfio.h" here, and add >>> checking of VFIO_PRESENT macro. >> I have a question, will your hotplug feature support freebsd ? >> >> If not, how about to put it in "lib/librte_eal/linuxapp/eal/" ? Also >> include attach or detach affairs. > I appreciate your comments. > > So far, FreeBSD doesn't support PCI hotplug. So I didn't implement code > for FreeBSD. > But in the future, I want to implement it when FreeBSD supports it. > Also my hotplug implementation depends on legacy code already > implemented in common layer. > Anyway, for me it's nice to implement the feature in common layer. > >>> But it seems I cannot reach "eal_vfio.h" from this file. >> Yes, you can't :) >> >>> My second option is just checking
[dpdk-dev] [PATCH v1 02/15] eal: new eal option '--lcores' for cpu assignment
> -Original Message-
> From: Richardson, Bruce
> Sent: Thursday, January 22, 2015 8:19 PM
> To: Liang, Cunming
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1 02/15] eal: new eal option '--lcores' for
> cpu
> assignment
>
> On Thu, Jan 22, 2015 at 04:16:25PM +0800, Cunming Liang wrote:
> > It supports one new eal long option '--lcores' for EAL thread cpuset
> > assignment.
> >
> > The format pattern:
> > --lcores='lcores[@cpus]<,lcores[@cpus]>'
> > lcores, cpus could be a single digit or a group.
> > '(' and ')' are necessary if it's a group.
> > If not supply '@cpus', the value of cpus uses the same as lcores.
> >
> > e.g. '1,2@(5-7),(3-5)@(0,2),(0,6)' means starting 7 EAL thread as below
> > lcore 0 runs on cpuset 0x41 (cpu 0,6)
> > lcore 1 runs on cpuset 0x2 (cpu 1)
> > lcore 2 runs on cpuset 0xe0 (cpu 5,6,7)
> > lcore 3,4,5 runs on cpuset 0x5 (cpu 0,2)
> > lcore 6 runs on cpuset 0x41 (cpu 0,6)
> >
>
> This strikes me as very confusing, though a couple of tweaks might help with
> readability. The lcore 0 at the end is especially confusing. Perhaps we can
> limit the allowed formats here,
> * require the lcore_id to be specified - the lack of an lcore id for the last
> part
> makes having it as lcore 0 surprising.
> * only allow one lcore id to be given for each set of cores.
[Liang, Cunming] The last one lcore_set (0,6) without cpuset assigned is equal
to '(0,6)@(0,6)' or '0@(0,6), 6@(0,6)'.
It's not a typical use case but gives an aggressive sample, it shows the simple
way to explain the map.
>
> I think it may still be readable if we allow the core set to be omitted if its
> to be the same as the lcore_id.
>
> It's probably still not going to be very tidy, but I think we can improve
> things.
>
> /Bruce
>
> > Signed-off-by: Cunming Liang
> > ---
> > lib/librte_eal/common/eal_common_launch.c | 1 -
> > lib/librte_eal/common/eal_common_options.c | 262
> -
> > lib/librte_eal/common/eal_options.h| 2 +
> > lib/librte_eal/linuxapp/eal/Makefile | 1 +
> > 4 files changed, 261 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/eal_common_launch.c
> b/lib/librte_eal/common/eal_common_launch.c
> > index 599f83b..2d732b1 100644
> > --- a/lib/librte_eal/common/eal_common_launch.c
> > +++ b/lib/librte_eal/common/eal_common_launch.c
> > @@ -117,4 +117,3 @@ rte_eal_mp_wait_lcore(void)
> > rte_eal_wait_lcore(lcore_id);
> > }
> > }
> > -
> > diff --git a/lib/librte_eal/common/eal_common_options.c
> b/lib/librte_eal/common/eal_common_options.c
> > index e2810ab..fc47588 100644
> > --- a/lib/librte_eal/common/eal_common_options.c
> > +++ b/lib/librte_eal/common/eal_common_options.c
> > @@ -45,6 +45,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "eal_internal_cfg.h"
> > #include "eal_options.h"
> > @@ -85,6 +86,7 @@ eal_long_options[] = {
> > {OPT_XEN_DOM0, 0, 0, OPT_XEN_DOM0_NUM},
> > {OPT_CREATE_UIO_DEV, 1, NULL, OPT_CREATE_UIO_DEV_NUM},
> > {OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
> > + {OPT_LCORES, 1, 0, OPT_LCORES_NUM},
> > {0, 0, 0, 0}
> > };
> >
> > @@ -255,9 +257,11 @@ eal_parse_corelist(const char *corelist)
> > if (min == RTE_MAX_LCORE)
> > min = idx;
> > for (idx = min; idx <= max; idx++) {
> > - cfg->lcore_role[idx] = ROLE_RTE;
> > - lcore_config[idx].core_index = count;
> > - count++;
> > + if (cfg->lcore_role[idx] != ROLE_RTE) {
> > + cfg->lcore_role[idx] = ROLE_RTE;
> > + lcore_config[idx].core_index = count;
> > + count++;
> > + }
> > }
> > min = RTE_MAX_LCORE;
> > } else
> > @@ -289,6 +293,241 @@ eal_parse_master_lcore(const char *arg)
> > return 0;
> > }
> >
> > +/*
> > + * Parse elem, the elem could be single number or '(' ')' group
> > + * Within group elem, '-' used for a range seperator;
> > + *',' used for a single number.
> > + */
> > +static int
> > +eal_parse_set(const char *input, uint16_t set[], unsigned num)
> > +{
> > + unsigned idx;
> > + const char *str = input;
> > + char *end = NULL;
> > + unsigned min, max;
> > +
> > + memset(set, 0, num * sizeof(uint16_t));
> > +
> > + while (isblank(*str))
> > + str++;
> > +
> > + /* only digit or left bracket is qulify for start point */
> > + if ((!isdigit(*str) && *str != '(') || *str == '\0')
> > + return -1;
> > +
> > + /* process single number */
> > + if (*str != '(') {
> > + errno = 0;
> > + idx = strtoul(str, , 10);
> > + if (errno || end == NULL || idx >= num)
> > + return -1;
> > +
