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

["Théo Lebrun" <theo.lebrun@bootlin.com>]

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)`?

  [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