At 22:13 1/13/2014 +0000, Skidmore, Donald C wrote: >Hey David, > >I'm sure what you mean by the "Low Latency Polling >patch", but I'm guessing it refers to the busy >poll sockets that we recently pushed upstream. >Please correct me if I'm wrong.
Hi Don, Thank you very much for your reply. Yes, I'm referring this patch, the LWN article about it refers to it in similar fashion http://lwn.net/Articles/551284/ >Given that I believe you could set up perfect >filter rules (via. ethtool --config-ntuple) to >direct certain UDP port packets to a given queue, Would like to do this programmatically, can the API used by 'ethtool' be employed or does a better alternative exists? I did a quick check with an igb/82576 (target ixgbe/82599 not available just now) and saw an error: $ ethtool --show-ntuple eth6 6 RX rings available rxclass: Cannot get RX class rule count: Operation not supported RX classification rule retrieval failed $ ethtool -i eth6 driver: igb version: 5.1.2 firmware-version: 1.5.3 bus-info: 0000:02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no $ uname -r 3.10.27 >pin that queue to a CPU and run your busy poll >socket on that CPU. All that said I have never >done this myself but I can't think of any reason >it wouldn't work. How does one bind a particular interface queue to a socket in PF_PACKET or PF_RING as opposed to the entire interface? I am familiar with creating 'rc.local' scripts to map specific queue IRQs to particular cores and have code for binding poll-wait threads to cores. >I'm also a little confused by your concern that >our rings can only hold (64k) PKT_LEN in the >advanced descriptor (I'm assuming this is what you >meant by '16-bit ring limit'). This value just >holds the number of bytes in a packet buffer. >Packets that exceed this would be in multiple >descriptors on the same queue. So the queue could >handle bursts over 64k. Or this there some reason >your implementation needs the complete packet in >one descriptor? Packets are all <=1500 bytes. I'm referring to the silicon-based packet ring mappings as shown here: $ ethtool -g eth6 Ring parameters for eth6: Pre-set maximums: RX: 32768 RX Mini: 0 RX Jumbo: 0 TX: 32768 Current hardware settings: RX: 32768 RX Mini: 0 RX Jumbo: 0 TX: 32768 I've hacked the 32k limit into the drivers here and would go to 64k except for concerns about the code handling 16-bit index wraps. The place where this is described in the 82599 silicon documentation under 8.2.3.8.4 Receive Descriptor Head 8.2.3.8.5 Receive Descriptor Tail RDH & RDT BITS 15:0 descriptor index reserved BITS 31:16 The above is not a concern in the context of using the regular Intel drivers with the low-latency patch as the kernel handles the situation where data gets ahead of the socket consumer by generating interrupts and causing the normal transfer of packets into SKBs and queuing them to the socket. But it matters in a kernel bypass scenario where user space is managing the silicon ring queue directly. I suppose the application can swap in new buffer descriptors if it falls behind in processing data so that the effective packet backlog can exceeded 64k. David > >> -----Original Message----- >> From: David Lawless [mailto:[email protected]] >> Sent: Thursday, January 09, 2014 7:23 PM >> To: [email protected] >> Subject: [E1000-devel] ixgbe/82599 + Flow Director >> + Low Latency Polling patch >> >> Hello, >> >> Is it possible with ixgbe/82599 to use >> Flow Director to map traffic to particular >> 82599 queues and then use either PF_PACKET >> sockets or the PF_RING >> capability to busy-poll a thread on each queue? >> >> Need to receive traffic from several different >> UDP ports together so the only solution I'm >> aware of is to read raw frames. >> >> Need to be able to have particular threads >> operate exclusively on particular >> queues. >> >> Have this working with Myricom DBL, but >> would be nice do accomplish it with >> 'ixgbe'. The goal, of course, is to read data >> without interrupts or context switches. >> >> ----- >> >> Does the newer Intel 10G silicon support ring queues >> larger than 65535 entries? >> If so one could use PF_RING to access the hardware >> directly while avoiding data loss from traffic bursts. >> That 16-bit ring limit in the 82599 is a killer. >> >> Thanks! >> >> David >> ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ 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
