[Bug 895] dpdk 18.11 ip_pipeline ：One to one forwarding processing mode appear CPU 0 is 100% of interrupted

[Bug 895] dpdk 18.11 ip_pipeline ：One to one forwarding processing mode appear CPU 0 is 100% of interrupted

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=895

            Bug ID: 895
           Summary: dpdk 18.11 ip_pipeline ：One to one forwarding
                    processing mode appear CPU 0 is 100% of interrupted
           Product: DPDK
           Version: 18.11
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: dyl_wlc@163.com
  Target Milestone: ---

Hello, I used the ip_pipeline program of 18.11 dpdk and made it flow 1GB/s. I
found that the 0-core CPU occupies very high (usleep has been added in the for
loop of the ip_pipeline main function, which should not occupy very high CPU).

This is my hardware information:

    CPU model : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
    Network card model and version : i40e 1.5.10-k, two card
    Network card firmware : 6.01 0x8000372b 0.0.0

Modified ip_pipeline main function :

        /* Script */
        if (app.script_name)
            cli_script_process(app.script_name,
                app.conn.msg_in_len_max,
                app.conn.msg_out_len_max);
        #include <unistd.h>
        /* Dispatch loop */
        for ( ; ; ) {
            conn_poll_for_conn(conn);
            usleep(5000);
            conn_poll_for_msg(conn);
            kni_handle_request();
        }

CLI startup parameters:
    ./ip_pipeline -c f -- -s ./l2fwd.cli

CLI content:

    mempool MEMPOOL0 buffer 2304 pool 32K cache 256 cpu 0

    link LINK0 dev 0000:03:00.1 rxq 1 128 MEMPOOL0 txq 1 512 promiscuous on
    link LINK1 dev 0000:03:00.0 rxq 1 128 MEMPOOL0 txq 1 512 promiscuous on
    ;link LINK2 dev 0000:06:00.0 rxq 1 128 MEMPOOL0 txq 1 512 promiscuous on
    ;link LINK3 dev 0000:06:00.1 rxq 1 128 MEMPOOL0 txq 1 512 promiscuous on

    pipeline PIPELINE0 period 10 offset_port_id 0 cpu 0

    pipeline PIPELINE0 port in bsz 32 link LINK0 rxq 0
    pipeline PIPELINE0 port in bsz 32 link LINK1 rxq 0
    ;pipeline PIPELINE0 port in bsz 32 link LINK2 rxq 0
    ;pipeline PIPELINE0 port in bsz 32 link LINK3 rxq 0

    pipeline PIPELINE0 port out bsz 32 link LINK0 txq 0
    pipeline PIPELINE0 port out bsz 32 link LINK1 txq 0
    ;pipeline PIPELINE0 port out bsz 32 link LINK2 txq 0
    ;pipeline PIPELINE0 port out bsz 32 link LINK3 txq 0

    pipeline PIPELINE0 table match stub
    pipeline PIPELINE0 table match stub
    ;pipeline PIPELINE0 table match stub
    ;pipeline PIPELINE0 table match stub

    pipeline PIPELINE0 port in 0 table 0
    pipeline PIPELINE0 port in 1 table 1
    ;pipeline PIPELINE0 port in 2 table 2
    ;pipeline PIPELINE0 port in 3 table 3

    thread 1 pipeline PIPELINE0 enable

    pipeline PIPELINE0 table 0 rule add match default action fwd port 1
    pipeline PIPELINE0 table 1 rule add match default action fwd port 0
    ;pipeline PIPELINE0 table 2 rule add match default action fwd port 3
    ;pipeline PIPELINE0 table 3 rule add match default action fwd port 2

I have done these tests

    1. Using the i40e device of E5-2620 CPU to perform the same test, there is
no such problem

    2. I still use the i7-6700 i40e device, and I rolled back to the 18.05
version for testing, there is no such problem.

    3. The fallback code locates the code node that causes this problem as
4205c7ccec4fc2aeafe3e7ccf6b028d9476fccaf, this node had no problems before, and
there were problems afterwards.

    4. I found that there are two kernel modules on this i7-6700 device:
idma64, i2c_designware, when I uninstall these two modules, this phenomenon
will not appear.
    5. On the basis of 18.11, in the i40e_dev_start function

            if (dev->data->dev_conf.intr_conf.rxq == 0) {
                rte_eal_alarm_set(I40E_ALARM_INTERVAL,

                        i40e_dev_alarm_handler, dev);
            } else {
                /* enable uio intr after callback register */
                rte_intr_enable(intr_handle);
            }

        Change to

            /* enable uio intr after callback register */
            rte_intr_enable(intr_handle);

            if (dev->data->dev_conf.intr_conf.rxq == 0) {
                rte_eal_alarm_set(I40E_ALARM_INTERVAL,
                        i40e_dev_alarm_handler, dev);
            }

        Then this problem will not occur.

From the above scene, if I want to use the 18.11 dpdk version normally, I will
either uninstall the module or add rte_intr_enable, but I don’t know what will
happen if I do this? Can you answer me? Is this a bug?

-- 
You are receiving this mail because:
You are the assignee for the bug.