Re: [PATCH net-next 0/8] net: macb: Add XDP support and page pool integration

[Paolo Valerio <pvalerio@redhat.com>]

On 16 Feb 2026 at 10:17:39 AM, Théo Lebrun <theo.lebrun@bootlin.com> wrote:

> On Sat Feb 14, 2026 at 4:37 PM CET, Paolo Valerio wrote:
>> On 13 Feb 2026 at 05:57:17 PM, Théo Lebrun <theo.lebrun@bootlin.com> wrote:
>>> My XSK series (based on top of yours) is ready.
>>> I won't be sending it while net-next is closed, of course.
>>
>> Nice!
>> Same for this series, will respin when net-next will reopen.
>>
>>> It starts with a few cleanup/rework patches that have no direct link to
>>> XSK and touch code you add in this series. They could be appended to
>>> your next revision or even squashed (with the right SoB &
>>> Co-developed-by trailers) for most.
>>>
>>> Some contain bug fixes, mostly related to stats accounting. I expect
>>> some amount of discussion as well, mostly regarding the page pool DMA
>>> direction.
>>
>> I quickly looked at the patches.
>>
>> As we briefly discussed off-list, in my plans stats were considered as a
>> follow up. I intentionally kept them out of the series and to keep it
>> smaller.
>> Given you added them, I guess it's perfectly fine if you include
>> the patch directly in your series (unless maintainers prefer/suggest
>> otherwise). The same should apply for macb_tx_complete() rework.
>> That being said, IMO, we should account xdp stats separately instead of
>> including them in the generic ones.
>
> ACK so I keep those patches in my series.
>
>   [PATCH 4/_] net: macb: account for stats in Rx XDP codepaths
>   [PATCH 6/_] net: macb: rework macb_tx_complete() processing loop
>
> If my diff related to statistics grows bigger, it'll deserve its own
> series. Until then I'll keep it part of XSK.
>
>> The one about DMA_BIDIRECTIONAL is already part of this review cycle
>> (see bot's reply to 5/8) and already incorporated. I'm also considering
>> the possibility a change that make this no longer relevant anyways, but
>> I'm not sure as it was planned as a follow up.
>
> Yes indeed, Jakub's LLM pointed it out. I looked into this for a bit and
> couldn't find any good solution. In the end I couldn't find any
> measurable performance improvement so no need to worry about it (on my
> platform). I guess the only valid option is to reopen
> if `running && (!!old_prog != !!new_prog)`?
>

yeah, which I guess is fine, after all.
Also, this way at some point we may even consider to remove the xdp
headroom for the skb case and reserve less like NET_SKB_PAD. This would
have the extra bonus to not require a full page for 1500 mtu with 4k
pages.

>   [PATCH 3/_] net: macb: always use DMA_BIDIRECTIONAL on page pool buffers
>
>> Regarding the patches containing simple renames, I don't think they
>> require a Co-developed-by. The reasoning follows the same logic I
>> applied to the patch you authored in my series; while I addressed a NULL
>> dereference, it didn't seem significant enough to mark the entire patch
>> as co-developed.
>> The same goes for the style change patch, it doesn't change any logic,
>> it's just a cosmetic change that normally go through the regular review
>> process, but if you think it requires a separate patch, feel free to
>> follow up on this in your series.
>
> Yes for sure! Squash the remaining patches as if they were ordinary
> review messages. It was simpler for me to send those as patches along
> the other three.
>
>   [PATCH 1/_] net: macb: rename release_buff() -> macb_tx_release_buff()
>   [PATCH 2/_] net: macb: drop two labels in gem_rx()
>   [PATCH 5/_] net: macb: improve Rx refill error message
>
> Thanks,
>
> --
> Théo Lebrun, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com