DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stefan Baranoff <sbaranoff@gmail.com>
To: Ivan Boule <ivan.boule@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Redirection Table
Date: Tue, 7 Jan 2014 08:03:56 -0500	[thread overview]
Message-ID: <CAHzKxpY3x_wO39aav90x+AQ55s9zJKG4_D=ePJHY8xbk3DZ1vw@mail.gmail.com> (raw)
In-Reply-To: <52CBBC6F.6030401@6wind.com>

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?

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?

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@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@6wind.com<mailto:
>> ivan.boule@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
>
>

  reply	other threads:[~2014-01-07 13:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-31 19:45 Michael Quicquaro
2014-01-06 15:21 ` Ivan Boule
2014-01-06 16:52   ` Michael Quicquaro
2014-01-07  8:35     ` Ivan Boule
2014-01-07 13:03       ` Stefan Baranoff [this message]
2014-01-10 10:14         ` Ivan Boule

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHzKxpY3x_wO39aav90x+AQ55s9zJKG4_D=ePJHY8xbk3DZ1vw@mail.gmail.com' \
    --to=sbaranoff@gmail.com \
    --cc=dev@dpdk.org \
    --cc=ivan.boule@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).