RSS hashing is pretty simple. Do you have the same source and destination address and port? If so, you get one hash. I'm not sure what your packets look like, I've been told by those who know more about PPoE that you'll need to use VMDq.
I know there are other ways for traffic to be routed to the default queue (0) but I think in this case VMDq is the way to go. I am guessing that VMDq isn't trivial and I'll have to look into this some more for you. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -----Original Message----- From: Jack Spinov [mailto:spi...@timegroup.ae] Sent: Thursday, May 15, 2014 5:46 AM To: Skidmore, Donald C Cc: e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to multiple queues According to driver source code functions are executed in order ( I skipped IPv6 ): IPv4, IPv4_TCP and if UDP flow hashing is enabled - IPv4_UDP. If yes, then I do not understand, why hash function returns 0 ( i.e. assigns packets to 0 queue ) for PPPoE packets. Looks like a bug to me. ----- Original Message ----- > From: "Jack Spinov" <spi...@timegroup.ae> > To: "Donald C Skidmore" <donald.c.skidm...@intel.com> > Cc: e1000-devel@lists.sourceforge.net > Sent: Thursday, May 15, 2014 3:11:03 PM > Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to > multiple queues > > And one more thing. According to Data Sheet, RSS can properly parse > tunneled packets, treating them as IP packets. In this case hash is > built by SourceAddress and DestinationAddress. However, it's stated, > that in case RSS function failed to parse packet - function returns > zero. Without ntuple and Flow Director ( do not work for tunneled > packets ), this means, that packets will always go to queue 0, which > is my case. > > So the question is: is there a way to find out what functions RSS uses > to parse IP packets, i.e. value of MRQC register? And modify it. It > seems to me, that needed function for parsing is just not included > into check. Adding it will render RSS index assigned and packets will > be properly distributed among queues. Unicorns and rainbows. > > > > > > ----- Original Message ----- > > > From: "Jack Spinov" <spi...@timegroup.ae> > > > To: "Donald C Skidmore" <donald.c.skidm...@intel.com> > > > Cc: e1000-devel@lists.sourceforge.net > > > Sent: Thursday, May 15, 2014 12:37:47 PM > > > Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via > > > RSS to multiple queues > > > > > > Thanks for your reply. > > > > > > I'll try that for synthetic tests. But it's unclear what to do, in > > > case I will not have VLANs or will have just few in production? > > > VMDq > > > without virtual environment looks like workaround to me. > > > > > > Let's say server is BRAS with PPPoE server terminating client > > > sessions. Without PPPoE - everything is working as it should. > > > Once > > > PPPoE in effect - everything gets to queue 0. > > > > > > How can I configure VFs in this case? > > > > > > ----- Original Message ----- > > > > From: "Donald C Skidmore" <donald.c.skidm...@intel.com> > > > > To: "Jack Spinov" <spi...@timegroup.ae>, > > > > e1000-devel@lists.sourceforge.net > > > > Sent: Wednesday, May 14, 2014 9:05:27 PM > > > > Subject: RE: [E1000-devel] ixgbe: how to balance PPPoE traffic > > > > via > > > > RSS to multiple queues > > > > > > > > Maybe try VMDq which could sort by L2 (MAC address and VLAN). > > > > > > > > Thanks, > > > > -Don Skidmore <donald.c.skidm...@intel.com> > > > > > > > > > -----Original Message----- > > > > > From: Jack Spinov [mailto:spi...@timegroup.ae] > > > > > Sent: Tuesday, May 13, 2014 7:39 AM > > > > > To: e1000-devel@lists.sourceforge.net > > > > > Subject: [E1000-devel] ixgbe: how to balance PPPoE traffic via > > > > > RSS to multiple queues > > > > > > > > > > Hello, everyone. > > > > > > > > > > Have spent a lot of time trying to balance traffic into > > > > > multiple RSS queues, but traffic falls into same queue all the > > > > > time. I've read all the documents, threads I could find, but > > > > > still cannot find a way to solve my problem. > > > > > > > > > > My configuration: 3 servers with 82599 adapters. Connected > > > > > like > > > > > this: > > > > > > > > > > Packet generator ( PG )<--- 10G ---> Packet router ( PR )<--- > > > > > 10G > > > > > ---> Packet > > > > > dumper ( PD ) > > > > > > > > > > PG connects to PR via PPPoE and generates packets directed to > > > > > Packed dumper ( PG ). > > > > > > > > > > PR running 3.2.23 kernel and latest ixgbe 3.21.2. PG running > > > > > 3.12.18 and same > > > > > latest ixgbe 3.21.2, with default settings. I've generated > > > > > traffic using iperf, netperf, ping. For iperf, netperf, both > > > > > TCP and UDP - all goes to default queue - 0, while the rest 15 > > > > > are idle. As on receiving interface, as on sending for PR. In > > > > > case of using ping - everything is distributed properly. > > > > > Which is > > > > > another riddle for me. > > > > > > > > > > I've tried using macvlan ( different MACs on PR, PG ), vlans ( > > > > > different source IPs for PPPoE sessions, different destination > > > > > IP for PD ) - nothing helps. I cannot use Flow Director as > > > > > packets in tunneling are not analyzed by it ( as per DS ), > > > > > this is proved by ethtool counter for fdir* variable. > > > > > > > > > > So what are my options? And how to guarantee, that in > > > > > production environment I will not face the same issue? Or > > > > > probably I'm doing something wrong? > > > > > > > > > > Thanks in advance. > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------------- "Accelerate Dev Cycles with Automated > > > > > Cross-Browser Testing - For FREE Instantly run your Selenium > > > > > tests across 300+ browser/OS combos. > > > > > Get unparalleled scalability from the best Selenium testing > > > > > platform available Simple to use. Nothing to install. Get > > > > > started now for free." > > > > > http://p.sf.net/sfu/SauceLabs > > > > > _______________________________________________ > > > > > E1000-devel mailing list > > > > > E1000-devel@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/e1000-devel > > > > > To learn more about Intel® Ethernet, visit > > > > > http://communities.intel.com/community/wired > > > > > > > > > > ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
