From: Stephen Hemminger <stephen@networkplumber.org>
To: Shuaisong Yang <yangshuaisong@h-partners.com>
Cc: Xingui Yang <yangxingui@huawei.com>,
Chengwen Feng <fengchengwen@huawei.com>,
Hao Chen <chenh@yusur.tech>,
"Min Hu (Connor)" <humin29@huawei.com>,
"Wei Hu (Xavier)" <xavier.huwei@huawei.com>,
Chunsong Feng <fengchunsong@huawei.com>,
Ferruh Yigit <ferruh.yigit@amd.com>, <dev@dpdk.org>,
<stable@dpdk.org>, <liuyonglong@huawei.com>
Subject: Re: [PATCH] net/hns3: fix hard-coded default value of UMV space
Date: Thu, 5 Nov 2026 09:37:07 +0100 [thread overview]
Message-ID: <20261105093707.17ab008d@stephen-xps.local> (raw)
In-Reply-To: <20261104124033.3373452-1-yangshuaisong@h-partners.com>
On Wed, 4 Nov 2026 20:40:33 +0800
Shuaisong Yang <yangshuaisong@h-partners.com> wrote:
> Currently, the driver obtains the PF's UMV (unicast MAC VLAN) table
> space from the board configuration, and falls back to the hard-coded
> default value HNS3_DEFAULT_UMV_SPACE_PER_PF (384 = 3072 / 8) when
> the firmware reports an empty umv_space field.
>
> The hard-coded value is only accurate for chips with a 3072-entry UMV
> table. On chips whose total UMV table size is smaller than 3072, every
> PF still requests 384 entries: the first initialized PF occupies the
> whole table while the others get nothing, which makes adding unicast
> MAC or VLAN entries fail on those ports.
>
> Fix this by obtaining the UMV size from the device specifications
> command, whose umv_size field is the default value allocated by the
> firmware policy. The requested size is determined at allocation time
> in hns3_init_umv_space(), in the following priority:
> 1. pf->cfg_umv_size, the user specified value from the board
> configuration
> 2. pf->def_umv_size, the default value reported by the firmware
> 3. the hard-coded default, as the last fallback for old firmware
>
> Fixes: d51867db65 ("net/hns3: add initialization")
> Cc: stable@dpdk.org
>
> Signed-off-by: Shuaisong Yang <yangshuaisong@h-partners.com>
> ---
Looks ok, I will correct the Fixes line during merge to next-net.
Current process needs longer hash value
next prev parent reply other threads:[~2026-11-05 8:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 12:40 [PATCH] net/hns3: fix hard-coded default value of UMV space Shuaisong Yang
2026-11-04 13:04 ` chengwen.feng
2026-11-09 18:41 ` Stephen Hemminger
2026-11-05 8:37 ` Stephen Hemminger [this message]
2026-11-09 18:42 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261105093707.17ab008d@stephen-xps.local \
--to=stephen@networkplumber.org \
--cc=chenh@yusur.tech \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=fengchunsong@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=humin29@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=stable@dpdk.org \
--cc=xavier.huwei@huawei.com \
--cc=yangshuaisong@h-partners.com \
--cc=yangxingui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.