On 01/07/2014 02:03 PM, Stefan Baranoff wrote: > > All, > > Does this mean that an application looking at traffic in something > like an IP/IP or GRE tunnel with only two endpoints on the tunnels but > many clients behind them must do software load balancing as the > packets would IP only (not TCP/UDP) with the same two addresses? > Yes, your understanding is correct, when Intel's NICs are used. But some other NICs could allow deeper packet analysis. When NICs only support IPv4/IPv6 RSS, then it is up to the network stack on top of the DPDK to provide the best optimal solution in software.
> How much of a penalty is there for crossing processor boundaries in > that case and might a 1 CPU server, while less core dense, actually > give better performance/watt? > This is hard to say. It is likely to partially depend on the CPU/memory/bus/ characteristics. Note that if you consider dedicating a single core to the polling of packets received on all ports, then you only need a single RX queue per port. By the way, in such a case, you can still configure RSS on the ports, so that the hardware computes the 32-bit RSS hash on each IP packet (it is stored into the rte_mbuf structure by the Poll Mode Driver), so that the RSS hash can be used in software to speed-up the assignment of IP packets to [a subset of] processing cores, if needed. Regards Ivan > Thanks, > Stefan > > Sent from my smart phone; people don't make typos, Swype does! > > On Jan 7, 2014 3:36 AM, "Ivan Boule" <ivan.boule at 6wind.com > <mailto:ivan.boule at 6wind.com>> wrote: > > On 01/06/2014 05:52 PM, Michael Quicquaro wrote: > > Thanks for the details. Can the hash function be modified so > that I can provide my own RSS function? i.e. my ultimate > goal is to provide RSS that is not dependent on packet contents. > > No, the RSS function is "hard-wired" and only works on IPv4/IPv6 > packets. All other packets are stored in the same queue (0 by > default). > You can change the RSS key used by the RSS function to compute the > hash value. > See the following testpmd command: > > port config X rss-hash-key <80 hexa digits> > > to set the 320-bit RSS key of port X. > > Best regards, > Ivan > > You may have seen my thread "generic load balancing". At this > point, I'm realizing that the only way to accomplish this is > to let the packets land where they may (the queue where the > NIC places the packet) and distribute them (to other queues) > by having some of the CPU processing devoted to this task. > Can you verify this? > > Regards, > - Michael. > > > On Mon, Jan 6, 2014 at 10:21 AM, Ivan Boule > <ivan.boule at 6wind.com <mailto:ivan.boule at 6wind.com> > <mailto:ivan.boule at 6wind.com <mailto:ivan.boule at 6wind.com>>> > wrote: > > On 12/31/2013 08:45 PM, Michael Quicquaro wrote: > > Has anyone used the "port config all reta (hash,queue)" > command of testpmd > with any success? > > I haven't found much documentation on it. > > Can someone provide an example on why and how it was used. > > Regards and Happy New Year, > Michael Quicquaro > > Hi Michael, > > "RETA" stands for Redirection Table. > It is a per-port configurable table of 128 entries that is > used by the > RSS filtering feature of Intel 1GbE and 10GbE controllers to > select the > RX queue into which to store a received IP packet. > When receiving an IPv4/IPv6 packet, the controller > computes a 32-bit > hash on: > > * the source address and the destination address of the > IP header of > the packet, > * the source port and the destination port of the UDP/TCP > header, if any. > > Then, the controller takes the 7 lower bits of the RSS > hash as an > index > into the RETA table to get the RX queue number where to > store the > packet. > > The API of the DPDK includes a function that is exported > by Poll Mode > Drivers to configure RETA entries of a given port. > > For test purposes, the testpmd application includes the > following > command > > "port config X rss reta (hash,queue)[,(hash,queue)]" > > to configure RETA entries of a port X, with each couple > (hash,queue) > contains the index of a RETA entry (between 0 and 127 > included) > and the > RX queue number (between 0 and 15) to be stored into that > RETA entry. > > Best regards > Ivan > > -- Ivan Boule > 6WIND Development Engineer > > > > > -- > Ivan Boule > 6WIND Development Engineer > -- Ivan Boule 6WIND Development Engineer
