Re: [PATCH net-next v6 3/9] bnxt_en: add support for tcp-data-split ethtool command

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 19 Dec 2024 14:33:44 -0500 Andy Gospodarek wrote:
> > I see it now in bnxt_set_rx_skb_mode. I guess with high MTU
> > the device splits in some "dumb" way, at a fixed offset..
> > You're right, we have to keep the check in the driver, 
> > at least for now.  
> 
> The mutlti-buffer implementation followed what was done at the time in
> other drivers.  Is the 'dumb way' you mention this check?
> 
>  4717                 if (dev->mtu > BNXT_MAX_PAGE_MODE_MTU) {
>  4718                         bp->flags |= BNXT_FLAG_JUMBO;
>  4719                         bp->rx_skb_func = bnxt_rx_multi_page_skb;
>  4720                 } else {
>  4721                         bp->flags |= BNXT_FLAG_NO_AGG_RINGS;
>  4722                         bp->rx_skb_func = bnxt_rx_page_skb;
>  4723                 }

Yes, that and my interpretation of the previous discussion let me to
believe that the BNXT_FLAG_JUMBO does not enable header-data split.
And speculating further I thought that perhaps the buffer split with
jumbo > 4k is to fill first buffer completely, header+however much
data fits.

I could have misread the previous conversation (perhaps Michael meant
XDP SB / PAGE_MODE when he was referring to XDP limitations?)

Or maybe the HDS does happen with XDP MB but there is another
limitation in the code?

I'm not sure. At this stage we just need to know if the check in the
driver is really needed or XDP MB + HDS are fine, and we can remove
the driver check, as core already prevents XDP SB + HDS. Could you
clarify?