I check the code, there is a macro RX_WTHRESH which was defined as 4, with the comment "/*< Default value of RX write-back threshold register. */". I don't know whether it is correlation with the problem. So I modify it to 0 in our code, but it doesn't take effect ether. then I check the code in i40e_rxtx.c, function i40e_dev_rx_queue_setup doesn't use this field(rx_conf.rx_thresh), so I want to know this register is correlation with this problem or not, if yes, how to set this register?
Thank you very much!
Please refer to the website for Intel® Data Plane Development Kit (Intel® DPDK) at http://www.intel.com/content/dam/www/public/us/en/documents/release-notes/intel-dpdk-release-notes.pdf
On page 57 Section 8.6, there is a specific section on Latency adjustments.
If the issue still persist, there is a note in the guide :
All Intel® DPDK questions and technical problems including those regarding the Ethernet* Controllers for the Poll Mode Driver should be reported through the Intel®
Premier Support site http://premier.intel.com/premier or access your IBL account and click the Intel® Premier Support link to enter issues under the Product
Name “Data Plane Development Kit (DPDK)”,
Hope this info helps.
Thanks for your response. I have read section 8.6, and have try to modify the burst packets. but it is no effect.
There is another thread https://communities.intel.com/message/293478#293478 , which mentioned the same question.
It said the problem may correlation with some features of PF driver. But we use VF PMD driver, can we set something in VF to solve this problem?
if VF driver cannot solve this problem, then how to modify it in the Linux PF driver?
Thank you for your support.
You may contact Premier support for further assistance:
Visit http://premier.intel.com/premier or access your IBL account click the Intel® Premier Support link to enter issues
With regard to support on Intel Business Link, you may visit this website
Congratulations to solved this problem.
I met the similiar issues to you.
And I have set the DIS_AUTOMASK_N_MASK in I40E_GLINT_CTL in Linux driver( i40e_vsi_configure_msix of i40e_main.c), it have no effect on this problem.
Could you tell me the details that you modified, and does the latency still exist?
1 of 1 people found this helpful
First, I modified the VF driver, set RTE_LIBRTE_I40E_ITR_INTERVAL equals to 6, so in function i40evf_config_irq_map (located in i40e_ethdev_vf.c of dpdk lib), it will send 3 in I40E_VIRTCHNL_OP_CONFIG_IRQ_MAP message to PF. which means NoITR.
Second, in Linux PF driver, in function i40e_config_irq_link_list which process I40E_VIRTCHNL_OP_CONFIG_IRQ_MAP message,
I added following lines at last.
#define I40E_GLINT_CTL 0x0003F800
#define I40E_GLINT_CTL_DIS_AUTOMASK_N_MASK 0x4
/* Disable auto-mask on enabling of all none-zero interrupt */
wr32(hw, I40E_GLINT_CTL, I40E_GLINT_CTL_DIS_AUTOMASK_N_MASK);
In fact these lines are copied from dpdk pf driver, function i40e_vsi_queues_bind_intr in i40e_ethdev.c
after modifed, the latency disappeared, but I'm not sure is there any disadvantage exists.
Thanks for your detailed explanation.
I do the same setting as you in my iPXE VF driver and linux driver,but it doesn't work.
And I want to know the 3 you refered is PF or DPDK logs show or you calculate? (set RTE_LIBRTE_I40E_ITR_INTERVAL equals to 6)
And I think set ITR_INDX to NoITR that is bit3-4 in VFINT_DYN_CTLN or PFINT_DYN_CTLN register, I don't know how rxitr_idx reflect on it. Could you give me an explanation about it?
Thanks you very very much!