Thanks for your reply. I issue is, that I do have different source IP and destination IP ( different VLANs for client and PPPoE server ) on layer 2. According to data sheet, this falls under IPv4 rule ( page 237 of DS ). This rule should parse L2 header and hash it.
Configuration is the following ( sorry for not posting it before ): Client has VLAN 2 and VLAN 3. IPs with mask /30. Server has VLAN 2 and VLAN 3 and 2 PPPoE servers running on each of them. IPs with mask /30. IP addressing inside PPPoE doesn't matter, since it's Layer 4. RSS hash should be different for each of the VLANs, isn't it? BTW I tried the same without VLANs, using different MACs ( macvlan functionality ) and different IPs. Issue is the same. That's why I think it's a bug in hashing function or in modification of MRQC register from driver side. Also I've tried to modify driver and leave in MRQC only IPV4 rule for hashing. Didn't help either. Regarding VMDq: in previous emails I've reported that it's not starting for me, so I do not know how to proceed. And the other question is: how to use them in production? In production I will have 2-3 VLANs, with lot of unknown ( to NIC ) MAC addresses. How to balance the traffic in this case? Hopefully you will be able to help in this. Thank you. ----- Original Message ----- > From: "Todd Fujinaka" <todd.fujin...@intel.com> > To: "Jack Spinov" <spi...@timegroup.ae>, "Donald C Skidmore" > <donald.c.skidm...@intel.com> > Cc: e1000-devel@lists.sourceforge.net > Sent: Thursday, May 15, 2014 8:25:31 PM > Subject: RE: [E1000-devel] ixgbe: how to balance PPPoE traffic via RSS > to multiple queues > > 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
