On Mon, Aug 14, 2023 at 11:34:11AM +0530, Ratheesh Kannoth wrote: > Clamp to 32k instead of returning error.
What is the motivation here? What is the real world impact for the users? > > Please find discussion at > https://lore.kernel.org/lkml/ > CY4PR1801MB1911E15D518A77535F6E51E2D308A@CY4PR1801MB1911. > namprd18.prod.outlook.com/T/ Please don't break the URL up like this. I think normally we would just write up a normal commit message and use the Link: tag. Fixes: ff7d6b27f894 ("page_pool: refurbish version of page_pool code") Link: https://lore.kernel.org/lkml/cy4pr1801mb1911e15d518a77535f6e51e2d3...@cy4pr1801mb1911.namprd18.prod.outlook.com/ Signed-off-by: > @@ -171,9 +171,10 @@ static int page_pool_init(struct page_pool *pool, > if (pool->p.pool_size) > ring_qsize = pool->p.pool_size; > > - /* Sanity limit mem that can be pinned down */ > + /* Cap queue size to 32k */ > if (ring_qsize > 32768) > - return -E2BIG; > + ring_qsize = 32768; > + > > /* DMA direction is either DMA_FROM_DEVICE or DMA_BIDIRECTIONAL. Don't introduce a blank line here. Checkpatch will complain if you have to blank lines in a row. It won't complain about the patch but it will complain if you apply the patch and then re-run checkpatch -f on the file. (I didn't test this but it's wrong either way. :P). regards, dan carpenter
