I'm so sorry I didn't describe clearly and didn't give you the Ping details early.
The VF (iPXE) can ping the PF(Linux) successfully since the second tips.
Thanks for your reply.
The driver i used is based on Linux-kernel 3.17.6 and this problem have been solved by ignoring the protocol differences in transmit.
And there is a new problem occurred that shows as follows:
1. after transmit be called 4 times that process 4 transmit packets. (solved. we have fixed it to one transmit,one process tx packet).
2. process 4 receive packets only after 4 tx packets processing happened. (not solved)
i don't known where or what register makes the 4 receive packets be processed together after processing 4 tx packets.
Could you give me a help?
the problem iPXE logs show that only after four packets received, the DD bit in the receive descriptor WB format will be set.
and logs show as following format:
and the response time as follows:
64 bytes from 192.168.57.81: icmp_seq=4 ttl=64 time=3039 ms
64 bytes from 192.168.57.81: icmp_seq=5 ttl=64 time=2034 ms
64 bytes from 192.168.57.81: icmp_seq=6 ttl=64 time=1032 ms
64 bytes from 192.168.57.81: icmp_seq=7 ttl=64 time=35.0 ms
When I use VF(linux) ping PF(Linux),the average response time only be 0.03ms
If you have any other confusion about this issue description, please contact me. And I look forward to your ideas about this issue.
We would like to further understand your environment, please provide details below:
1. ethtool output
2. Network card model XL710 Series - is this our retail adapter or an onboard nic?
3. type/model of optic module used
We look forward to your updates.
- 1. ethtool output:
firmware-version: f4.22 a1.1 n04.24 e800013fd
- 2. Network card mode is XL710QDA1 and the card is retail adapter
lspci result is:
Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 01)
- 3. type/model of optic module used
no. Because our procurement is delayed, we have not get the optic model,and the module is on procure.
The method makes VF and PF communicating is by modifing the link status of NIC in PF. PF and VF can communicate with each other normally. The result of ping VF(Linux) from PF(Linux) is as follows(short response time,0.03ms):
Good day. Upon checking the info you've provided, we found that the adapter's firmware is quite old. We suggest to update the firmware on the adapter. The firmware is available here - https://downloadcenter.intel.com/download/24769/NVM-Update-Utility-for-Intel-Ethernet-Converged-Network-Adapter-XL710-X710-Series NVM Update Utility.
Please let us know the results after updating the firmware.
When i update adapter's firmware I met the problem
" Intel(R) Ethernet Converged Network Ad 8086-1584 02:00 Access error"
after execute the command
" ./nvmupdate64e -l nvmupdatelog.txt"
Could you tell me the reason may cause it.
And We have upate firmware versions in EFI successfuly.
I have test my driver after firmware and i40e linux driver updated and there is no chage in result.
firmware-version: f4.33.31377 a1.2 n4.42 e1930
the result ping VF(iPXE) from PF(Linux) is as follows:
64 bytes from 192.168.X.X: icmp_seq=38 ttl=64 time=3074 ms
64 bytes from 192.168.X.X: icmp_seq=39 ttl=64 time=2095 ms
64 bytes from 192.168.X.X: icmp_seq=40 ttl=64 time=1114 ms
64 bytes from 192.168.X.X: icmp_seq=41 ttl=64 time=124 ms
64 bytes from 192.168.X.X: icmp_seq=42 ttl=64 time=3070 ms
64 bytes from 192.168.X.X: icmp_seq=43 ttl=64 time=2090 ms
64 bytes from 192.168.X.X: icmp_seq=44 ttl=64 time=1101 ms
64 bytes from 192.168.X.X: icmp_seq=45 ttl=64 time=120 ms