[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACKFLikWhVicBRENq9Je=61+zJUqpcrpKONKP7sczi89sgbw0g@mail.gmail.com>
Date: Thu, 14 Nov 2024 16:22:26 -0800
From: Michael Chan <michael.chan@...adcom.com>
To: Taehee Yoo <ap420073@...il.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
edumazet@...gle.com, almasrymina@...gle.com, donald.hunter@...il.com,
corbet@....net, andrew+netdev@...n.ch, hawk@...nel.org,
ilias.apalodimas@...aro.org, ast@...nel.org, daniel@...earbox.net,
john.fastabend@...il.com, dw@...idwei.uk, sdf@...ichev.me,
asml.silence@...il.com, brett.creeley@....com, linux-doc@...r.kernel.org,
netdev@...r.kernel.org, kory.maincent@...tlin.com,
maxime.chevallier@...tlin.com, danieller@...dia.com, hengqi@...ux.alibaba.com,
ecree.xilinx@...il.com, przemyslaw.kitszel@...el.com, hkallweit1@...il.com,
ahmed.zaki@...el.com, rrameshbabu@...dia.com, idosch@...dia.com,
jiri@...nulli.us, bigeasy@...utronix.de, lorenzo@...nel.org,
jdamato@...tly.com, aleksander.lobakin@...el.com, kaiyuanz@...gle.com,
willemb@...gle.com, daniel.zahka@...il.com
Subject: Re: [PATCH net-next v5 1/7] bnxt_en: add support for rx-copybreak
ethtool command
On Wed, Nov 13, 2024 at 9:32 AM Taehee Yoo <ap420073@...il.com> wrote:
>
> The bnxt_en driver supports rx-copybreak, but it couldn't be set by
> userspace. Only the default value(256) has worked.
> This patch makes the bnxt_en driver support following command.
> `ethtool --set-tunable <devname> rx-copybreak <value> ` and
> `ethtool --get-tunable <devname> rx-copybreak`.
>
> By this patch, hds_threshol is set to the rx-copybreak value.
> But it will be set by `ethtool -G eth0 header-data-split-thresh N`
> in the next patch.
>
> Reviewed-by: Brett Creeley <brett.creeley@....com>
> Tested-by: Stanislav Fomichev <sdf@...ichev.me>
> Signed-off-by: Taehee Yoo <ap420073@...il.com>
> @@ -6417,16 +6422,14 @@ static int bnxt_hwrm_vnic_set_hds(struct bnxt *bp, struct bnxt_vnic_info *vnic)
>
> req->flags = cpu_to_le32(VNIC_PLCMODES_CFG_REQ_FLAGS_JUMBO_PLACEMENT);
> req->enables = cpu_to_le32(VNIC_PLCMODES_CFG_REQ_ENABLES_JUMBO_THRESH_VALID);
> + req->jumbo_thresh = cpu_to_le16(bp->rx_buf_use_size);
>
> - if (BNXT_RX_PAGE_MODE(bp)) {
> - req->jumbo_thresh = cpu_to_le16(bp->rx_buf_use_size);
> - } else {
> + if (!BNXT_RX_PAGE_MODE(bp) && (bp->flags & BNXT_FLAG_AGG_RINGS)) {
> req->flags |= cpu_to_le32(VNIC_PLCMODES_CFG_REQ_FLAGS_HDS_IPV4 |
> VNIC_PLCMODES_CFG_REQ_FLAGS_HDS_IPV6);
> req->enables |=
> cpu_to_le32(VNIC_PLCMODES_CFG_REQ_ENABLES_HDS_THRESHOLD_VALID);
> - req->jumbo_thresh = cpu_to_le16(bp->rx_copy_thresh);
> - req->hds_threshold = cpu_to_le16(bp->rx_copy_thresh);
> + req->hds_threshold = cpu_to_le16(bp->rx_copybreak);
I double checked our hardware spec and the HDS threshold is 10 bits,
so the maximum value is 1023. When we get to patch #5, the HDS
threshold is separated from RX copybreak and the HDS maximum becomes
256. So it is within the hardware limit.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4209 bytes)
Powered by blists - more mailing lists