On 08/25/2016 02:18 PM, Aaro Koskinen wrote:
Hi,
On Thu, Aug 25, 2016 at 01:11:45PM -0700, David Daney wrote:
On 08/25/2016 11:22 AM, Aaro Koskinen wrote:
On Thu, Aug 25, 2016 at 09:50:15AM -0700, David Daney wrote:
Ideally we would configure the packet classifiers on the RX side to create
multiple RX queues based on a hash of the TCP 5-tuple, and handle each queue
with a single NAPI instance. That should result in better performance while
maintaining packet ordering.
Would this need anything else than reprogramming CVMX_PIP_PRT_TAGX, and
eliminating the global pow_receive_group and creating multiple NAPI instances
and registering IRQ handlers?
That is essentially how it works. Set the tag generation parameters, and
use the low order bits of the tag to select which POW/SSO group is assigned.
The SSO group corresponds to an "rx queue"
OK, I will try to experiment with this. Even though my home routers are
2-core only I could still create more queues and verify that the traffic
gets distributed by checking the counters...
You will have to set proper SSO group masks, etc. when you do the get
work operation, and who knows what else.
Good Luck!
In the Yocto tree, the CVMX_PIP_PRT_TAGX register values are actually
documented:
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/tree/arch/mips/include/asm/octeon/cvmx-pip-defs.h?h=apaliwal/octeon#n3737
Wow, I didn't realize that documentation was made public.
Also D-Link and Qbiquity GPL source offerings for their products usually
include documentation for register fields. Only in mainline kernel they
are missing.
The desires of the Lawyers foiled again by the requirements of the GPL.
A.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
