Hi Li,
A while back DaveM mentioned that it would be good to
break out the ring allocations[1] in this driver.
I was looking at it, and in the process noticed this:
$ grep 'numQueues.*=' drivers/net/ethernet/freescale/ucc_geth.c
.numQueuesTx = 1,
.numQueuesRx = 1,
$
My interpretation of the above is that there is no way
(aside from a code edit) to enable multi queue support.
They are only ever assigned one time, to a value of one.
Assuming I'm not missing something obvious, is the multi
queue support functional and tested, or just old code
that never got tested and subsequently enabled?
The reason I ask, is that the ring allocation code gets rid
of the loop wrapping it, if the driver is really only meant
to ever have just single queues for Rx/Tx. And other areas
of the driver can also be simplified accordingly as well.
Thanks,
Paul.
[1] http://lists.openwall.net/netdev/2010/09/06/45
-----Original Message-----
From: Paul Gortmaker [mailto:paul.gortmaker@windriver.com]
Sent: Friday, February 03, 2012 6:42 AM
To: Li Yang-R58472
Cc: netdev@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: [RFC] Multi queue support in ethernet/freescale/ucc_geth.c
=20
Hi Li,
Hi Paul,
Sorry for the late response due to holidays.
=20
A while back DaveM mentioned that it would be good to break out the ring
allocations[1] in this driver.
=20
I was looking at it, and in the process noticed this:
=20
$ grep 'numQueues.*=3D' drivers/net/ethernet/freescale/ucc_geth.c
.numQueuesTx =3D 1,
.numQueuesRx =3D 1,
$
=20
My interpretation of the above is that there is no way (aside from a code
edit) to enable multi queue support.
They are only ever assigned one time, to a value of one.
=20
Assuming I'm not missing something obvious, is the multi queue support
functional and tested, or just old code that never got tested and
subsequently enabled?
Previously the device is only used on single core cpu, so we didn't have th=
e incentive to enable multi-queue. It is not tested on Linux currently.
=20
The reason I ask, is that the ring allocation code gets rid of the loop
wrapping it, if the driver is really only meant to ever have just single
queues for Rx/Tx. And other areas of the driver can also be simplified
accordingly as well.
Well. I would prefer the other way which is to add the multi-queue support=
as we are using the QE in multi-core SoC and the current driver is having =
almost all the code needed for multi-queue except interface to the protocol=
layer.
- Leo