On Thu, Oct 10, 2024 at 12:28 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Wed, 9 Oct 2024 22:54:17 +0900 Taehee Yoo wrote: > > > This breaks previous behavior. The HDS reporting from get was > > > introduced to signal to user space whether the page flip based > > > TCP zero-copy (the one added some years ago not the recent one) > > > will be usable with this NIC. > > > > > > When HW-GRO is enabled HDS will be working. > > > > > > I think that the driver should only track if the user has set the value > > > to ENABLED (forced HDS), or to UKNOWN (driver default). Setting the HDS > > > to disabled is not useful, don't support it. > > > > Okay, I will remove the disable feature in a v4 patch. > > Before this patch, hds_threshold was rx-copybreak value. > > How do you think hds_threshold should still follow rx-copybreak value > > if it is UNKNOWN mode? > > IIUC the rx_copybreak only applies to the header? Or does it apply > to the entire frame? > > If rx_copybreak applies to the entire frame and not just the first > buffer (headers or headers+payload if not split) - no preference. > If rx_copybreak only applies to the headers / first buffer then > I'd keep them separate as they operate on a different length. It applies only the first buffer. So, if HDS is enabled, it copies only header. Thanks, I will separate rx-copybreak and hds_threshold. > > > I think hds_threshold need to follow new tcp-data-split-thresh value in > > ENABLE/UNKNOWN and make rx-copybreak pure software feature. > > Sounds good to me, but just to be clear: > > If user sets the HDS enable to UNKNOWN (or doesn't set it): > - GET returns (current behavior, AFAIU): > - DISABLED (if HW-GRO is disabled and MTU is not Jumbo) > - ENABLED (if HW-GRO is enabled of MTU is Jumbo) > If user sets the HDS enable to ENABLED (force HDS on): > - GET returns ENABLED > > hds_threshold returns: some value, but it's only actually used if GET > returns ENABLED. > Thanks for the detailed explanation! > > But if so, it changes the default behavior. > > How so? The configuration of neither of those two is exposed to > the user. We can keep the same defaults, until user overrides them. > Ah, right. I understood. > > How do you think about it? > > > > > > > > > ering->tx_max_pending = BNXT_MAX_TX_DESC_CNT; > > > > > > > > ering->rx_pending = bp->rx_ring_size; > > > > @@ -854,9 +858,25 @@ static int bnxt_set_ringparam(struct net_device *dev, > > > > (ering->tx_pending < BNXT_MIN_TX_DESC_CNT)) > > > > return -EINVAL; > > > > > > > > + if (kernel_ering->tcp_data_split != ETHTOOL_TCP_DATA_SPLIT_DISABLED && > > > > + BNXT_RX_PAGE_MODE(bp)) { > > > > + NL_SET_ERR_MSG_MOD(extack, "tcp-data-split can not be enabled with XDP"); > > > > + return -EINVAL; > > > > + } > > > > > > Technically just if the XDP does not support multi-buffer. > > > Any chance we could do this check in the core? > > > > I think we can access xdp_rxq_info with netdev_rx_queue structure. > > However, xdp_rxq_info is not sufficient to distinguish mb is supported > > by the driver or not. I think prog->aux->xdp_has_frags is required to > > distinguish it correctly. > > So, I think we need something more. > > Do you have any idea? > > Take a look at dev_xdp_prog_count(), something like that but only > counting non-mb progs? Thanks for very nice example, I will try it!