Hi Emil, The size of UDP packets is quite small, so they should not be fragmented.
16:52:30.908413 IP 10.69.0.1.18890 > 10.69.9.81.3000: UDP, length 96 16:52:30.908425 IP 10.69.0.1.42398 > 10.69.9.81.3000: UDP, length 96 16:52:30.908632 IP 10.69.0.1.44382 > 10.69.9.81.3000: UDP, length 96 16:52:30.908669 IP 10.69.0.1.44298 > 10.69.9.81.3000: UDP, length 96 16:52:30.908817 IP 10.69.0.1.44294 > 10.69.9.81.3000: UDP, length 96 16:52:30.908830 IP 10.69.0.1.19994 > 10.69.9.81.3000: UDP, length 96 16:52:30.908890 IP 10.69.0.1.41230 > 10.69.9.81.3000: UDP, length 96 16:52:30.908976 IP 10.69.0.1.44918 > 10.69.9.81.3000: UDP, length 96 16:52:30.909079 IP 10.69.0.1.41194 > 10.69.9.81.3000: UDP, length 96 16:52:30.909083 IP 10.69.0.1.13918 > 10.69.9.81.3000: UDP, length 96 16:52:30.909206 IP 10.69.0.1.18430 > 10.69.9.81.3000: UDP, length 96 16:52:30.909239 IP 10.69.0.1.42426 > 10.69.9.81.3000: UDP, length 96 16:52:30.909332 IP 10.69.0.1.44942 > 10.69.9.81.3000: UDP, length 96 16:52:30.909409 IP 10.69.0.1.44398 > 10.69.9.81.3000: UDP, length 96 16:52:30.909598 IP 10.69.0.1.42326 > 10.69.9.81.3000: UDP, length 96 16:52:30.909707 IP 10.69.0.1.44982 > 10.69.9.81.3000: UDP, length 96 16:52:30.909722 IP 10.69.0.1.42354 > 10.69.9.81.3000: UDP, length 96 16:52:30.909759 IP 10.69.0.1.44898 > 10.69.9.81.3000: UDP, length 96 16:52:30.909761 IP 10.69.0.1.42278 > 10.69.9.81.3000: UDP, length 96 16:52:30.909768 IP 10.69.0.1.44426 > 10.69.9.81.3000: UDP, length 96 16:52:30.909928 IP 10.69.0.1.19814 > 10.69.9.81.3000: UDP, length 96 16:52:30.909942 IP 10.69.0.1.19906 > 10.69.9.81.3000: UDP, length 96 16:52:30.910067 IP 10.69.0.1.19866 > 10.69.9.81.3000: UDP, length 96 16:52:30.910104 IP 10.69.0.1.19982 > 10.69.9.81.3000: UDP, length 96 16:52:30.910170 IP 10.69.0.1.16226 > 10.69.9.81.3000: UDP, length 96 16:52:30.910301 IP 10.69.0.1.44990 > 10.69.9.81.3000: UDP, length 96 16:52:30.910305 IP 10.69.0.1.44322 > 10.69.9.81.3000: UDP, length 96 16:52:30.910505 IP 10.69.0.1.44282 > 10.69.9.81.3000: UDP, length 96 16:52:30.910581 IP 10.69.0.1.18446 > 10.69.9.81.3000: UDP, length 96 16:52:30.910604 IP 10.69.0.1.42474 > 10.69.9.81.3000: UDP, length 96 16:52:30.910616 IP 10.69.0.1.42286 > 10.69.9.81.3000: UDP, length 96 16:52:30.910628 IP 10.69.0.1.44266 > 10.69.9.81.3000: UDP, length 96 16:52:30.910690 IP 10.69.0.1.13892 > 10.69.9.81.3000: UDP, length 96 16:52:30.910770 IP 10.69.0.1.16134 > 10.69.9.81.3000: UDP, length 96 16:52:30.911145 IP 10.69.0.1.16210 > 10.69.9.81.3000: UDP, length 96 16:52:30.911316 IP 10.69.0.1.13934 > 10.69.9.81.3000: UDP, length 96 In Intel 82599 10 Gbe Controller Datasheet, it tells, " Enabling rules: * RSS is enabled in the MRQC register. * |>***********RSS enabling cannot be done dynamically while it must be preceded by a software reset.************<| * RSS status field in the descriptor write-back is enabled when the RXCSUM.PCSD bit is set (fragment checksum is disabled). RSS is therefore mutually exclusive with UDP fragmentation checksum offload. * Support for RSS is not provided when legacy receive descriptor format is used. " Before we execute the command " ethtool -N fi0 rx-flow-hash udp4 sdfn " Register MRQC has value 330001 0x05818: MRQC (Multiple Rx Queues Command) 0x00330001 After we execute the command, Register MRQC has value 730001 0x05818: MRQC (Multiple Rx Queues Command) 0x00330001 I wonder, should we do any software reset after executing the above command? And how to do a software reset? Please advice... Br,Lane -----Original Message----- From: ext Tantilov, Emil S [mailto:[email protected]] Sent: Thursday, June 12, 2014 2:32 AM To: Xu, Gang 1. (NSN - CN/Hangzhou); [email protected] Cc: Ni, Zhenglin (NSN - CN/Hangzhou); Liu, Xin 9. (NSN - CN/Hangzhou); Ouyang, Lane (NSN - CN/Hangzhou); Yan, Liming (NSN - CN/Hangzhou); Liu, Zuofeng (NSN - CN/Hangzhou) Subject: RE: [E1000-devel] Need Help about UDP multiple receive queue >-----Original Message----- >From: Xu, Gang 1. (NSN - CN/Hangzhou) >[mailto:[email protected]] >Sent: Sunday, June 08, 2014 10:52 PM >To: [email protected] >Cc: Ni, Zhenglin (NSN - CN/Hangzhou); Liu, Xin 9. (NSN - >CN/Hangzhou); Ouyang, Lane (NSN - CN/Hangzhou); Yan, Liming >(NSN - CN/Hangzhou); Liu, Zuofeng (NSN - CN/Hangzhou) >Subject: [E1000-devel] Need Help about UDP multiple receive >queue > >Hi, > > We try to enable the UDP multiple receiving queue by >"ethtool -N fi0 rx-flow-hash udp4 sdfn" command, >but after this command executed, all udp packets with >different soured udp port still allocated to the same rx >queue 0. Other rx queues are nearly empty, and then this >only processed by one CPU core(load 100%) and other cores >are nearly 0, we can not get the maximum packets through >out. > >Our question: >1. How to assign the udp packets with different udp >source ports to different rx queues ? The command you used above should work, however keep in mind that only packets that are not fragmented will be given an RSS hash by the HW. You can check your traffic via tcpdump - if your UDP packets are fragmented they will not be assigned different queues by RSS. Some things you may be able to do is increase the MTU, or in the case of multicast (if you are doing receives only) you can have the transmitting app spoof the src port in order to generate a different hash for each packet (because the dst IP/port info is lost for the HW if the packet is fragmented). Thanks, Emil ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
