Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
1,728 Views

process 4 receive packets only after 4 tx packets processing happened

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

0 Kudos
11 Replies
Highlighted
Valued Contributor I
1 View

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

0 Kudos
Highlighted
Valued Contributor I
1 View

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

0 Kudos
Highlighted
Beginner
1 View

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

0 Kudos
Highlighted
Valued Contributor I
1 View

Hi animy,

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

Sincerely,

Sandy

0 Kudos
Highlighted
Valued Contributor I
1 View

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-Netw... NVM Update Utility.

Please let us know the results after updating the firmware.

Sincerely,

Sandy

0 Kudos
Highlighted
Beginner
1 View

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

0 Kudos
Highlighted
Beginner
1 View

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

0 Kudos
Highlighted
Valued Contributor I
1 View

Hi Animy,

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

Sincerely,

Sandy

0 Kudos
Highlighted
New Contributor III
1 View

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

0 Kudos
Highlighted
Beginner
1 View

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

0 Kudos
Highlighted
New Contributor III
1 View

Hi Animy,

Glad to know the issue is resolved.

rgds,

wb

0 Kudos