From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by dpdk.org (Postfix) with ESMTP id 629133F9 for ; Mon, 6 Jan 2014 17:51:24 +0100 (CET) Received: by mail-pd0-f170.google.com with SMTP id g10so18373514pdj.29 for ; Mon, 06 Jan 2014 08:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VniUMDIVTo68rCIlqpmpE9MZX0shk5YZ/qbuejD7XQ0=; b=pCDAkbrLfG9E+IoUSJDV1C+86+TbQdMRd2yZe6GD1e+8wsaNI806w09Rzgw99w6xz5 AqBtvtmX6tfZ7wfKg0A3oIWT2H/R4svFNjAu4DQ9+IsJm95fy72iRUKcBxnFrmFcHso0 ZwxLfOERwl2yX9Ek5zIeJ/ghv2W2K2ri9avsyepHAIlhpdqfhJZ3F3bcwNQwPRifwpZk L1vizEYFYWbKgrBotrtj1kMRtd7YVwAFWv/oYawp8BH7dEGO52sAyTaonqca82SjuVyW F+VpNe8LZ03MwShg9VCzu2KBKy504+2vGmHc1UXNCU1SJI4wOFid+0cWo9mL1eh92vbp N28Q== X-Received: by 10.68.134.98 with SMTP id pj2mr128377071pbb.110.1389027154648; Mon, 06 Jan 2014 08:52:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.131.225 with HTTP; Mon, 6 Jan 2014 08:52:14 -0800 (PST) In-Reply-To: <52CACA17.7000202@6wind.com> References: <52CACA17.7000202@6wind.com> From: Michael Quicquaro Date: Mon, 6 Jan 2014 11:52:14 -0500 Message-ID: To: Ivan Boule Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Redirection Table X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 16:51:25 -0000 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. 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 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 > >