Sorry, givven offsets in different dimensions. PPPoE src IP starts at 184 bit, dst IP starts at 216, instead of 96 and 128 respectively.
Just to correct myself. ----- Original Message ----- > From: "Jack Spinov" <spi...@timegroup.ae> > To: "Donald C Skidmore" <donald.c.skidm...@intel.com> > Cc: e1000-devel@lists.sourceforge.net > Sent: Friday, May 16, 2014 11:14:36 AM > Subject: Re: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS to > multiple queues > > Thanks for your reply, Donald. > > Looks like you're right. Src IP offset starts at 23 bit and Dst IP at > 27. Instead of 12 and 16. > > Just a rhetoric question: why not to have hash function on MAC? > > And not rhetoric: how to balance damn PPPoE traffic? > > BTW I didn't had any issue balancing such traffic on 82579. > Everything worked perfectly. > > ----- Original Message ----- > > From: "Donald C Skidmore" <donald.c.skidm...@intel.com> > > To: "Jack Spinov" <spi...@timegroup.ae> > > Cc: e1000-devel@lists.sourceforge.net > > Sent: Friday, May 16, 2014 12:00:10 AM > > Subject: RE: [E1000-devel] ixgbe: how to balance PPPoE traffic via > > RSS to multiple queues > > > > I might be misunderstanding what you're trying to do here, but the > > reason you're going to queue 0 is that you are tunneling over > > PPPoE. > > Because of this all of the offsets that the HW expects are no > > longer correct so it can't hash on the IPv4, IPv4_TCP and if UDP > > fields RSS needs. > > > > Thanks, > > -Don Skidmore <donald.c.skidm...@intel.com> > > > > > -----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
