Re: [PATCH net-next v9 2/8] netmem: introduce utility APIs to use struct netmem_desc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/14/25 11:05, Byungchul Park wrote:
On Mon, Jul 14, 2025 at 10:43:35AM +0100, Pavel Begunkov wrote:
On 7/14/25 00:07, Byungchul Park wrote:
On Sat, Jul 12, 2025 at 12:59:34PM +0100, Pavel Begunkov wrote:
On 7/10/25 09:28, Byungchul Park wrote:
...> +
    static inline struct net_iov *netmem_to_net_iov(netmem_ref netmem)
    {
        if (netmem_is_net_iov(netmem))
@@ -314,6 +340,21 @@ static inline netmem_ref netmem_compound_head(netmem_ref netmem)
        return page_to_netmem(compound_head(netmem_to_page(netmem)));
    }

+#define nmdesc_to_page(nmdesc)               (_Generic((nmdesc),             \
+     const struct netmem_desc * :    (const struct page *)(nmdesc),  \
+     struct netmem_desc * :          (struct page *)(nmdesc)))

Considering that nmdesc is going to be separated from pages and
accessed through indirection, and back reference to the page is
not needed (at least for net/), this helper shouldn't even exist.
And in fact, you don't really use it ...
+static inline struct netmem_desc *page_to_nmdesc(struct page *page)
+{
+     VM_BUG_ON_PAGE(PageTail(page), page);
+     return (struct netmem_desc *)page;
+}
+
+static inline void *nmdesc_address(struct netmem_desc *nmdesc)
+{
+     return page_address(nmdesc_to_page(nmdesc));
+}

... That's the only caller, and nmdesc_address() is not used, so
just nuke both of them. This helper doesn't even make sense.

Please avoid introducing functions that you don't use as a general
rule.

I'm sorry about making you confused.  I should've included another patch
using the helper like the following.

Ah, I see. And still, it's not a great function. There should be
no way to extract a page or a page address from a nmdesc.

For the diff below it's same as with the mt76 patch, it's allocating
a page, expects it to be a page, using it as a page, but for no reason
keeps it wrapped into netmem. It only adds confusion and overhead.
A rule of thumb would be only converting to netmem if the new code
would be able to work with a netmem-wrapped net_iovs.

Thanks.  I'm now working on this job, avoiding your concern.

By the way, am I supposed to wait for you to complete the work about
extracting type from page e.g. page pool (or bump) type?

1/8 doesn't depend on it, if you're sending it separately. As for
the rest, it might need to wait for the PGTY change, which is more
likely to be for 6.18

--
Pavel Begunkov





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux