process 4 receive packets only after 4 tx packets processing happened

[jliu85]

Hi Sandy

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.

animy 撰写:

Hi,Sandy

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?

Regards!

Animy

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:

transmit

transmit

transmit

transmit

receive

receive

receive

receive

ping success!

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.

Sincerely,

Animy

[SYeo3]

Dear animy,

Thank you for your clarifications. I'll further check on this.

Also, I moved your post to a new thread so it won't mix up with the other issue.

Sincerely,

Sandy

[SYeo3]

Hi animy,

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.

Sincerely,

Sandy

[jliu85]

Hi Sandy,

• 1. ethtool output:

driver: i40e

version: 0.4.21-k

firmware-version: f4.22 a1.1 n04.24 e800013fd

bus-info: 0000:02:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: no

• 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):

Best regards!

Animy

[SYeo3]

Hi animy,

Thanks for the additional details. We'll check on this and will update you on our findings.

Sincerely,

Sandy

[SYeo3]

Hi animy,

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.

Sincerely,

Sandy

[jliu85]

Hi Sandy,

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.

Thanks,

Animy

[jliu85]

Hi Sandy,

I have test my driver after firmware and i40e linux driver updated and there is no chage in result.

driver: i40e

version: 1.2.38

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

Thanks,

Animy

[SYeo3]

Hi Animy,

Thank you for posting the test results. We'll further check on this issue.

Sincerely,

Sandy

[st4]

Hi Animy,

Please help dump the interrupt info from /proc/interrupts to a file like below:

# grep –H i40e /proc/interrupts > dumpfile

Please provide the output to us.

rgds,

wb

[jliu85]

Hi Wb,

Thanks for your post.

We have solved this problem by updating the firmware and clearing the DIS_AUTOMASK_N flag in the GLINT_CTL register in i40e-1.2.38.

Thanks for your help again.

Best Regards,

Animy

[st4]

Hi Animy,

Glad to know the issue is resolved.

rgds,

wb