From: Ben Hutchings <bhutchings@solarflare.com>
To: Yuehai Xu <yuehaixu@gmail.com>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>, <yhxu@wayne.edu>,
<sbw@mit.edu>
Subject: Re: How do I know my driver support RSS?
Date: Sun, 4 Mar 2012 22:23:57 +0000 [thread overview]
Message-ID: <1330899837.3022.17.camel@deadeye> (raw)
In-Reply-To: <CAEc1PS0OhdbVD_tUurNO2rk_w_VSewSNWirq2w6LwZCsZoBisQ@mail.gmail.com>
On Sat, 2012-03-03 at 23:30 -0500, Yuehai Xu wrote:
> On Sat, Mar 3, 2012 at 7:10 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> > On Sat, 2012-03-03 at 16:25 -0500, Yuehai Xu wrote:
> > [...]
> >> Since I read the following statements from a paper, "we use a separate
> >> hardware receive and transmit queue for each core and configure the
> >> IXGBE to inspect the port number in each incoming packet header, place
> >> the packet on the queue dedicated to the associated memcached's core,
> >> and deliver the receive interrupt to that core." and the background of
> >> this configuration is that each memcached is pinned to a separate core
> >> and has its own UDP port. It seems that IXGBE's driver can detect UDP
> >> packets according to their port numbers and put these packets into
> >> corresponding receive queues in the hardware, is this achieved by
> >> configuring RSS in IXGBE? If it is, I am wondering whether bnx2
> >> supports RSS and whether it can configure in the same way.
> >>
> >> I appreciate any help for this.
> >
> > You're confusing RSS (flow hashing) with flow steering. These are both
> > explained in Documentation/network/scaling.txt.
> >
> > Ben.
> >
> I appreciate your replying!! What confuses me is that for each UDP
> socket with exclusive port number, it has RX queue in transport layer,
> and network card might also have multiple RX queues. These two queues
> are definitely different. So, is it possible to configure network card
> to put packets to queues(RX queues in network card) according to hash?
Yes.
> I read the codes of RPS/RFS, it seems that packets are put into queues
> in transport layer of sockets instead of queues in network card. Am I
> correct?
>
> I appreciate any replies.
No, that's not right. There are also per-CPU queues of packets to be
processed. So a packet can go from the port into a hardware RX queue,
then to a per-CPU queue for protocol processing on that CPU, then to a
per-socket queue. By default, the protocol processing for a packet will
be done on the same CPU that took it off the hardware queue, but RPS and
RFS can transfer packets to other per-CPU queues. It is possible to
improve on this with the hardware flow steering mechanisms discussed in
that document.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
prev parent reply other threads:[~2012-03-04 22:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-03 21:25 How do I know my driver support RSS? Yuehai Xu
2012-03-04 0:10 ` Ben Hutchings
2012-03-04 4:30 ` Yuehai Xu
2012-03-04 22:23 ` Ben Hutchings [this message]
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=1330899837.3022.17.camel@deadeye \
--to=bhutchings@solarflare.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sbw@mit.edu \
--cc=yhxu@wayne.edu \
--cc=yuehaixu@gmail.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).