On 09/06/2023 15.17, Yunsheng Lin wrote:
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index a7c526ee5024..cd4ac378cc63 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -832,6 +832,15 @@ static int mlx5e_alloc_rq(struct mlx5e_params *params,
> /* Create a page_pool and register it with rxq */
> struct page_pool_params pp_params = { 0 };
>
> + /* Return error here to aoivd writing to page->pp_frag_count in
^^^^^
Typo
> + * mlx5e_page_release_fragmented() for page->pp_frag_count is not
> + * usable for arch with PAGE_POOL_DMA_USE_PP_FRAG_COUNT being true.
> + */
> + if (PAGE_POOL_DMA_USE_PP_FRAG_COUNT) {
> + err = -EINVAL;
> + goto err_free_by_rq_type;
> + }
> +
> pp_params.order = 0;
> pp_params.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV | PP_FLAG_PAGE_FRAG;
> pp_params.pool_size = pool_size;
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index 126f9e294389..5c7f7501f300 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -33,6 +33,7 @@
> #include <linux/mm.h> /* Needed by ptr_ring */
> #include <linux/ptr_ring.h>
> #include <linux/dma-direction.h>
> +#include <linux/dma-mapping.h>
>
> #define PP_FLAG_DMA_MAP BIT(0) /* Should page_pool do the DMA
> * map/unmap
> @@ -50,6 +51,9 @@
> PP_FLAG_DMA_SYNC_DEV |\
> PP_FLAG_PAGE_FRAG)
>
> +#define PAGE_POOL_DMA_USE_PP_FRAG_COUNT \
> + (sizeof(dma_addr_t) > sizeof(unsigned long))
> +
I have a problem with the name PAGE_POOL_DMA_USE_PP_FRAG_COUNT
because it is confusing to read in an if-statement.
Proposals rename to: DMA_OVERLAP_PP_FRAG_COUNT
Or: MM_DMA_OVERLAP_PP_FRAG_COUNT
Or: DMA_ADDR_OVERLAP_PP_FRAG_COUNT
Notice how I also removed the prefix PAGE_POOL_ because this is a
MM-layer constraint and not a property of page_pool.
--Jesper
On 2023/6/9 23:02, Jesper Dangaard Brouer wrote:
...
>> PP_FLAG_DMA_SYNC_DEV |\
>> PP_FLAG_PAGE_FRAG)
>> +#define PAGE_POOL_DMA_USE_PP_FRAG_COUNT \
>> + (sizeof(dma_addr_t) > sizeof(unsigned long))
>> +
>
> I have a problem with the name PAGE_POOL_DMA_USE_PP_FRAG_COUNT
> because it is confusing to read in an if-statement.
Actually, it is already in an if-statement before this patch:)
Maybe starting to use it in the driver is confusing to you?
If not, maybe we can keep it that for now, and change it when
we come up with a better name.
>
> Proposals rename to: DMA_OVERLAP_PP_FRAG_COUNT
> Or: MM_DMA_OVERLAP_PP_FRAG_COUNT
> Or: DMA_ADDR_OVERLAP_PP_FRAG_COUNT
It seems DMA_ADDR_OVERLAP_PP_FRAG_COUNT is better,
and DMA_ADDR_UPPER_OVERLAP_PP_FRAG_COUNT seems more accurate if a
longer macro name is not an issue here.
>
> Notice how I also removed the prefix PAGE_POOL_ because this is a MM-layer constraint and not a property of page_pool.
I am not sure if it is a MM-layer constraint yet.
Do you mean 'MM-layer constraint' as 'struct page' not having
enough space for page pool with 32-bit arch with 64-bit DMA?
If that is the case, we may need a more generic name for that
constraint instead of 'DMA_ADDR_OVERLAP_PP_FRAG_COUNT'?
And a more generic name seems confusing for page pool too, as
it doesn't tell that we only have that problem for 32-bit arch
with 64-bit DMA.
So if the above makes sense, it seems we may need to keep the
PAGE_POOL_ prefix, which would be
'PAGE_POOL_DMA_ADDR_UPPER_OVERLAP_PP_FRAG_COUNT' if the long
name is not issue here.
Anyway, naming is hard, we may need a seperate patch to explain
it, which is not really related to this patchset IHMO, so I'd
rather keep it as before if we can not come up with a name which
is not confusing to most people.
>
>
> --Jesper
>
>
On 10/06/2023 15.13, Yunsheng Lin wrote:
> On 2023/6/9 23:02, Jesper Dangaard Brouer wrote:
> ...
>
>>> PP_FLAG_DMA_SYNC_DEV |\
>>> PP_FLAG_PAGE_FRAG)
>>> +#define PAGE_POOL_DMA_USE_PP_FRAG_COUNT \
>>> + (sizeof(dma_addr_t) > sizeof(unsigned long))
>>> +
>>
>> I have a problem with the name PAGE_POOL_DMA_USE_PP_FRAG_COUNT
>> because it is confusing to read in an if-statement.
>
> Actually, it is already in an if-statement before this patch:)
I did notice, but I've had a problem with this name for a while.
(see later, why this might be long in separate patch)
> Maybe starting to use it in the driver is confusing to you?
> If not, maybe we can keep it that for now, and change it when
> we come up with a better name.
>
>>
>> Proposals rename to: DMA_OVERLAP_PP_FRAG_COUNT
>> Or: MM_DMA_OVERLAP_PP_FRAG_COUNT
>> Or: DMA_ADDR_OVERLAP_PP_FRAG_COUNT
>
> It seems DMA_ADDR_OVERLAP_PP_FRAG_COUNT is better,
> and DMA_ADDR_UPPER_OVERLAP_PP_FRAG_COUNT seems more accurate if a
> longer macro name is not an issue here.
>
I like the shorter DMA_ADDR_OVERLAP_PP_FRAG_COUNT variant best.
>>
>> Notice how I also removed the prefix PAGE_POOL_ because this is a
>> MM-layer constraint and not a property of page_pool.
>
> I am not sure if it is a MM-layer constraint yet.
> Do you mean 'MM-layer constraint' as 'struct page' not having
> enough space for page pool with 32-bit arch with 64-bit DMA?
Yes.
> If that is the case, we may need a more generic name for that
> constraint instead of 'DMA_ADDR_OVERLAP_PP_FRAG_COUNT'?
>
I think this name is clear enough; the dma_addr_t is overlapping the
pp_frag_count.
> And a more generic name seems confusing for page pool too, as
> it doesn't tell that we only have that problem for 32-bit arch
> with 64-bit DMA.
>
> So if the above makes sense, it seems we may need to keep the
> PAGE_POOL_ prefix, which would be
> 'PAGE_POOL_DMA_ADDR_UPPER_OVERLAP_PP_FRAG_COUNT' if the long
> name is not issue here.
>
I think it gets too long now.
Also I still disagree with PAGE_POOL_ prefix, if anything it is a
property of 'struct page'. Thus a prefix with PAGE_ make more sense to
me, but it also gets too long (for my taste).
> Anyway, naming is hard, we may need a seperate patch to explain
> it, which is not really related to this patchset IHMO, so I'd
> rather keep it as before if we can not come up with a name which
> is not confusing to most people.
>
Okay, lets do the (re)naming in another patch then.
--Jesper