netdev - Re: [RFC net-next 1/2] eth: bnxt: refactor buffer descriptor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e5ea71d4-dca2-4a21-a727-4ac04023aad4@davidwei.uk>
Date: Tue, 1 Apr 2025 08:22:07 -0700
From: David Wei <dw@...idwei.uk>
To: Taehee Yoo <ap420073@...il.com>, Michael Chan <michael.chan@...adcom.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
 edumazet@...gle.com, andrew+netdev@...n.ch, horms@...nel.org,
 pavan.chebbi@...adcom.com, ilias.apalodimas@...aro.org,
 netdev@...r.kernel.org, kuniyu@...zon.com, sdf@...ichev.me,
 aleksander.lobakin@...el.com
Subject: Re: [RFC net-next 1/2] eth: bnxt: refactor buffer descriptor

On 2025-04-01 00:17, Taehee Yoo wrote:
> On Tue, Apr 1, 2025 at 2:39 PM Michael Chan <michael.chan@...adcom.com> wrote:
>>
> 
> Hi Michael,
> Thanks a lot for the review!
> 
>> On Mon, Mar 31, 2025 at 4:47 AM Taehee Yoo <ap420073@...il.com> wrote:
>>
>>> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>>> index 934ba9425857..198a42da3015 100644
>>> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>>> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>>> @@ -915,24 +915,24 @@ static struct page *__bnxt_alloc_rx_page(struct bnxt *bp, dma_addr_t *mapping,
>>>         if (!page)
>>>                 return NULL;
>>>
>>> -       *mapping = page_pool_get_dma_addr(page) + *offset;
>>> +       *mapping = page_pool_get_dma_addr(page) + bp->rx_dma_offset + *offset;
>>
>> Why are we changing the logic here by adding bp->rx_dma_offset?
>> Please explain this and other similar offset changes in the rest of
>> the patch.  It may be more clear if you split this patch into smaller
>> patches.
> 
> Apologies for a lack of explanation.
> This change intends to make the two functions similar.
> __bnxt_alloc_rx_page() and __bnxt_alloc_rx_frag().
> 
> Original code like this.
> ```
>     __bnxt_alloc_rx_page()
>         *mapping = page_pool_get_dma_addr(page) + *offset;
>     __bnxt_alloc_rx_frag()
>         *mapping = page_pool_get_dma_addr(page) + bp->rx_dma_offset + offset;
> 
> Then, we use a mapping value like below.
>     bnxt_alloc_rx_data()
>         if (BNXT_RX_PAGE_MODE(bp)) {
>             ...
>             mapping += bp->rx_dma_offset;
>         }
> 
>     rx_buf->mapping = mapping;
> 
>     bnxt_alloc_rx_page()
>         page = __bnxt_alloc_rx_page();
>         // no mapping offset change.
> ```
> 
> So I changed this logic like below.
> ```
>     __bnxt_alloc_rx_page()
>         *mapping = page_pool_get_dma_addr(page) + bp->rx_dma_offset + *offset;
>     __bnxt_alloc_rx_frag()
>         *mapping = page_pool_get_dma_addr(page) + bp->rx_dma_offset + *offset;
> 
>     bnxt_alloc_rx_data()
>         // no mapping offset change.
>         rx_buf->mapping = mapping;
> 
>     bnxt_alloc_rx_page()
>         page = __bnxt_alloc_rx_page();
>         mapping -= bp->rx_dma_offset; //added for this change.
> ```
> 
> However, including this change is not necessary for this patchset.
> Moreover, it makes the patch harder to review.
> Therefore, as you mentioned, I would like to drop this change for now
> and submit a separate patch for it later.

I double checked this when testing the patchset. The maths is correct,
though imo it just shifts the extra op (either add or sub
bp->rx_dma_offset) so I'm not sure how much it gains.