- Linuxarm - mailweb.openeuler.org

[PATCH for-rc] RDMA/hns: Use mutex instead of spinlock for ida allocation
by Weihang Li 20 Jan '21

20 Jan '21

From: Yangyang Li <liyangyang20(a)huawei.com> GFP_KERNEL may cause ida_alloc_range() to sleep, but the spinlock covering this function is not allowed to sleep, so the spinlock needs to be changed to mutex. As there is a certain chance of memory allocation failure, GFP_ATOMIC is not suitable for QP allocation scenarios. Fixes: 71586dd20010 ("RDMA/hns: Create QP with selected QPN for bank load balance") Signed-off-by: Yangyang Li <liyangyang20(a)huawei.com> Signed-off-by: Weihang Li <liweihang(a)huawei.com> --- drivers/infiniband/hw/hns/hns_roce_device.h | 2 +- drivers/infiniband/hw/hns/hns_roce_qp.c | 11 ++++++----- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h b/drivers/infiniband/hw/hns/hns_roce_device.h index 55d5386..ad82532 100644 --- a/drivers/infiniband/hw/hns/hns_roce_device.h +++ b/drivers/infiniband/hw/hns/hns_roce_device.h @@ -532,7 +532,7 @@ struct hns_roce_qp_table { struct hns_roce_hem_table sccc_table; struct mutex scc_mutex; struct hns_roce_bank bank[HNS_ROCE_QP_BANK_NUM]; - spinlock_t bank_lock; + struct mutex bank_mutex; }; struct hns_roce_cq_table { diff --git a/drivers/infiniband/hw/hns/hns_roce_qp.c b/drivers/infiniband/hw/hns/hns_roce_qp.c index d8e2fe5..1116371 100644 --- a/drivers/infiniband/hw/hns/hns_roce_qp.c +++ b/drivers/infiniband/hw/hns/hns_roce_qp.c @@ -209,7 +209,7 @@ static int alloc_qpn(struct hns_roce_dev *hr_dev, struct hns_roce_qp *hr_qp) hr_qp->doorbell_qpn = 1; } else { - spin_lock(&qp_table->bank_lock); + mutex_lock(&qp_table->bank_mutex); bankid = get_least_load_bankid_for_qp(qp_table->bank); ret = alloc_qpn_with_bankid(&qp_table->bank[bankid], bankid, @@ -217,12 +217,12 @@ static int alloc_qpn(struct hns_roce_dev *hr_dev, struct hns_roce_qp *hr_qp) if (ret) { ibdev_err(&hr_dev->ib_dev, "failed to alloc QPN, ret = %d\n", ret); - spin_unlock(&qp_table->bank_lock); + mutex_unlock(&qp_table->bank_mutex); return ret; } qp_table->bank[bankid].inuse++; - spin_unlock(&qp_table->bank_lock); + mutex_unlock(&qp_table->bank_mutex); hr_qp->doorbell_qpn = (u32)num; } @@ -408,9 +408,9 @@ static void free_qpn(struct hns_roce_dev *hr_dev, struct hns_roce_qp *hr_qp) ida_free(&hr_dev->qp_table.bank[bankid].ida, hr_qp->qpn >> 3); - spin_lock(&hr_dev->qp_table.bank_lock); + mutex_lock(&hr_dev->qp_table.bank_mutex); hr_dev->qp_table.bank[bankid].inuse--; - spin_unlock(&hr_dev->qp_table.bank_lock); + mutex_unlock(&hr_dev->qp_table.bank_mutex); } static int set_rq_size(struct hns_roce_dev *hr_dev, struct ib_qp_cap *cap, @@ -1371,6 +1371,7 @@ int hns_roce_init_qp_table(struct hns_roce_dev *hr_dev) unsigned int i; mutex_init(&qp_table->scc_mutex); + mutex_init(&qp_table->bank_mutex); xa_init(&hr_dev->qp_table_xa); reserved_from_bot = hr_dev->caps.reserved_qps; -- 2.8.1

2 1

Re: [RFC PATCH 1/2] EDAC/ghes: Add EDAC device for the CPU caches
by Shiju Jose 19 Jan '21

19 Jan '21

Hi Boris, Thanks for the feedback. Apologies for the delay. >-----Original Message----- >From: Borislav Petkov [mailto:bp@alien8.de] >Sent: 31 December 2020 16:44 >To: Shiju Jose <shiju.jose(a)huawei.com> >Cc: linux-edac(a)vger.kernel.org; linux-acpi(a)vger.kernel.org; linux- >kernel(a)vger.kernel.org; james.morse(a)arm.com; >mchehab+huawei(a)kernel.org; tony.luck(a)intel.com; rjw(a)rjwysocki.net; >lenb(a)kernel.org; rrichter(a)marvell.com; Linuxarm <linuxarm(a)huawei.com>; >xuwei (O) <xuwei5(a)huawei.com>; Jonathan Cameron ><jonathan.cameron(a)huawei.com>; John Garry <john.garry(a)huawei.com>; >tanxiaofei <tanxiaofei(a)huawei.com>; Shameerali Kolothum Thodi ><shameerali.kolothum.thodi(a)huawei.com>; Salil Mehta ><salil.mehta(a)huawei.com> >Subject: Re: [RFC PATCH 1/2] EDAC/ghes: Add EDAC device for the CPU >caches > >On Tue, Dec 08, 2020 at 05:29:58PM +0000, Shiju Jose wrote: >> The corrected error count on the CPU caches required reporting to the >> user-space for the predictive failure analysis. For this purpose, add >> an EDAC device and device blocks for the CPU caches found. >> The cache's corrected error count would be stored in the >> /sys/devices/system/edac/cpu/cpu*/cache*/ce_count. > >This still doesn't begin to explain why the kernel needs this. I had already >asked whether errors in CPU caches are something which happen often >enough so that software should count them but nothing came. So pls justify >first why this wants to be added to the kernel. L2 cache corrected errors are detected occasionally on few of our ARM64 hardware boards. Though it is rare, the probability of the CPU cache errors frequently occurring can't be avoided. The earlier failure detection by monitoring the cache corrected errors for the frequent occurrences and taking preventive action could prevent more serious hardware faults. On Intel architectures, cache corrected errors are reported and the affected cores are offline in the architecture specific method. http://www.mcelog.org/cache.html However for the firmware-first error reporting, specifically on ARM64 architectures, there is no provision present for reporting the cache corrected error count to the user-space and taking preventive action such as offline the affected cores. > >> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig index >> 7a47680d6f07..c73eeab27ac9 100644 >> --- a/drivers/edac/Kconfig >> +++ b/drivers/edac/Kconfig >> @@ -74,6 +74,16 @@ config EDAC_GHES >> >> In doubt, say 'Y'. >> >> +config EDAC_GHES_CPU_ERROR >> + bool "EDAC device for reporting firmware-first BIOS detected CPU >error count" > >Why a separate Kconfig item? CONFIG_EDAC_GHES_CPU_CACHE_ERROR is added to make this feature optional only for the platforms which need this and supported. > >> + depends on EDAC_GHES >> + help >> + EDAC device for the firmware-first BIOS detected CPU error count >> +reported > >Well this is not what it is doing - you're talking about cache errors. >"CPU errors" can be a lot more than just cache errors. Sure. I will change. > >> +static void ghes_edac_create_cpu_device(struct device *dev) { >> + int cpu; >> + struct cpu_cacheinfo *this_cpu_ci; >> + >> + /* >> + * Find the maximum number of caches present in the CPU heirarchy >> + * among the online CPUs. >> + */ >> + for_each_online_cpu(cpu) { >> + this_cpu_ci = get_cpu_cacheinfo(cpu); >> + if (!this_cpu_ci) >> + continue; >> + if (max_number_of_caches < this_cpu_ci->num_leaves) >> + max_number_of_caches = this_cpu_ci->num_leaves; > >So this is counting the number of cache levels on the system? So you want to >count the errors per cache levels? Yes. This was the suggestion from James and to offline the affected cores for the shared cache. > >> + } >> + if (!max_number_of_caches) >> + return; >> + >> + /* >> + * EDAC device interface only supports creating the CPU cache >hierarchy for alls >> + * the CPUs together. Thus need to allocate cpu_edac_block_list for >the >> + * max_number_of_caches among all the CPUs irrespective of the >number of caches >> + * per CPU might vary. >> + */ > >So this is lumping all the caches together into a single list? What for? >To untangle to the proper ones when the error gets reported? > >Have you heard of percpu variables? Yes. Changed the list to the percpu variable. > >> @@ -624,6 +787,10 @@ int ghes_edac_register(struct ghes *ghes, struct >device *dev) >> ghes_pvt = pvt; >> spin_unlock_irqrestore(&ghes_lock, flags); >> >> +#if defined(CONFIG_EDAC_GHES_CPU_ERROR) >> + ghes_edac_create_cpu_device(dev); >> +#endif >> + > >Init stuff belongs into ghes_scan_system(). > Did you mean calling ghes_edac_create_cpu_device() in the ghes_scan_system()? >... > >Ok, I've seen enough. "required reporting to the user-space for the predictive >failure analysis." is not even trying to explain *why* you're doing this, what >*actual* problem it is addressing and why should the kernel get it. > >And without a proper problem definition of what you're trying to solve, this >is not going anywhere. > >-- >Regards/Gruss, > Boris. > Thanks, Shiju

2 3

[PATCH mm/zswap 0/2] Fix the compatibility of zsmalloc and zswap
by Tian Tao 19 Jan '21

19 Jan '21

patch #1 add a flag to zpool, then zswap used to determine if zpool drivers such as zbud/z3fold/zsmalloc whether can sleep in atoimc context. patch #2 set flag sleep_mapped to true indicates that zbud/z3fold can sleep in atomic context. zsmalloc didin't support sleep in atomic context, so not set that flag to true. Tian Tao (2): mm/zswap: add the flag can_sleep_mapped mm: set the sleep_mapped to true for zbud and z3fold include/linux/zpool.h | 3 +++ mm/z3fold.c | 1 + mm/zbud.c | 1 + mm/zpool.c | 13 +++++++++++++ mm/zswap.c | 50 +++++++++++++++++++++++++++++++++++++++++++++----- 5 files changed, 63 insertions(+), 5 deletions(-) -- 2.7.4

2 4

[PATCH v2 for-next] RDMA/hns: Create CQ with selected CQN for bank load balance
by Weihang Li 19 Jan '21

19 Jan '21

From: Yangyang Li <liyangyang20(a)huawei.com> In order to improve performance by balancing the load between different banks of cache, the CQC cache is desigend to choose one of 4 banks according to lower 2 bits of CQN. The hns driver needs to count the number of CQ on each bank and then assigns the CQ being created to the bank with the minimum load first. Signed-off-by: Yangyang Li <liyangyang20(a)huawei.com> Signed-off-by: Weihang Li <liweihang(a)huawei.com> --- Changes since v1: - Change GFP_ATOMIC to GFP_KERNEL as there is a chance of memory allocation failure, and change the spin lock to mutex lock because ida_alloc_range() may sleep. - Link: https://patchwork.kernel.org/project/linux-rdma/patch/1609742115-47270-1-gi… drivers/infiniband/hw/hns/hns_roce_cq.c | 115 +++++++++++++++++++++++----- drivers/infiniband/hw/hns/hns_roce_device.h | 10 ++- drivers/infiniband/hw/hns/hns_roce_main.c | 8 +- 3 files changed, 105 insertions(+), 28 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_cq.c b/drivers/infiniband/hw/hns/hns_roce_cq.c index 8533fc2..ffb7f7e 100644 --- a/drivers/infiniband/hw/hns/hns_roce_cq.c +++ b/drivers/infiniband/hw/hns/hns_roce_cq.c @@ -38,11 +38,74 @@ #include "hns_roce_hem.h" #include "hns_roce_common.h" +static u8 get_least_load_bankid_for_cq(struct hns_roce_bank *bank) +{ + u32 least_load = bank[0].inuse; + u8 bankid = 0; + u32 bankcnt; + u8 i; + + for (i = 1; i < HNS_ROCE_CQ_BANK_NUM; i++) { + bankcnt = bank[i].inuse; + if (bankcnt < least_load) { + least_load = bankcnt; + bankid = i; + } + } + + return bankid; +} + +static int alloc_cqn(struct hns_roce_dev *hr_dev, struct hns_roce_cq *hr_cq) +{ + struct hns_roce_cq_table *cq_table = &hr_dev->cq_table; + struct hns_roce_bank *bank; + u8 bankid; + int id; + + mutex_lock(&cq_table->bank_mutex); + bankid = get_least_load_bankid_for_cq(cq_table->bank); + bank = &cq_table->bank[bankid]; + + id = ida_alloc_range(&bank->ida, bank->min, bank->max, GFP_KERNEL); + if (id < 0) { + mutex_unlock(&cq_table->bank_mutex); + return id; + } + + /* the lower 2 bits is bankid */ + hr_cq->cqn = (id << CQ_BANKID_SHIFT) | bankid; + bank->inuse++; + mutex_unlock(&cq_table->bank_mutex); + + return 0; +} + +static inline u8 get_cq_bankid(unsigned long cqn) +{ + /* The lower 2 bits of CQN are used to hash to different banks */ + return (u8)(cqn & GENMASK(1, 0)); +} + +static void free_cqn(struct hns_roce_dev *hr_dev, unsigned long cqn) +{ + struct hns_roce_cq_table *cq_table = &hr_dev->cq_table; + struct hns_roce_bank *bank; + + bank = &cq_table->bank[get_cq_bankid(cqn)]; + + ida_free(&bank->ida, cqn >> CQ_BANKID_SHIFT); + + mutex_lock(&cq_table->bank_mutex); + bank->inuse--; + mutex_unlock(&cq_table->bank_mutex); +} + static int alloc_cqc(struct hns_roce_dev *hr_dev, struct hns_roce_cq *hr_cq) { + struct hns_roce_cq_table *cq_table = &hr_dev->cq_table; struct ib_device *ibdev = &hr_dev->ib_dev; struct hns_roce_cmd_mailbox *mailbox; - struct hns_roce_cq_table *cq_table; u64 mtts[MTT_MIN_COUNT] = { 0 }; dma_addr_t dma_handle; int ret; @@ -54,13 +117,6 @@ static int alloc_cqc(struct hns_roce_dev *hr_dev, struct hns_roce_cq *hr_cq) return -EINVAL; } - cq_table = &hr_dev->cq_table; - ret = hns_roce_bitmap_alloc(&cq_table->bitmap, &hr_cq->cqn); - if (ret) { - ibdev_err(ibdev, "failed to alloc CQ bitmap, ret = %d.\n", ret); - return ret; - } - /* Get CQC memory HEM(Hardware Entry Memory) table */ ret = hns_roce_table_get(hr_dev, &cq_table->table, hr_cq->cqn); if (ret) { @@ -110,7 +166,6 @@ static int alloc_cqc(struct hns_roce_dev *hr_dev, struct hns_roce_cq *hr_cq) hns_roce_table_put(hr_dev, &cq_table->table, hr_cq->cqn); err_out: - hns_roce_bitmap_free(&cq_table->bitmap, hr_cq->cqn, BITMAP_NO_RR); return ret; } @@ -138,7 +193,6 @@ static void free_cqc(struct hns_roce_dev *hr_dev, struct hns_roce_cq *hr_cq) wait_for_completion(&hr_cq->free); hns_roce_table_put(hr_dev, &cq_table->table, hr_cq->cqn); - hns_roce_bitmap_free(&cq_table->bitmap, hr_cq->cqn, BITMAP_NO_RR); } static int alloc_cq_buf(struct hns_roce_dev *hr_dev, struct hns_roce_cq *hr_cq, @@ -298,11 +352,17 @@ int hns_roce_create_cq(struct ib_cq *ib_cq, const struct ib_cq_init_attr *attr, goto err_cq_buf; } + ret = alloc_cqn(hr_dev, hr_cq); + if (ret) { + ibdev_err(ibdev, "failed to alloc CQN, ret = %d.\n", ret); + goto err_cq_db; + } + ret = alloc_cqc(hr_dev, hr_cq); if (ret) { ibdev_err(ibdev, "failed to alloc CQ context, ret = %d.\n", ret); - goto err_cq_db; + goto err_cqn; } /* @@ -326,6 +386,8 @@ int hns_roce_create_cq(struct ib_cq *ib_cq, const struct ib_cq_init_attr *attr, err_cqc: free_cqc(hr_dev, hr_cq); +err_cqn: + free_cqn(hr_dev, hr_cq->cqn); err_cq_db: free_cq_db(hr_dev, hr_cq, udata); err_cq_buf: @@ -341,9 +403,11 @@ int hns_roce_destroy_cq(struct ib_cq *ib_cq, struct ib_udata *udata) if (hr_dev->hw->destroy_cq) hr_dev->hw->destroy_cq(ib_cq, udata); - free_cq_buf(hr_dev, hr_cq); - free_cq_db(hr_dev, hr_cq, udata); free_cqc(hr_dev, hr_cq); + free_cqn(hr_dev, hr_cq->cqn); + free_cq_db(hr_dev, hr_cq, udata); + free_cq_buf(hr_dev, hr_cq); + return 0; } @@ -402,18 +466,33 @@ void hns_roce_cq_event(struct hns_roce_dev *hr_dev, u32 cqn, int event_type) complete(&hr_cq->free); } -int hns_roce_init_cq_table(struct hns_roce_dev *hr_dev) +void hns_roce_init_cq_table(struct hns_roce_dev *hr_dev) { struct hns_roce_cq_table *cq_table = &hr_dev->cq_table; + unsigned int reserved_from_bot; + unsigned int i; + mutex_init(&cq_table->bank_mutex); xa_init(&cq_table->array); - return hns_roce_bitmap_init(&cq_table->bitmap, hr_dev->caps.num_cqs, - hr_dev->caps.num_cqs - 1, - hr_dev->caps.reserved_cqs, 0); + reserved_from_bot = hr_dev->caps.reserved_cqs; + + for (i = 0; i < reserved_from_bot; i++) { + cq_table->bank[get_cq_bankid(i)].inuse++; + cq_table->bank[get_cq_bankid(i)].min++; + } + + for (i = 0; i < HNS_ROCE_CQ_BANK_NUM; i++) { + ida_init(&cq_table->bank[i].ida); + cq_table->bank[i].max = hr_dev->caps.num_cqs / + HNS_ROCE_CQ_BANK_NUM - 1; + } } void hns_roce_cleanup_cq_table(struct hns_roce_dev *hr_dev) { - hns_roce_bitmap_cleanup(&hr_dev->cq_table.bitmap); + int i; + + for (i = 0; i < HNS_ROCE_CQ_BANK_NUM; i++) + ida_destroy(&hr_dev->cq_table.bank[i].ida); } diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h b/drivers/infiniband/hw/hns/hns_roce_device.h index 55d5386..c46b330 100644 --- a/drivers/infiniband/hw/hns/hns_roce_device.h +++ b/drivers/infiniband/hw/hns/hns_roce_device.h @@ -119,6 +119,9 @@ #define SRQ_DB_REG 0x230 #define HNS_ROCE_QP_BANK_NUM 8 +#define HNS_ROCE_CQ_BANK_NUM 4 + +#define CQ_BANKID_SHIFT 2 /* The chip implementation of the consumer index is calculated * according to twice the actual EQ depth @@ -536,9 +539,10 @@ struct hns_roce_qp_table { }; struct hns_roce_cq_table { - struct hns_roce_bitmap bitmap; struct xarray array; struct hns_roce_hem_table table; + struct hns_roce_bank bank[HNS_ROCE_CQ_BANK_NUM]; + struct mutex bank_mutex; }; struct hns_roce_srq_table { @@ -779,7 +783,7 @@ struct hns_roce_caps { u32 max_cqes; u32 min_cqes; u32 min_wqes; - int reserved_cqs; + u32 reserved_cqs; int reserved_srqs; int num_aeq_vectors; int num_comp_vectors; @@ -1164,7 +1168,7 @@ int hns_roce_mtr_map(struct hns_roce_dev *hr_dev, struct hns_roce_mtr *mtr, int hns_roce_init_pd_table(struct hns_roce_dev *hr_dev); int hns_roce_init_mr_table(struct hns_roce_dev *hr_dev); -int hns_roce_init_cq_table(struct hns_roce_dev *hr_dev); +void hns_roce_init_cq_table(struct hns_roce_dev *hr_dev); int hns_roce_init_qp_table(struct hns_roce_dev *hr_dev); int hns_roce_init_srq_table(struct hns_roce_dev *hr_dev); diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c index d9179ba..2b78b1f 100644 --- a/drivers/infiniband/hw/hns/hns_roce_main.c +++ b/drivers/infiniband/hw/hns/hns_roce_main.c @@ -748,11 +748,7 @@ static int hns_roce_setup_hca(struct hns_roce_dev *hr_dev) goto err_pd_table_free; } - ret = hns_roce_init_cq_table(hr_dev); - if (ret) { - dev_err(dev, "Failed to init completion queue table.\n"); - goto err_mr_table_free; - } + hns_roce_init_cq_table(hr_dev); ret = hns_roce_init_qp_table(hr_dev); if (ret) { @@ -777,8 +773,6 @@ static int hns_roce_setup_hca(struct hns_roce_dev *hr_dev) err_cq_table_free: hns_roce_cleanup_cq_table(hr_dev); - -err_mr_table_free: hns_roce_cleanup_mr_table(hr_dev); err_pd_table_free: -- 2.8.1

2 1

Re: [PATCH v3 01/22] ethdev: fix MTU size exceeds max rx packet length
by oulijun 18 Jan '21

18 Jan '21

Hi Steve This is a very good job! But I have some question and suggestions. Please check it. 在 2021/1/14 17:45, Steve Yang 写道: > Ethdev is using default Ethernet overhead to decide if provided > 'max_rx_pkt_len' value is bigger than max (non jumbo) MTU value, > and limits it to MAX if it is. > > Since the application/driver used Ethernet overhead is different than > the ethdev one, check result is wrong. > > If the driver is using Ethernet overhead bigger than the default one, > the provided 'max_rx_pkt_len' is trimmed down, and in the driver when > correct Ethernet overhead is used to convert back, the resulting MTU is > less than the intended one, causing some packets to be dropped. > > Like, > app -> max_rx_pkt_len = 1500/*mtu*/ + 22/*overhead*/ = 1522 > ethdev -> 1522 > 1518/*MAX*/; max_rx_pkt_len = 1518 > driver -> MTU = 1518 - 22 = 1496 > Packets with size 1497-1500 are dropped although intention is to be able > to send/receive them. > > The fix is to make ethdev use the correct Ethernet overhead for port, > instead of default one. > > Fixes: 59d0ecdbf0e1 ("ethdev: MTU accessors") > > Signed-off-by: Steve Yang <stevex.yang(a)intel.com> > --- > lib/librte_ethdev/rte_ethdev.c | 27 ++++++++++++++++++++++++--- > 1 file changed, 24 insertions(+), 3 deletions(-) > > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c > index 17ddacc78d..19ca4c4512 100644 > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > @@ -1292,8 +1292,10 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, > struct rte_eth_dev *dev; > struct rte_eth_dev_info dev_info; > struct rte_eth_conf orig_conf; > + uint16_t overhead_len; > int diag; > int ret; > + uint16_t old_mtu; > > RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); > > @@ -1319,10 +1321,20 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, > memcpy(&dev->data->dev_conf, dev_conf, > sizeof(dev->data->dev_conf)); > > + /* Backup mtu for rollback */ > + old_mtu = dev->data->mtu; > + > ret = rte_eth_dev_info_get(port_id, &dev_info); > if (ret != 0) > goto rollback; > > + /* Get the real Ethernet overhead length */ > + if (dev_info.max_mtu != UINT16_MAX && > + dev_info.max_rx_pktlen > dev_info.max_mtu) > + overhead_len = dev_info.max_rx_pktlen - dev_info.max_mtu; > + else > + overhead_len = RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN; > + The Ethernet frame header length supported by each NIC may be different, which cause the difference of allowed packets size and drop you say. The diference of Ethernet frame header length have an impact for the maximum Ethernet frame length, which is a boundary value of enabling jumbo frame through the ' max_rx_pkt_len '. However, we need to do the same thing you do above to get the overhead_len every time, which will cause a lot of duplicate code in the framework and app. For examples, parsing and processing for '--max-pkt-len=xxx' parameter, and " cmd_config_max_pkt_len_parsed " in testpmd, and here modifying here dev_configure API. It's a little redundant and troublesome. Maybe, it is necessary for driver to directly report the supported maximum Ethernet frame length by rte_dev_info_get API. As following: struct rte_eth_dev_info { xxxx /** * The maximum Ethernet frame length supported by each * driver varies with the Ethernet header length. */ uint16_t eth_max_len; xxxx } int rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info) { xxx dev_info->min_mtu = RTE_ETHER_MIN_MTU; dev_info->max_mtu = UINT16_MAX; dev_info->eth_max_len = RTE_ETHER_MAX_LEN; xxx } And then: xxx_devv_infos_get(struct rte_eth_dev *eth_dev, struct rte_eth_dev_info *info) { xxx info->eth_max_len = xxx_ETHER_MAX _LEN; xxx } What do you think? > /* If number of queues specified by application for both Rx and Tx is > * zero, use driver preferred values. This cannot be done individually > * as it is valid for either Tx or Rx (but not both) to be zero. > @@ -1410,11 +1422,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, > goto rollback; > } > } else { > - if (dev_conf->rxmode.max_rx_pkt_len < RTE_ETHER_MIN_LEN || > - dev_conf->rxmode.max_rx_pkt_len > RTE_ETHER_MAX_LEN) > + uint16_t pktlen = dev_conf->rxmode.max_rx_pkt_len; > + if (pktlen < RTE_ETHER_MIN_MTU + overhead_len || > + pktlen > RTE_ETHER_MTU + overhead_len) > /* Use default value */ > dev->data->dev_conf.rxmode.max_rx_pkt_len = > - RTE_ETHER_MAX_LEN; > + RTE_ETHER_MTU + overhead_len; > + } > + > + /* Scale the MTU size to adapt max_rx_pkt_len */ > + if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) { > + dev->data->mtu = dev->data->dev_conf.rxmode.max_rx_pkt_len - > + overhead_len; > } Now that we update mtu here when jumbo frame enabled. It is necessary to check validity of max_rx_pkt_len. As following: if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) { if (dev_conf->rxmode.max_rx_pkt_len > dev_info.max_rx_pktlen || dev_conf->rxmode.max_rx_pkt_len <= RTE_ETHER_MTU + overhead_len) { xxxx } } else { xxx } If it does not thing above, which will cause an unreasonable case. Like, dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME == 1 dev_conf->rxmode.max_rx_pkt_len = 1500 overhead_len = 26 dev->data->mtu = dev_conf->rxmode.max_rx_pkt_len - overhead_len = 1500 - 26 = 1474 In fact, DEV_RX_OFFLOAD_JUMBO_FRAME is set to rxmode.offloads when mtu > 1500. > > /* > @@ -1549,6 +1568,8 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, > eth_dev_tx_queue_config(dev, 0); > rollback: > memcpy(&dev->data->dev_conf, &orig_conf, sizeof(dev->data->dev_conf)); > + if (old_mtu != dev->data->mtu) > + dev->data->mtu = old_mtu; > > rte_ethdev_trace_configure(port_id, nb_rx_q, nb_tx_q, dev_conf, ret); > return ret; >

2 1

[PATCH] maintainers: remove maintainer for hns3
by Lijun Ou 18 Jan '21

18 Jan '21

Because Wei Hu has changed to a new job and the email address(xavier.huwei(a)huawei.com) has expired, we remove him from the hns3 maintainer list. All patches signed-off-by Wei Hu will be copied to Lijun Ou. Signed-off-by: Lijun Ou <oulijun(a)huawei.com> --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 76ed473..7a16af3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -648,7 +648,6 @@ F: doc/guides/nics/enic.rst F: doc/guides/nics/features/enic.ini Hisilicon hns3 -M: Wei Hu (Xavier) <xavier.huwei(a)huawei.com> M: Min Hu (Connor) <humin29(a)huawei.com> M: Yisen Zhuang <yisen.zhuang(a)huawei.com> M: Lijun Ou <oulijun(a)huawei.com> -- 2.7.4

2 1

Re: [PATCH v13 08/15] iommu/smmuv3: Implement cache_invalidate
by chenxiang (M) 16 Jan '21

16 Jan '21

Hi Eric, 在 2020/11/18 19:21, Eric Auger 写道: > Implement domain-selective and page-selective IOTLB invalidations. > > Signed-off-by: Eric Auger <eric.auger(a)redhat.com> > > --- > v7 -> v8: > - ASID based invalidation using iommu_inv_pasid_info > - check ARCHID/PASID flags in addr based invalidation > - use __arm_smmu_tlb_inv_context and __arm_smmu_tlb_inv_range_nosync > > v6 -> v7 > - check the uapi version > > v3 -> v4: > - adapt to changes in the uapi > - add support for leaf parameter > - do not use arm_smmu_tlb_inv_range_nosync or arm_smmu_tlb_inv_context > anymore > > v2 -> v3: > - replace __arm_smmu_tlb_sync by arm_smmu_cmdq_issue_sync > > v1 -> v2: > - properly pass the asid > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 53 +++++++++++++++++++++ > 1 file changed, 53 insertions(+) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > index fdecc9f17b36..24124361dd3b 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > @@ -2771,6 +2771,58 @@ static void arm_smmu_detach_pasid_table(struct iommu_domain *domain) > mutex_unlock(&smmu_domain->init_mutex); > } > > +static int > +arm_smmu_cache_invalidate(struct iommu_domain *domain, struct device *dev, > + struct iommu_cache_invalidate_info *inv_info) > +{ > + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); > + struct arm_smmu_device *smmu = smmu_domain->smmu; > + > + if (smmu_domain->stage != ARM_SMMU_DOMAIN_NESTED) > + return -EINVAL; > + > + if (!smmu) > + return -EINVAL; > + > + if (inv_info->version != IOMMU_CACHE_INVALIDATE_INFO_VERSION_1) > + return -EINVAL; > + > + if (inv_info->cache & IOMMU_CACHE_INV_TYPE_IOTLB) { > + if (inv_info->granularity == IOMMU_INV_GRANU_PASID) { > + struct iommu_inv_pasid_info *info = > + &inv_info->granu.pasid_info; > + > + if (!(info->flags & IOMMU_INV_PASID_FLAGS_ARCHID) || > + (info->flags & IOMMU_INV_PASID_FLAGS_PASID)) > + return -EINVAL; > + > + __arm_smmu_tlb_inv_context(smmu_domain, info->archid); > + > + } else if (inv_info->granularity == IOMMU_INV_GRANU_ADDR) { > + struct iommu_inv_addr_info *info = &inv_info->granu.addr_info; > + size_t size = info->nb_granules * info->granule_size; > + bool leaf = info->flags & IOMMU_INV_ADDR_FLAGS_LEAF; > + > + if (!(info->flags & IOMMU_INV_ADDR_FLAGS_ARCHID) || > + (info->flags & IOMMU_INV_ADDR_FLAGS_PASID)) > + return -EINVAL; > + > + __arm_smmu_tlb_inv_range(info->addr, size, > + info->granule_size, leaf, > + smmu_domain, info->archid); When debugging with vSMMU on ARM64 huawei platform, there is a issue: RIL feature is enabled on guest OS while it is not supported on host OS, with some operations (such as rmmod driver during iperf between guest and host), SMMU translation error occurs frequently, and it works well if RIL feature is disabled on guest OS. We find that in function vfio_iommu_unmap_notify() (qemu code) it passes total size of tlb (num_pages * granule_size) as granule size to host OS : addr_info->granules_size = size addr_info->nb_granule = 1 So total size (num_pages * granule_size) is passed as granule size to function __arm_smmu_inv_range(), if RIL feature is not supported, then total size may be not the granule size that host OS can recongize, i will only invalidate part of tlb it wants to invalidate (for example, 4K/2M/1G pagesize is supported on host OS, if total_size = 8K, then addr_info->granule_size = 8K, addr_info->nb_granule = 1, as RIL feature is not supported, it invalidates just 4K one time but it thought it had invalidated 8K). Please have a check of the issue, and we have a temporary fix as follows on the issue. hw/arm/smmuv3.c | 3 ++- hw/vfio/common.c | 6 +++--- include/exec/memory.h | 1 + 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c index 6725019..891a65d 100644 --- a/hw/arm/smmuv3.c +++ b/hw/arm/smmuv3.c @@ -821,7 +821,8 @@ static void smmuv3_notify_iova(IOMMUMemoryRegion *mr, entry.target_as = &address_space_memory; entry.iova = iova; - entry.addr_mask = num_pages * (1 << granule) - 1; + entry.addr_mask = (1 << granule) - 1; + entry.num_pages = num_pages; entry.perm = IOMMU_NONE; entry.arch_id = asid; entry.flags = IOMMU_INV_GRANU_ADDR; diff --git a/hw/vfio/common.c b/hw/vfio/common.c index 5d365e0..c0164b1 100644 --- a/hw/vfio/common.c +++ b/hw/vfio/common.c @@ -604,7 +604,7 @@ static void vfio_iommu_unmap_notify(IOMMUNotifier *n, IOMMUTLBEntry *iotlb) hwaddr start = iotlb->iova + giommu->iommu_offset; VFIOContainer *container = giommu->container; struct vfio_iommu_type1_cache_invalidate ustruct = {}; - size_t size = iotlb->addr_mask + 1; + size_t size = iotlb->num_pages * (iotlb->addr_mask + 1); int ret; assert(iotlb->perm == IOMMU_NONE); @@ -632,8 +632,8 @@ static void vfio_iommu_unmap_notify(IOMMUNotifier *n, IOMMUTLBEntry *iotlb) } addr_info->archid = iotlb->arch_id; addr_info->addr = start; - addr_info->granule_size = size; - addr_info->nb_granules = 1; + addr_info->granule_size = iotlb->addr_mask + 1; + addr_info->nb_granules = iotlb->num_pages; } trace_vfio_iommu_addr_inv_iotlb(iotlb->arch_id, start, size, 1, iotlb->leaf); diff --git a/include/exec/memory.h b/include/exec/memory.h index 21959a7..aa8d43e 100644 --- a/include/exec/memory.h +++ b/include/exec/memory.h @@ -103,6 +103,7 @@ struct IOMMUTLBEntry { hwaddr iova; hwaddr translated_addr; hwaddr addr_mask; + uint64_t num_pages; IOMMUAccessFlags perm; uint32_t arch_id; uint32_t flags;

1 0

Re: [RESEND PATCH v3 0/4] iommu/iova: Solve longterm IOVA issue
by John Garry 15 Jan '21

15 Jan '21

+ linux-scsi (see https://lore.kernel.org/linux-iommu/1607538189-237944-4-git-send-email-john…) On 17/11/2020 10:25, John Garry wrote: > This series contains a patch to solve the longterm IOVA issue which > leizhen originally tried to address at [0]. > > A sieved kernel log is at the following, showing periodic dumps of IOVA > sizes, per CPU and per depot bin, per IOVA size granule: > https://raw.githubusercontent.com/hisilicon/kernel-dev/topic-iommu-5.10-iov… > > Notice, for example, the following logs: > [13175.355584] print_iova1 cpu_total=40135 depot_total=3866 total=44001 > [83483.457858] print_iova1 cpu_total=62532 depot_total=24476 total=87008 > > Where total IOVA rcache size has grown from 44K->87K over a long time. > JFYI, I am able to reproduce this aging issue on another storage card, an LSI SAS 3008, so now it's harder to say it's an issue specific to a (buggy) single driver. A log of the IOVA size dumps is here: https://raw.githubusercontent.com/hisilicon/kernel-dev/064c4dc8869b3f2ad07e… Notice again how the total IOVA size goes up over time, like: [ 68.176914] print_iova1 cpu_total=23663 depot_total=256 total=23919 [ 2337.008194] print_iova1 cpu_total=67361 depot_total=9088 total=76449 [17141.860078] print_iova1 cpu_total=73397 depot_total=10368 total=83765 [27087.850830] print_iova1 cpu_total=73386 depot_total=10624 total=84010 [10434.042877] print_iova1 cpu_total=90652 depot_total=12928 total=103580 I had to change some settings for that storage card to reproduce, though [0]. Could explain why no other reports. So please consider this issue again... Thanks, john [0] https://lore.kernel.org/linux-scsi/dd8e6fdc-397d-b6ad-3371-0b65d1932ad1@hua… > Along with this patch, I included the following: > - A smaller helper to clear all IOVAs for a domain > - Change polarity of the IOVA magazine helpers > - Small optimisation from Cong Wang included, which was never applied [1]. > There was some debate of the other patches in that series, but this one > is quite straightforward. > > Differnces to v2: > - Update commit message for patch 3/4

1 0

[RFC PATCH] sched/fair: first try to fix the scheduling impact of NUMA diameter > 2
by Barry Song 15 Jan '21

15 Jan '21

This patch is a follow-up of the 3-hops issue reported by Valentin Schneider: [1] https://lore.kernel.org/lkml/jhjtux5edo2.mognet@arm.com/ [2] https://lore.kernel.org/lkml/20201110184300.15673-1-valentin.schneider@arm.… Here is a brief summary of the background: For a NUMA system with 3-hops, sched_group for NUMA 2-hops could be not a subset of sched_domain. For example, for a system with the below topology(two cpus in each NUMA node): node 0 1 2 3 0: 10 12 20 22 1: 12 10 22 24 2: 20 22 10 12 3: 22 24 12 10 For CPU0, domain-2 will span 0-5, but its group will span 0-3, 4-7. 4-7 isn't a subset of 0-5. CPU0 attaching sched-domain(s): domain-0: span=0-1 level=MC groups: 0:{ span=0 cap=989 }, 1:{ span=1 cap=1016 } domain-1: span=0-3 level=NUMA groups: 0:{ span=0-1 cap=2005 }, 2:{ span=2-3 cap=2028 } domain-2: span=0-5 level=NUMA groups: 0:{ span=0-3 cap=4033 }, 4:{ span=4-7 cap=3909 } ERROR: groups don't span domain->span domain-3: span=0-7 level=NUMA groups: 0:{ span=0-5 mask=0-1 cap=6062 }, 6:{ span=4-7 mask=6-7 cap=3928 } All other cpus also have the same issue: sched_group could be not a subset of sched_domain. Here I am trying to figure out the scheduling impact of this issue from two aspects: 1. find busiest cpu in load_balance 2. find idlest cpu in fork/exec/wake balance For case 1, load_balance() seems to be handling this issue correctly as it only fills cpus in sched_domain to the cpus of lb_env. Also, find_busiest_group() and find_busiest_queue() will result in scanning cpus within env.cpus only: static int load_balance(int this_cpu, struct rq *this_rq, struct sched_domain *sd, enum cpu_idle_type idle, int *continue_balancing) {` ... struct lb_env env = { ... .cpus = cpus, .fbq_type = all, .tasks = LIST_HEAD_INIT(env.tasks), }; /* added by barry: only cpus in sched_domain are put in lb_env */ cpumask_and(cpus, sched_domain_span(sd), cpu_active_mask); ... /* * added by barry: the below functions are only scanning cpus * in env.cpus */ group = find_busiest_group(&env); ... busiest = find_busiest_queue(&env, group); ... } But one thing which looks wrong is that update_sg_lb_stats() is only counting tasks in sched_domain, but sgs->group_capacity and sgs->group_weight are counting all cpus in the sched_group. Then finally, update_sg_lb_stats() uses the load of cpus which are in the sched_domain to calculate group_type and avg_load which can be seriously underestimated. This is explained in detail as the comments added by me in the code: static inline void update_sg_lb_stats() { int i, nr_running, local_group; /* added by barry: here it only counts cpu in the sched_domain */ for_each_cpu_and(i, sched_group_span(group), env->cpus) { ... sgs->group_load += cpu_load(rq); sgs->group_util += cpu_util(i); sgs->group_runnable += cpu_runnable(rq); sgs->sum_h_nr_running += rq->cfs.h_nr_running; nr_running = rq->nr_running; sgs->sum_nr_running += nr_running; ... } ... /* added by barry: here it count all cpus which might not be in the domain */ sgs->group_capacity = group->sgc->capacity; sgs->group_weight = group->group_weight; /* added by barry: finally the group_type and avg_load could be wrong */ sgs->group_type = group_classify(env->sd->imbalance_pct, group, sgs); if (sgs->group_type == group_overloaded) sgs->avg_load = (sgs->group_load * SCHED_CAPACITY_SCALE) / sgs->group_capacity; ... } For example, if we have 2 cpus in sched_domain and 4 cpus in sched_group, the code is using the load of 2 cpus to calculate the group_type and avg_load of 4 cpus, the sched_group is likely to get much lower load than the real case. This patch fixed it by only counting cpus within sched_domain for group_capacity and group_weight. For case 2, find_idlest_group() and find_idlest_group_cpu() don't use sched_domain for scanning at all. They are scanning all cpus in the sched_group though sched_group isn't a subset of sched_domain. So they can result in picking an idle cpu outside the sched_domain but inside the sched_group. This patch moved to only scan cpus within the sched_domain, which would be similar with load_balance(). For this moment, this is pretty much PoC code to get feedback. Signed-off-by: Barry Song <song.bao.hua(a)hisilicon.com> --- kernel/sched/fair.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 04a3ce20da67..f183dba4961e 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5901,7 +5901,7 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu); * find_idlest_group_cpu - find the idlest CPU among the CPUs in the group. */ static int -find_idlest_group_cpu(struct sched_group *group, struct task_struct *p, int this_cpu) +find_idlest_group_cpu(struct sched_domain *sd, struct sched_group *group, struct task_struct *p, int this_cpu) { unsigned long load, min_load = ULONG_MAX; unsigned int min_exit_latency = UINT_MAX; @@ -5916,6 +5916,10 @@ find_idlest_group_cpu(struct sched_group *group, struct task_struct *p, int this /* Traverse only the allowed CPUs */ for_each_cpu_and(i, sched_group_span(group), p->cpus_ptr) { + /* when sched_group isn't a subset of sched_domain */ + if (!cpumask_test_cpu(i, sched_domain_span(sd))) + continue; + if (sched_idle_cpu(i)) return i; @@ -5984,7 +5988,7 @@ static inline int find_idlest_cpu(struct sched_domain *sd, struct task_struct *p continue; } - new_cpu = find_idlest_group_cpu(group, p, cpu); + new_cpu = find_idlest_group_cpu(sd, group, p, cpu); if (new_cpu == cpu) { /* Now try balancing at a lower domain level of 'cpu': */ sd = sd->child; @@ -8416,6 +8420,8 @@ static inline void update_sg_lb_stats(struct lb_env *env, if ((env->flags & LBF_NOHZ_STATS) && update_nohz_stats(rq, false)) env->flags |= LBF_NOHZ_AGAIN; + sgs->group_capacity += capacity_of(i); + sgs->group_weight++; sgs->group_load += cpu_load(rq); sgs->group_util += cpu_util(i); sgs->group_runnable += cpu_runnable(rq); @@ -8462,10 +8468,6 @@ static inline void update_sg_lb_stats(struct lb_env *env, sgs->group_asym_packing = 1; } - sgs->group_capacity = group->sgc->capacity; - - sgs->group_weight = group->group_weight; - sgs->group_type = group_classify(env->sd->imbalance_pct, group, sgs); /* Computing avg_load makes sense only when group is overloaded */ @@ -8688,10 +8690,12 @@ static inline void update_sg_wakeup_stats(struct sched_domain *sd, memset(sgs, 0, sizeof(*sgs)); - for_each_cpu(i, sched_group_span(group)) { + for_each_cpu_and(i, sched_group_span(group), sched_domain_span(sd)) { struct rq *rq = cpu_rq(i); unsigned int local; + sgs->group_capacity += capacity_of(i); + sgs->group_weight++; sgs->group_load += cpu_load_without(rq, p); sgs->group_util += cpu_util_without(i, p); sgs->group_runnable += cpu_runnable_without(rq, p); @@ -8715,10 +8719,6 @@ static inline void update_sg_wakeup_stats(struct sched_domain *sd, sgs->group_misfit_task_load = 1; } - sgs->group_capacity = group->sgc->capacity; - - sgs->group_weight = group->group_weight; - sgs->group_type = group_classify(sd->imbalance_pct, group, sgs); /* -- 2.25.1

1 0

[RFC PATCH 0/2] EDAC/ghes: Add EDAC device for recording the CPU cache error count
by Shiju Jose 14 Jan '21

14 Jan '21

ARM64 server chip Kunpeng 920 occasionally detected L2 cache corrected errors on few hardware. Thus the probability of the CPU cache errors occurring often exists. The earlier failure detection by monitoring the cache corrected errors for the frequent occurrences and taking preventive action could prevent more serious hardware faults. For the firmware-first error handling, especially on ARM64 architectures, there is no provision for recording the CPU cache corrected error count is present. For Intel architectures cache corrected errors reporting and offline the cores is done through more architecture specific method. http://www.mcelog.org/cache.html For this purpose, the suggestion was to create the CPU EDAC device for the CPU caches for recording the cache error count. The EDAC device blocks for the CPU caches would be created based on the cache information obtained from the cpu_cacheinfo. User-space application could monitor the recorded corrected error count for the earlier hardware failure detection and could take preventive action. Changes: RFC V1 -> RFC V2: 1. Fixed feedback by Boris. 1.1. Added reason of this patch. 1.2. Changed CPU errors to CPU cache errors in the drivers/edac/Kconfig 1.3 Changed EDAC cache list to percpu variables. 2. Changes in the descriptions. Shiju Jose (2): EDAC/ghes: Add EDAC device for reporting the CPU cache errors ACPI / APEI: Add reporting ARM64 CPU cache corrected error count Documentation/ABI/testing/sysfs-devices-edac | 15 ++ drivers/acpi/apei/ghes.c | 76 +++++++- drivers/edac/Kconfig | 10 + drivers/edac/ghes_edac.c | 181 +++++++++++++++++++ include/acpi/ghes.h | 27 +++ include/linux/cper.h | 4 + 6 files changed, 309 insertions(+), 4 deletions(-) -- 2.17.1

1 2

2024

2023

2022

2021

2020

Linuxarm