Multi queue support in ethernet/freescale/ucc_geth.c
Subsystems (2)
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.
Quoted 8 lines
-----Original Message-----
From: Paul Gortmaker [mailto:[email protected]]
Sent: Friday, February 03, 2012 6:42 AM
To: Li Yang-R58472
Cc: [email protected]; [email protected]
Subject: [RFC] Multi queue support inethernet/freescale/ucc_geth.cHi Li,
Hi Paul,
Sorry for the late response due to holidays.
Quoted 11 lines
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, $
Quoted 7 lines
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?
Previously the device is only used on single core cpu, so we didn't have the incentive to enable multi-queue. It is not tested on Linux currently.
Quoted 5 lines
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