[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTScYMPUsf0+67FAU0LBfuxhGT8JKyvL1WX=Rjomno75q2A@mail.gmail.com>
Date: Tue, 21 May 2013 10:30:53 -0400
From: Willem de Bruijn <willemb@...gle.com>
To: Eliezer Tamir <eliezer.tamir@...ux.intel.com>
Cc: Alex Rosenbaum <alexr@...lanox.com>,
Dave Miller <davem@...emloft.net>,
linux-kernel <linux-kernel@...r.kernel.org>,
netdev@...r.kernel.org,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Don Skidmore <donald.c.skidmore@...el.com>,
e1000-devel <e1000-devel@...ts.sourceforge.net>,
Andi Kleen <andi@...stfloor.org>, HPA <hpa@...or.com>,
Eliezer Tamir <eliezer@...ir.org.il>
Subject: Re: [PATCH v3 net-next 0/4] net: low latency Ethernet device polling
>> 2. How is the logic aware of RSS and RFS?
>>
>> With TCP sockets, the driver knows the specific ring it need to poll so
>> this should be mapped and provide the best latency.
>
>
> This code is blissfully oblivious of RFS and RSS, it only assumes that the
> packets for a socket are likely to continue to come on the same queue.
> The code is designed to be correct even if you get your data on the wrong
> queue. (your performance will suffer but no more than that.)
>
For low latency, you don't want to have to wait for the IPI that RPS
sets to redirect packets to another CPU. However, this feature works
extremely well with hardware flow steering (nfc/ntuple) and
accelerated RFS, where the device will enqueue directly on an rxqueue
owned exclusively by the destination cpu (if configured correctly).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists