[lkml]   [2012]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: How do I know my driver support RSS?
On Sat, 2012-03-03 at 23:30 -0500, Yuehai Xu wrote:
> On Sat, Mar 3, 2012 at 7:10 PM, Ben Hutchings <> 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?


> 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 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.

 \ /
  Last update: 2012-03-04 23:27    [W:0.041 / U:1.768 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site