Re: [RFC net-next] netmem: replace __netmem_clear_lsb() with netmem_to_nmdesc()
From: Pavel Begunkov
Date: Mon Jul 28 2025 - 14:57:18 EST
On 7/28/25 19:46, Pavel Begunkov wrote:
On 7/28/25 18:44, Mina Almasry wrote:
On Sun, Jul 27, 2025 at 9:21 PM Byungchul Park <byungchul@xxxxxx> wrote:
...>> - * Return: the netmem_ref cast to net_iov* regardless of its underlying type.
+ * Return: the pointer to struct netmem_desc * regardless of its
+ * underlying type.
*/
-static inline struct net_iov *__netmem_clear_lsb(netmem_ref netmem)
+static inline struct netmem_desc *netmem_to_nmdesc(netmem_ref netmem)
{
- return (struct net_iov *)((__force unsigned long)netmem & ~NET_IOV);
+ if (netmem_is_net_iov(netmem))
+ return &((struct net_iov *)((__force unsigned long)netmem &
+ ~NET_IOV))->desc;
+
+ return __netmem_to_nmdesc(netmem);
The if statement generates overhead. I'd rather avoid it. We can
implement netmem_to_nmdesc like this, no?
netmem_to_nmdesc(netmem_ref netmem)
{
return (struct netmem_desc)((__force unsigned long)netmem & ~NET_IOV);
}
Because netmem_desc is the first element in both net_iov and page for
the moment. (yes I know that will change eventually, but we don't have
to incur overhead of an extra if statement until netmem_desc is
removed from page, right?)
Same concern, but I think the goal here should be to make enough
s/make/give/
info to the compiler to optimise it out without assumptions on
the layouts nor NET_IOV_ASSERT_OFFSET. Currently it's not so bad,
but we should be able to remove this test+cmove.
movq %rdi, %rax # netmem, tmp105
andq $-2, %rax #, tmp105
testb $1, %dil #, netmem
cmove %rdi, %rax # tmp105,, netmem, <retval>
jmp __x86_return_thunk
struct netmem_desc *netmem_to_nmdesc(netmem_ref netmem)
{
void *p = (void *)((__force unsigned long)netmem & ~NET_IOV);
if (netmem_is_net_iov(netmem))
return &((struct net_iov *)p)->desc;
return __pp_page_to_nmdesc((struct page *)p);
}
movq %rdi, %rax # netmem, netmem
andq $-2, %rax #, netmem
jmp __x86_return_thunk
This should do it, and if the layouts change, it'd still
remain correct.
--
Pavel Begunkov