[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.040 / U:2.988 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site