> > I have been trying to figure out how exactly I can translate the current code
> > over to using the page pool api over the past week. It seems like it is quiet
> > a complex change. As the driver seems to be keeping up with our
> > performance requirements would it be acceptable to mark this as a
> Its not just performance. Using well debugged and shared core code
> means less bugs in your driver. It makes maintenance simpler since
> there are more people who understand the page pool code than what you
> have in your driver and it makes your driver more like other drivers.
> So overall you will end up with a better quality driver by adapting
> the page pool code.
Greetings Andrew,
In that case I will continue to attempt to try and adopt the page pool
API. In all the examples with page pool HW rings it appears they are
using alloc_etherdev_mqs. Are there any HW requirements to use this
library? If there are none what is the typical number for rx and tx
queues?
Thank you for the assistance,
-Nick Hawkins
> Greetings Andrew,
>
> In that case I will continue to attempt to try and adopt the page pool
> API. In all the examples with page pool HW rings it appears they are
> using alloc_etherdev_mqs. Are there any HW requirements to use this
> library? If there are none what is the typical number for rx and tx
> queues?
There are no hardware requirements as far as i understand it. If your
hardware only has one RX queue and one TX queue, define it as
1. Having more allows you to spread the load over multiple CPUs, with
each queue typically having its own interrupt, and interrupts are then
mapped to a single CPU. But if you don't have any of that, it should
not be a hindrance.
Andrew