ContributionsMost RecentMost LikesSolutionsN3000 bind pcie leads the server reboot Recently, our two servers which installed N3000-1 and N3000-2 respectively meet the same questions. And both of the servers had been work correctly with N3000 for several months. Here are the main phenomenons: when burn the sof file with JTAG, the server would reboot in the page of burning and then you need burn it again when bind the pcie B:D:F of the FPGA,the servers would reboot as well; when use the command of “sudo rsu bmcimg”, the servers would reboot. Actually,the two servers are used by different people and they do not use the other machine. The log shows that the occurrence of reboot dues to the release of interrupt. We tried to uninstall the opae packages, and the machine would not reboot now. However, it makes that the functions of opae are unavailable, which is not the best option. Anyone knows why and any least expensive solutions ? Thanks! Is there any limitation on N3000-2 XL710 We produce some packets as we want by dpdk drivers and APIs. But we find when the 13byte of the packet header(which position is the eth pkt type) is 0x00 the packet would not be received. Does the XL710 in the N3000-2 board filter packets?For example, is there any limitations for the type field in the MAC header (position of 13 Byte), or does it automatically filter packets beyond certain types set? If there is such a limitation, can user change it? Re: How to make N3000 support jumbo frames? well, It's my pleasure to help others. 1. DPDK L3fwd supports jumbo frames originally when you run it with '--enable-jumbo --max-pkt-len 9600 '; 2.the default mtu size of N3000-1(10G) is 1500, one should change it to 9600, and you can get the command by looking in the manual of ug-ias-n3000(chapter 8.1); the default mtu size of N3000-2(25G) is 9600, it have no need to be changed. 3. you can modify the mode of rx and tx to support jumbo frames by reference to l3fwd CMD_LINE_OPT_ENABLE_JUMBO_NUM module For example, in the l2fwd application, you need to make the following changes Re: How to make N3000 support jumbo frames? Thank you for your continued attention. We have found that some dpdk application can fully support giant frame and we ported the related functions to other applications. So far the issue with giant frame support has been resolved. Re: How to make N3000 support jumbo frames? another problem is that I cannot check mtu size after bounding to dpdk Re: How to make N3000 support jumbo frames? ls -la /sys/class/net sudo ip link set dev enp61s0f0 mtu 9600 sudo ip link set dev enp61s0f1 mtu 9600 sudo ip link set dev enp64s0f0 mtu 9600 sudo ip link set dev enp64s0f1 mtu 9600 ip link show enp61s0f0 ip link show enp61s0f1 ip link show enp64s0f0 ip link show enp64s0f1 sudo fpgadiag -b 0b3f -m fpgamac --side=host --mtu then bound to dpdk Re: How to make N3000 support jumbo frames? The matter is that if I revert back to OPAE and set the MTU size again, the MTU of XL710 would be returned to the default value 1500 even though we set it to 9600 after bounding to vfio-pci driver in the mode of DPDK Re: How to establish communication between two N3000 cards or more cards in a host server? OK, I see. Thanks for your reply. Re: Intel N3000-2 FEC mode Thanks for your reply! We have changed the card to another server and the problem have been settled. Re: How to make N3000 support jumbo frames? Thanks for your reply! Actually we have checked the size of MTU of wrapper and modified it to 9600. The MTU of XL710 would be returned to the default value 1500 even though we set it to 9600 after bounding to vfio-pci driver in the mode of DPDK . But we could receive jumbo frames. The problem is the card can not forward jumbo frames. Using signal-tap we captured some signals and found that egr_out* signals are correct. Based on this, we can deduce XL710 and DPDK have no problem. So we think that there may exist some configurations in the path of egr_out* to QSFP, which limits the forwarding of jumbo frames. In the other experiment, we connected the ing_in*----egr_out* directly, and the forwarding of jumbo frames failed too. I think this is further confirmation that our consideration is right. The bottleneck is between egr_out and QSFP, and that's exactly what corresponds to nfv_eth_wrapper, mux, demux and some other modules in RTL project.