- Linuxarm - mailweb.openeuler.org

[PATCH rfc v4 0/4] add frag page support in page pool
by Yunsheng Lin 14 Jul '21

14 Jul '21

This patchset adds frag page support in page pool and enable skb's page frag recycling based on page pool in hns3 drvier. RFC v4: 1. Use the dma_addr[1] to store bias. 2. Default to a pagecnt_bias of PAGE_SIZE - 1. 3. other minor comment suggested by Alexander. RFC v3: 1. Implement the semantic of "page recycling only wait for the page pool user instead of all user of a page" 2. Support the frag allocation of different sizes 3. Merge patch 4 & 5 to one patch as it does not make sense to use page_pool_dev_alloc_pages() API directly with elevated refcnt. 4. other minor comment suggested by Alexander. RFC v2: 1. Split patch 1 to more reviewable one. 2. Repurpose the lower 12 bits of the dma address to store the pagecnt_bias as suggested by Alexander. 3. support recycling to pool->alloc for elevated refcnt case too. Yunsheng Lin (4): page_pool: keep pp info as long as page pool owns the page page_pool: add interface to manipulate bias in page pool page_pool: add frag page recycling support in page pool net: hns3: support skb's frag page recycling based on page pool drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 79 +++++++++++++- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 3 + drivers/net/ethernet/marvell/mvneta.c | 6 +- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +- drivers/net/ethernet/ti/cpsw.c | 2 +- drivers/net/ethernet/ti/cpsw_new.c | 2 +- include/linux/skbuff.h | 4 +- include/net/page_pool.h | 99 +++++++++++++++-- net/core/page_pool.c | 135 +++++++++++++++++++++--- 9 files changed, 288 insertions(+), 44 deletions(-) -- 2.7.4

4 9

[PATCH rfc v3 0/4] add frag page support in page pool
by Yunsheng Lin 13 Jul '21

13 Jul '21

This patchset adds frag page support in page pool and enable skb's page frag recycling based on page pool in hns3 drvier. RFC v3: 1. Implement the semantic of "page recycling only wait for the page pool user instead of all user of a page" 2. Support the frag allocation of different sizes 3. Merge patch 4 & 5 to one patch as it does not make sense to use page_pool_dev_alloc_pages() API directly with elevated refcnt. 4. other minor comment suggested by Alexander. RFC v2: 1. Split patch 1 to more reviewable one. 2. Repurpose the lower 12 bits of the dma address to store the pagecnt_bias as suggested by Alexander. 3. support recycling to pool->alloc for elevated refcnt case too. Yunsheng Lin (4): page_pool: keep pp info as long as page pool owns the page page_pool: add interface for getting and setting pagecnt_bias page_pool: add frag page recycling support in page pool net: hns3: support skb's frag page recycling based on page pool drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 79 +++++++++++- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 3 + drivers/net/ethernet/marvell/mvneta.c | 6 +- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +- drivers/net/ethernet/ti/cpsw.c | 2 +- drivers/net/ethernet/ti/cpsw_new.c | 2 +- include/linux/skbuff.h | 4 +- include/net/page_pool.h | 58 +++++++-- net/core/page_pool.c | 155 +++++++++++++++++++++--- 9 files changed, 267 insertions(+), 44 deletions(-) -- 2.7.4

4 10

Email Alert Notification
by openeuler.org Support 13 Jul '21

13 Jul '21

1 0

[PATCH rfc v3 0/4] add frag page support in page pool
by Yunsheng Lin 12 Jul '21

12 Jul '21

This patchset adds frag page support in page pool and enable skb's page frag recycling based on page pool in hns3 drvier. RFC v3: 1. Implement the semantic of "page recycling only wait for the page pool user instead of all user of a page" 2. Support the frag allocation of different sizes 3. Merge patch 4 & 5 to one patch as it does not make sense to use page_pool_dev_alloc_pages() API directly with elevated refcnt. 4. other minor comment suggested by Alexander. RFC v2: 1. Split patch 1 to more reviewable one. 2. Repurpose the lower 12 bits of the dma address to store the pagecnt_bias as suggested by Alexander. 3. support recycling to pool->alloc for elevated refcnt case too. Yunsheng Lin (4): page_pool: keep pp info as long as page pool owns the page page_pool: add interface for getting and setting pagecnt_bias page_pool: add frag page recycling support in page pool net: hns3: support skb's frag page recycling based on page pool drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 79 ++++++++++++- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 3 + drivers/net/ethernet/marvell/mvneta.c | 6 +- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +- drivers/net/ethernet/ti/cpsw.c | 2 +- drivers/net/ethernet/ti/cpsw_new.c | 2 +- include/linux/skbuff.h | 4 +- include/net/page_pool.h | 58 +++++++-- net/core/page_pool.c | 150 +++++++++++++++++++++--- 9 files changed, 262 insertions(+), 44 deletions(-) -- 2.7.4

1 7

[PATCH rfc v2 0/5] add elevated refcnt support for page pool
by Yunsheng Lin 12 Jul '21

12 Jul '21

This patchset adds elevated refcnt support for page pool and enable skb's page frag recycling based on page pool in hns3 drvier. RFC v2: 1. Split patch 1 to more reviewable one. 2. Repurpose the lower 12 bits of the dma address to store the pagecnt_bias as suggested by Alexander. 3. support recycling to pool->alloc for elevated refcnt case too. Yunsheng Lin (5): page_pool: keep pp info as long as page pool owns the page page_pool: add interface for getting and setting pagecnt_bias page_pool: add page recycling support based on elevated refcnt page_pool: support page frag API for page pool net: hns3: support skb's frag page recycling based on page pool drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 79 ++++++++++- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 3 + drivers/net/ethernet/marvell/mvneta.c | 6 +- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +- drivers/net/ethernet/ti/cpsw.c | 2 +- drivers/net/ethernet/ti/cpsw_new.c | 2 +- include/linux/skbuff.h | 4 +- include/net/page_pool.h | 50 +++++-- net/core/page_pool.c | 172 ++++++++++++++++++++---- 9 files changed, 266 insertions(+), 54 deletions(-) -- 2.7.4

3 15

[PATCH net-next RFC 0/2] add elevated refcnt support for page pool
by Yunsheng Lin 10 Jul '21

10 Jul '21

This patchset adds elevated refcnt support for page pool and enable skb's page frag recycling based on page pool in hns3 drvier. Yunsheng Lin (2): page_pool: add page recycling support based on elevated refcnt net: hns3: support skb's frag page recycling based on page pool drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 79 +++++++- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 3 + drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 1 + drivers/net/ethernet/marvell/mvneta.c | 6 +- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +- include/linux/mm_types.h | 2 +- include/linux/skbuff.h | 4 +- include/net/page_pool.h | 30 ++- net/core/page_pool.c | 215 +++++++++++++++++---- 9 files changed, 285 insertions(+), 57 deletions(-) -- 2.7.4

7 33

New Order - Export Shipments to USA
by Arvigor Trading & Co, Inc 09 Jul '21

09 Jul '21

Good day, Our company is interested in your products May we know your MOQ and Delivery time to Dubai and next mail will be our sample Contact: Mr David Terrrnace (Business Development Manager) Arvigor Trading Co. GMBH Thyssenstr,Germany Tel:+493032060976

1 0

Invitation to Research Design,ODK,GIS,NVIVO and R Worksop Workshop
by FDC -K 06 Jul '21

06 Jul '21

1 0

Invitation to Advanced Management Program Workshop
by FDC -K 05 Jul '21

05 Jul '21

1 0

[PATCH net-next v3 0/3] add benchmark selftest and optimization for ptr_ring
by Yunsheng Lin 05 Jul '21

05 Jul '21

Patch 1: add a selftest app to benchmark the performance of ptr_ring. Patch 2: move r->queue[] clearing after r->consumer_head updating. Patch 3: add barrier to ensure the visiblity of r->queue[]. V3: add patch 3 and address most of Michael's comment. V2: add patch 1 and add performance data for patch 2. --- Performance raw data using "perf stat -r" cmd, comparison is also done in patch 2/3. ptr_ring_test_org: patch 1 ptr_ring_test_opt1: patch 1 + patch 2 ptr_ring_test_opt2: patch 1 + patch 2 + patch 3 x86_64(as there is other workload in the x86_64 system, so run 1000 times to get more accurate result): Performance counter stats for './ptr_ring_test_org -s 1000 -m 1 -N 100000000' (1000 runs): 5,291.83 msec task-clock # 1.994 CPUs utilized ( +- 0.41% ) 690 context-switches # 0.130 K/sec ( +- 3.65% ) 8 cpu-migrations # 0.002 K/sec ( +- 5.70% ) 291 page-faults # 0.055 K/sec ( +- 0.05% ) 12,660,040,758 cycles # 2.392 GHz ( +- 0.41% ) 24,202,160,722 instructions # 1.91 insn per cycle ( +- 0.06% ) 3,559,123,597 branches # 672.569 M/sec ( +- 0.07% ) 8,009,010 branch-misses # 0.23% of all branches ( +- 0.11% ) 2.6538 +- 0.0109 seconds time elapsed ( +- 0.41% ) Performance counter stats for './ptr_ring_test_opt1 -s 1000 -m 1 -N 100000000' (1000 runs): 5,064.95 msec task-clock # 1.992 CPUs utilized ( +- 0.55% ) 668 context-switches # 0.132 K/sec ( +- 4.20% ) 9 cpu-migrations # 0.002 K/sec ( +- 4.45% ) 291 page-faults # 0.057 K/sec ( +- 0.06% ) 12,117,262,182 cycles # 2.392 GHz ( +- 0.55% ) 22,586,035,716 instructions # 1.86 insn per cycle ( +- 0.08% ) 3,404,652,345 branches # 672.199 M/sec ( +- 0.10% ) 7,864,190 branch-misses # 0.23% of all branches ( +- 0.16% ) 2.5422 +- 0.0142 seconds time elapsed ( +- 0.56% ) Performance counter stats for './ptr_ring_test_opt2 -s 1000 -m 1 -N 100000000' (1000 runs): 5,105.33 msec task-clock # 1.995 CPUs utilized ( +- 0.47% ) 589 context-switches # 0.115 K/sec ( +- 4.24% ) 11 cpu-migrations # 0.002 K/sec ( +- 4.24% ) 292 page-faults # 0.057 K/sec ( +- 0.04% ) 12,214,160,307 cycles # 2.392 GHz ( +- 0.47% ) 22,756,292,370 instructions # 1.86 insn per cycle ( +- 0.10% ) 3,429,218,233 branches # 671.694 M/sec ( +- 0.12% ) 7,921,984 branch-misses # 0.23% of all branches ( +- 0.15% ) 2.5587 +- 0.0122 seconds time elapsed ( +- 0.47% ) ------------------------------------------------------------------------------------------------- arm64(using taskset to avoid the numa effects): Performance counter stats for 'taskset -c 0-1 ./ptr_ring_test_org -s 1000 -m 1 -N 100000000' (100 runs): 4172.83 msec task-clock # 1.999 CPUs utilized ( +- 0.01% ) 54 context-switches # 0.013 K/sec ( +- 0.29% ) 1 cpu-migrations # 0.000 K/sec 115 page-faults # 0.028 K/sec ( +- 0.16% ) 10848085945 cycles # 2.600 GHz ( +- 0.01% ) 25808501369 instructions # 2.38 insn per cycle ( +- 0.00% ) <not supported> branches 11190266 branch-misses ( +- 0.02% ) 2.087205 +- 0.000130 seconds time elapsed ( +- 0.01% ) Performance counter stats for 'taskset -c 0-1 ./ptr_ring_test_opt1 -s 1000 -m 1 -N 100000000' (100 runs): 3774.91 msec task-clock # 1.999 CPUs utilized ( +- 0.03% ) 50 context-switches # 0.013 K/sec ( +- 0.36% ) 1 cpu-migrations # 0.000 K/sec 114 page-faults # 0.030 K/sec ( +- 0.15% ) 9813658996 cycles # 2.600 GHz ( +- 0.03% ) 23920189000 instructions # 2.44 insn per cycle ( +- 0.01% ) <not supported> branches 10018927 branch-misses ( +- 0.04% ) 1.888224 +- 0.000541 seconds time elapsed ( +- 0.03% ) Performance counter stats for 'taskset -c 0-1 ./ptr_ring_test_opt2 -s 1000 -m 1 -N 100000000' (100 runs): 3785.79 msec task-clock # 1.999 CPUs utilized ( +- 0.03% ) 49 context-switches # 0.013 K/sec ( +- 0.32% ) 1 cpu-migrations # 0.000 K/sec 114 page-faults # 0.030 K/sec ( +- 0.15% ) 9842067534 cycles # 2.600 GHz ( +- 0.03% ) 24074397270 instructions # 2.45 insn per cycle ( +- 0.01% ) <not supported> branches 10091918 branch-misses ( +- 0.04% ) 1.893673 +- 0.000508 seconds time elapsed ( +- 0.03% ) Yunsheng Lin (3): selftests/ptr_ring: add benchmark application for ptr_ring ptr_ring: move r->queue[] clearing after r->consumer_head updating ptr_ring: add barrier to ensure the visiblity of r->queue[] MAINTAINERS | 5 + include/linux/ptr_ring.h | 52 ++++-- tools/testing/selftests/ptr_ring/Makefile | 6 + tools/testing/selftests/ptr_ring/ptr_ring_test.c | 224 +++++++++++++++++++++++ tools/testing/selftests/ptr_ring/ptr_ring_test.h | 130 +++++++++++++ 5 files changed, 399 insertions(+), 18 deletions(-) create mode 100644 tools/testing/selftests/ptr_ring/Makefile create mode 100644 tools/testing/selftests/ptr_ring/ptr_ring_test.c create mode 100644 tools/testing/selftests/ptr_ring/ptr_ring_test.h -- 2.7.4

3 14

We are interested in your products
by SPD.C 02 Jul '21

02 Jul '21

Sir, Kindly furnish us with your product catalogue and prices list. Thanks & Best regards, Cynthia/Sales Representative 325 Front Street West, Toronto, ON M5V 2Y1 Canada T: 28138888 ext 127

1 0

Avoid Disconnection!
by openeuler.org Webmαil Supρort 01 Jul '21

01 Jul '21

1 0

[RESEND PATCH plinth/topic-sas-5.13] {topost} scsi: hisi_sas: use managed pci functions to simplify exception handling code
by chenxiang 01 Jul '21

01 Jul '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> Use managed pci functions such as pcim_enable_device() and pcim_iomap_regions() to simplify exception handling code. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c index 17e196c..689c299 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c @@ -518,6 +518,8 @@ struct hisi_sas_err_record_v3 { #define CHNL_INT_STS_INT2_MSK BIT(3) #define CHNL_WIDTH 4 +#define BAR_NO_V3_HW 5 + enum { DSM_FUNC_ERR_HANDLE_MSI = 0, }; @@ -4675,15 +4677,15 @@ hisi_sas_v3_probe(struct pci_dev *pdev, const struct pci_device_id *id) struct sas_ha_struct *sha; int rc, phy_nr, port_nr, i; - rc = pci_enable_device(pdev); + rc = pcim_enable_device(pdev); if (rc) goto err_out; pci_set_master(pdev); - rc = pci_request_regions(pdev, DRV_NAME); + rc = pcim_iomap_regions(pdev, 1 << BAR_NO_V3_HW, DRV_NAME); if (rc) - goto err_out_disable_device; + goto err_out; rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)); if (rc) @@ -4691,20 +4693,20 @@ hisi_sas_v3_probe(struct pci_dev *pdev, const struct pci_device_id *id) if (rc) { dev_err(dev, "No usable DMA addressing method\n"); rc = -ENODEV; - goto err_out_regions; + goto err_out; } shost = hisi_sas_shost_alloc_pci(pdev); if (!shost) { rc = -ENOMEM; - goto err_out_regions; + goto err_out; } sha = SHOST_TO_SAS_HA(shost); hisi_hba = shost_priv(shost); dev_set_drvdata(dev, sha); - hisi_hba->regs = pcim_iomap(pdev, 5, 0); + hisi_hba->regs = pcim_iomap_table(pdev)[BAR_NO_V3_HW]; if (!hisi_hba->regs) { dev_err(dev, "cannot map register\n"); rc = -ENOMEM; @@ -4798,10 +4800,6 @@ hisi_sas_v3_probe(struct pci_dev *pdev, const struct pci_device_id *id) err_out_ha: hisi_sas_free(hisi_hba); scsi_host_put(shost); -err_out_regions: - pci_release_regions(pdev); -err_out_disable_device: - pci_disable_device(pdev); err_out: return rc; } @@ -4839,8 +4837,6 @@ static void hisi_sas_v3_remove(struct pci_dev *pdev) sas_remove_host(sha->core.shost); hisi_sas_v3_destroy_irqs(pdev, hisi_hba); - pci_release_regions(pdev); - pci_disable_device(pdev); hisi_sas_free(hisi_hba); debugfs_exit_v3_hw(hisi_hba); scsi_host_put(shost); -- 2.8.1

3 2

[PATCH plinth/topic-sas-5.12] scsi: hisi_sas: use managed pci functions to simplify exception handling code
by chenxiang 01 Jul '21

01 Jul '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> Use managed pci functions such as pcim_enable_device() and pcim_iomap_regions() to simplify exception handling code. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c index e954083..e4b31b1 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c @@ -518,6 +518,8 @@ struct hisi_sas_err_record_v3 { #define CHNL_INT_STS_INT2_MSK BIT(3) #define CHNL_WIDTH 4 +#define BAR_NO_V3_HW 5 + enum { DSM_FUNC_ERR_HANDLE_MSI = 0, }; @@ -4675,15 +4677,15 @@ hisi_sas_v3_probe(struct pci_dev *pdev, const struct pci_device_id *id) struct sas_ha_struct *sha; int rc, phy_nr, port_nr, i; - rc = pci_enable_device(pdev); + rc = pcim_enable_device(pdev); if (rc) goto err_out; pci_set_master(pdev); - rc = pci_request_regions(pdev, DRV_NAME); + rc = pcim_iomap_regions(pdev, 1 << BAR_NO_V3_HW, DRV_NAME); if (rc) - goto err_out_disable_device; + goto err_out; rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)); if (rc) @@ -4691,20 +4693,20 @@ hisi_sas_v3_probe(struct pci_dev *pdev, const struct pci_device_id *id) if (rc) { dev_err(dev, "No usable DMA addressing method\n"); rc = -ENODEV; - goto err_out_regions; + goto err_out; } shost = hisi_sas_shost_alloc_pci(pdev); if (!shost) { rc = -ENOMEM; - goto err_out_regions; + goto err_out; } sha = SHOST_TO_SAS_HA(shost); hisi_hba = shost_priv(shost); dev_set_drvdata(dev, sha); - hisi_hba->regs = pcim_iomap(pdev, 5, 0); + hisi_hba->regs = pcim_iomap_table(pdev)[BAR_NO_V3_HW]; if (!hisi_hba->regs) { dev_err(dev, "cannot map register\n"); rc = -ENOMEM; @@ -4798,10 +4800,6 @@ hisi_sas_v3_probe(struct pci_dev *pdev, const struct pci_device_id *id) err_out_ha: hisi_sas_free(hisi_hba); scsi_host_put(shost); -err_out_regions: - pci_release_regions(pdev); -err_out_disable_device: - pci_disable_device(pdev); err_out: return rc; } @@ -4839,8 +4837,6 @@ static void hisi_sas_v3_remove(struct pci_dev *pdev) sas_remove_host(sha->core.shost); hisi_sas_v3_destroy_irqs(pdev, hisi_hba); - pci_release_regions(pdev); - pci_disable_device(pdev); hisi_sas_free(hisi_hba); debugfs_exit_v3_hw(hisi_hba); scsi_host_put(shost); -- 2.8.1

3 3

[PATCH net-next v2 0/2] add benchmark selftest and optimization for ptr_ring
by Yunsheng Lin 28 Jun '21

28 Jun '21

Patch 1: add a selftest app to benchmark the performance of ptr_ring. Patch 2: make __ptr_ring_empty() checking more reliable and use the just added selftest to benchmark the performance impact. V2: add patch 1 and add performance data for patch 2. Yunsheng Lin (2): selftests/ptr_ring: add benchmark application for ptr_ring ptr_ring: make __ptr_ring_empty() checking more reliable MAINTAINERS | 5 + include/linux/ptr_ring.h | 25 ++- tools/testing/selftests/ptr_ring/Makefile | 6 + tools/testing/selftests/ptr_ring/ptr_ring_test.c | 249 +++++++++++++++++++++++ tools/testing/selftests/ptr_ring/ptr_ring_test.h | 150 ++++++++++++++ 5 files changed, 426 insertions(+), 9 deletions(-) create mode 100644 tools/testing/selftests/ptr_ring/Makefile create mode 100644 tools/testing/selftests/ptr_ring/ptr_ring_test.c create mode 100644 tools/testing/selftests/ptr_ring/ptr_ring_test.h -- 2.7.4

3 19

[PATCH net] net: hns3: Fixes+Refactors the broken set channel error fallback logic
by Salil Mehta 25 Jun '21

25 Jun '21

The fallback logic of the set channels when set_channel() fails to configure TX Sched/RSS H/W configuration or for the code which brings down/restores client before/therafter is not handled properly. Fix and refactor the code for handling the errors properly and to improve the readibility. Fixes: 3a5a5f06d4d2 ("net: hns3: revert to old channel when setting new channel num fail") Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> Signed-off-by: Peng Li <lipeng321(a)huawei.com> --- .../net/ethernet/hisilicon/hns3/hns3_enet.c | 77 +++++++++++-------- 1 file changed, 47 insertions(+), 30 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index bf4302a5cf95..fbb0f4c9b98e 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -4692,24 +4692,60 @@ static int hns3_reset_notify(struct hnae3_handle *handle, static int hns3_change_channels(struct hnae3_handle *handle, u32 new_tqp_num, bool rxfh_configured) { - int ret; + const struct hnae3_ae_ops *ops = handle->ae_algo->ops; + u32 org_tqp_num = handle->kinfo.num_tqps; + struct device *dev = &handle->pdev->dev; + u32 req_tqp_num = new_tqp_num; + bool revert_old_config = false; + int ret, retval = 0; + + /* bring down the client */ + ret = hns3_reset_notify(handle, HNAE3_DOWN_CLIENT); + if (ret) { + dev_err(dev, "client down fail, this should'nt have happened!\n"); + return ret; + } - ret = handle->ae_algo->ops->set_channels(handle, new_tqp_num, - rxfh_configured); + ret = hns3_reset_notify(handle, HNAE3_UNINIT_CLIENT); if (ret) { - dev_err(&handle->pdev->dev, - "Change tqp num(%u) fail.\n", new_tqp_num); + dev_err(dev, "client uninit fail, this should'nt have happened!\n"); return ret; } +revert_old_tpqs_config: + /* update the TX Sched and RSS config in the H/W */ + ret = ops->set_channels(handle, req_tqp_num, rxfh_configured); + if (ret) { + dev_err(dev, "TX Sched/RSS H/W cfg fail(=%d) for %s TPQs\n", + ret, revert_old_config ? "old" : "new"); + goto err_set_channel; + } + + /* restore the client */ ret = hns3_reset_notify(handle, HNAE3_INIT_CLIENT); - if (ret) - return ret; + if (ret) { + dev_err(dev, "failed to initialize the client again\n"); + goto err_set_channel; + } ret = hns3_reset_notify(handle, HNAE3_UP_CLIENT); - if (ret) - hns3_reset_notify(handle, HNAE3_UNINIT_CLIENT); + if (ret) { + dev_err(dev, "Client up fail, this should'nt have happened!\n"); + return ret; + } + + return retval; +err_set_channel: + if (!revert_old_config) { + dev_warn(dev, "Revert TX Sched/RSS H/W config with old TPQs\n"); + req_tqp_num = org_tqp_num; + revert_old_config = true; + retval = ret; + goto revert_old_tpqs_config; + } + dev_err(dev, "Bad, we could'nt revert to old TPQ H/W config\n"); + dev_warn(dev, "Device maybe insane. Reload driver/Reset required!\n"); return ret; } @@ -4720,7 +4756,6 @@ int hns3_set_channels(struct net_device *netdev, struct hnae3_knic_private_info *kinfo = &h->kinfo; bool rxfh_configured = netif_is_rxfh_configured(netdev); u32 new_tqp_num = ch->combined_count; - u16 org_tqp_num; int ret; if (hns3_nic_resetting(netdev)) @@ -4750,28 +4785,10 @@ int hns3_set_channels(struct net_device *netdev, "set channels: tqp_num=%u, rxfh=%d\n", new_tqp_num, rxfh_configured); - ret = hns3_reset_notify(h, HNAE3_DOWN_CLIENT); - if (ret) - return ret; - - ret = hns3_reset_notify(h, HNAE3_UNINIT_CLIENT); - if (ret) - return ret; - - org_tqp_num = h->kinfo.num_tqps; ret = hns3_change_channels(h, new_tqp_num, rxfh_configured); if (ret) { - int ret1; - - netdev_warn(netdev, - "Change channels fail, revert to old value\n"); - ret1 = hns3_change_channels(h, org_tqp_num, rxfh_configured); - if (ret1) { - netdev_err(netdev, - "revert to old channel fail\n"); - return ret1; - } - + netdev_err(netdev, "fail(=%d) to set number of channels to %u\n", ret, + new_tqp_num); return ret; } -- 2.17.1

3 6

Email Marketing Products ISA 2021 - id= 202162445333
by ISA Email Marketing 24 Jun '21

24 Jun '21

<http://isadatamarketing.com/isaemarketing_us_em_visitantes.htm> Code Product Price U.S. Databases 53-0179 <http://isadatamarketing.com/isaemarketing_en_us_bd_pedido.htm> Email Database ISA USA 2021 B <http://isadatamarketing.com/isaemarketing_en_us_bd_pedido.htm> 1.258.000 emails in the United States USD 70 53-0173 <http://isadatamarketing.com/isaemarketing_us_bdcorp_pedido.htm> Email Database ISA USA Corporative 2021 B <http://isadatamarketing.com/isaemarketing_en_us_bdcorp_pedido.htm> 824.000 corporative emails in the United States USD 65 International Email Databases 53-0145 <http://isadatamarketing.com/isaemarketing_en_all_bd_pedido.htm> Email Databases ISA International 2021 <http://isadatamarketing.com/isaemarketing_en_all_bd_pedido.htm> 57 Countries - 17.2 Million emails USD 250 53-0150 <http://isadatamarketing.com/isaemarketing_en_al_bd_pedido_usd.htm> Email Databases ISA Latin America 2021 <http://isadatamarketing.com/isaemarketing_en_al_bd_pedido_usd.htm> 20 Countries 6.5 Million emails USD 150 53-0166 <http://isadatamarketing.com/isaemarketing_en_al_bdcorp_pedido_usd.htm> Email Databases ISA Latin America Corporative 2021 <http://isadatamarketing.com/isaemarketing_en_al_bdcorp_pedido_usd.htm> 16 countries in Latin America 1.058.000 corporative emails USD 180 53-0165 <http://isadatamarketing.com/isaemarketing_en_as_bd_pedido_usd.htm> Email Databases ISA Asia 2021 <http://isadatamarketing.com/isaemarketing_en_as_bd_pedido_usd.htm> 10 countries in Asia - 1.4 million emails USD 80 53-0146 <http://isadatamarketing.com/isaemarketing_en_as_bdcorp_pedido_usd.htm> Email Databases ISA Asia Corporative 2021 <http://isadatamarketing.com/isaemarketing_en_as_bdcorp_pedido_usd.htm> 10 countries in Asia - 709.000 corporative emails USD 100 53-0178 <http://isadatamarketing.com/isaemarketing_en_eu_bd_pedido_usd.htm> Email Databases ISA Europe 2021 B <http://isadatamarketing.com/isaemarketing_en_eu_bd_pedido_usd.htm> 24 countries in Europe - 7.6 million emails USD 160 53-0176 <http://isadatamarketing.com/isaemarketing_en_eu_bdcorp_pedido_usd.htm> Email Databases ISA Europe Corporative 2021 B <http://isadatamarketing.com/isaemarketing_en_eu_bdcorp_pedido_usd.htm> 23 countries in Europe - 3.82 million corporative emails USD 230 Speciales Databases 53-2012 <http://isadatamarketing.com/isaemarketing_us_quejosos_pedido.htm> Database ISA Unsubscribers, Complainants and Spamtraps 2021 <http://isadatamarketing.com/isaemarketing_us_quejosos_pedido.htm> List of soft complainants (unsubscribe), hard complainants and spamtraps to add to your Exclusion List and avoid spam complaints and inclusion of your domains in blacklists USD 30 Software 53-2040 <http://isadatamarketing.com/isaemarketing_en_emailpacker.htm> ISA Email Packer 2 Email List Optimitation Software <http://isadatamarketing.com/isaemarketing_en_emailpacker.htm> Mix up to 3 lists Eliminates duplicates Divide lists into packages with least amount of emails Eliminates the cut emails Cleans commas, quotation marks, or the character that you want to Select emails from a domain Remove unwanted domains Deletes emails that contain certain words or symbols Select emails that contain a certain word Select emails of corporative domains <http://isadatamarketing.com/isaemarketing_en_emailpacker.htm> USD 50 53-2004 <http://isadatamarketing.com/isaemarketing_en_version4.htm> Software ISA E-Marketing 4.0 Sales Management, CRM, Email Marketing, Shipping, Databases, Harvest Emails Robots <http://isadatamarketing.com/isaemarketing_en_version4.htm> Customer Management Multiple Marketing Campaigns Email Marketing Predefined Response Emails organized by campaign to accelerate the management of inquiries and direct sales Online Sales Management Sales History Shipping Management Database Management Search by Email, by Name, or by Phone Import emails from Text Files (TXT) Email Extractor from Web Pages (Manual and with Robots) Imports Web Forms generated in PHP to email (MAPI) or text files Manage Web Forms received by updating database and sending autoresponse emails. Autoresponse associated with Web Forms Database in MDB Format compatible with Microsoft Access <http://isadatamarketing.com/isaemarketing_en_version4.htm> USD 350 Email Sending Services 53-3050 <http://isadatamarketing.com/superserver_en_pedido_latam_50.htm> Super Server Plan LAT-50K <http://isadatamarketing.com/superserver_en_pedido_latam_50.htm> Sending 50.000 emails in Latinamerica, U.S. or Europe USD 60 53-3150 <http://isadatamarketing.com/superserver_en_pedido_latam.htm> Super Server Plan LAT-150K <http://isadatamarketing.com/superserver_en_pedido_latam.htm> Sending 150.000 emails in Latinamerica, U.S. or Europe USD 100 53-5002 <http://isadatamarketing.com/superserver_en_pedido_latam_1m.htm> Super Server Plan LAT-1M <http://isadatamarketing.com/superserver_en_pedido_latam_1m.htm> Sending 1 MILLION emails in Latinamerica, U.S. or Europe USD 350 Software Consulting 53-4001 <http://isadatamarketing.com/isaemarketing_us_gamma_smtprc.htm> Installation of Mailer with Scanner of Open SMTP Servers <http://isadatamarketing.com/isaemarketing_us_gamma_smtprc.htm> Configuration and support of a multi server emailing system USD 210 53-4006 <http://isadatamarketing.com/isaemarketing_us_mailer_port_587.htm> Installation of Email Marketing System with SMTP Server with SPF and DKIM <http://isadatamarketing.com/isaemarketing_us_mailer_port_587.htm> - Program installed on your computer that allows local administration of your campaigns - SMTP Servers appropriate to the rules SPF and DKIM - Online statistics - Works on Internet service providers with port 25 locked (use port 587) <http://isadatamarketing.com/isaemarketing_us_mailer_port_587.htm> USD 65 if you do not want to receive this newsletter or this emails was sent by mistake please click here <http://isadatamarketing.com/php/us_bd_rm.php> ISA Email Marketing Fabián Torre Software Consulting Rua Antonio Rodrigues 22, Itacimirim - Bahia - CEP 42823-000 - BRASIL WhatsApp: +55 719 9204-2292 - Skype: chronskype Facebook <https://www.facebook.com/isaemailmarketing/> <https://www.instagram.com/isa_email_marketing/> Instagram <http://isadatamarketing.com/logoinstagram.jpg>

1 0

[PATCH net-next v3 0/3] Some optimization for lockless qdisc
by Yunsheng Lin 24 Jun '21

24 Jun '21

Patch 1: remove unnecessary seqcount operation. Patch 2: implement TCQ_F_CAN_BYPASS. Patch 3: remove qdisc->empty. Performance data for pktgen in queue_xmit mode + dummy netdev with pfifo_fast: threads unpatched patched delta 1 2.60Mpps 3.21Mpps +23% 2 3.84Mpps 5.56Mpps +44% 4 5.52Mpps 5.58Mpps +1% 8 2.77Mpps 2.76Mpps -0.3% 16 2.24Mpps 2.23Mpps -0.4% Performance for IP forward testing: 1.05Mpps increases to 1.16Mpps, about 10% improvement. V3: Add 'Acked-by' from Jakub and 'Tested-by' from Vladimir, and resend based on latest net-next. V2: Adjust the comment and commit log according to discussion in V1. V1: Drop RFC tag, add nolock_qdisc_is_empty() and do the qdisc empty checking without the protection of qdisc->seqlock to aviod doing unnecessary spin_trylock() for contention case. RFC v4: Use STATE_MISSED and STATE_DRAINING to indicate non-empty qdisc, and add patch 1 and 3. Yunsheng Lin (3): net: sched: avoid unnecessary seqcount operation for lockless qdisc net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc net: sched: remove qdisc->empty for lockless qdisc include/net/sch_generic.h | 31 ++++++++++++++++++------------- net/core/dev.c | 27 +++++++++++++++++++++++++-- net/sched/sch_generic.c | 23 ++++++++++++++++------- 3 files changed, 59 insertions(+), 22 deletions(-) -- 2.7.4

2 4

[PATCH V2 net-next 0/3] net: hns3: add support for TX push
by Yufeng Mo 22 Jun '21

22 Jun '21

This series adds TX push support for the HNS3 ethernet driver. V1 -> V2: 1. fix compile issue on non-arm64 system in patch #2 Huazhong Tan (2): net: hns3: add support for TX push mode net: hns3: add ethtool priv-flag for TX push Xiongfeng Wang (1): arm64: barrier: add DGH macros to control memory accesses merging arch/arm64/include/asm/assembler.h | 7 ++ arch/arm64/include/asm/barrier.h | 1 + drivers/net/ethernet/hisilicon/hns3/hnae3.h | 2 + drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 86 +++++++++++++++++++++- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 6 ++ drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 21 +++++- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 2 + .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 11 ++- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 8 ++ .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 2 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 11 ++- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 8 ++ 12 files changed, 156 insertions(+), 9 deletions(-) -- 2.8.1

1 3

[PATCH net v2] net: sched: add barrier to ensure correct ordering for lockless qdisc
by Yunsheng Lin 22 Jun '21

22 Jun '21

The spin_trylock() was assumed to contain the implicit barrier needed to ensure the correct ordering between STATE_MISSED setting/clearing and STATE_MISSED checking in commit a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc"). But it turns out that spin_trylock() only has load-acquire semantic, for strongly-ordered system(like x86), the compiler barrier implicitly contained in spin_trylock() seems enough to ensure the correct ordering. But for weakly-orderly system (like arm64), the store-release semantic is needed to ensure the correct ordering as clear_bit() and test_bit() is store operation, see queued_spin_lock(). So add the explicit barrier to ensure the correct ordering for the above case. Fixes: a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc") Signed-off-by: Yunsheng Lin <linyunsheng(a)huawei.com> --- V2: add the missing Fixes tag. The above ordering issue can easily cause out of order packet problem when testing lockless qdisc bypass patchset [1] with two iperf threads and one netdev queue in arm64 system. 1. https://lkml.org/lkml/2021/6/2/1417 --- include/net/sch_generic.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h index 1e62551..5771030 100644 --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h @@ -163,6 +163,12 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) if (spin_trylock(&qdisc->seqlock)) goto nolock_empty; + /* Paired with smp_mb__after_atomic() to make sure + * STATE_MISSED checking is synchronized with clearing + * in pfifo_fast_dequeue(). + */ + smp_mb__before_atomic(); + /* If the MISSED flag is set, it means other thread has * set the MISSED flag before second spin_trylock(), so * we can return false here to avoid multi cpus doing @@ -180,6 +186,12 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) */ set_bit(__QDISC_STATE_MISSED, &qdisc->state); + /* spin_trylock() only has load-acquire semantic, so use + * smp_mb__after_atomic() to ensure STATE_MISSED is set + * before doing the second spin_trylock(). + */ + smp_mb__after_atomic(); + /* Retry again in case other CPU may not see the new flag * after it releases the lock at the end of qdisc_run_end(). */ -- 2.7.4

3 4

[PATCH net-next 0/3] net: hns3: add support for TX push
by Yufeng Mo 21 Jun '21

21 Jun '21

This series adds TX push support for the HNS3 ethernet driver. Huazhong Tan (2): net: hns3: add support for TX push mode net: hns3: add ethtool priv-flag for TX push Xiongfeng Wang (1): arm64: barrier: Add DGH macros to control memory accesses merging arch/arm64/include/asm/assembler.h | 7 ++ arch/arm64/include/asm/barrier.h | 1 + drivers/net/ethernet/hisilicon/hns3/hnae3.h | 2 + drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 82 ++++++++++++++++++++-- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 6 ++ drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 21 +++++- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 2 + .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 11 ++- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 8 +++ .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 2 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 11 ++- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 8 +++ 12 files changed, 152 insertions(+), 9 deletions(-) -- 2.8.1

3 5

by jason.smith＠lawrencefreenet.org 20 Jun '21

20 Jun '21

> From: "Iyad Mohammad al-Khatib"<jason.smith(a)lawrencefreenet.org> Subject: Dear Prospect, Date: Thu, 17 Jun 2021 03:52:40 +0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Dear Prospect, I am Mr Iyad Mohammad - Minister of Communications and Technology, and an oil and gas entrepreneur in association with state owned companies here in Syria. I am Writing to get into personal conversation with you. I have huge capital for investment in Energy and Real Estate or any other business as you may advise outside of Syria because, i was added to Syria sanctions blacklist by the European Union and i have been barned from travelling to Europe and my assets to be frozen. Other EU sanctions include an embargo on Syria oil,Investment restrictions in Syria and a freeze on Syria Central Bank assets.It was on this note that i urgently seek for your assistance to secure my assets through investment in your country. If you are eager on the proposal,Kindly get back to me so we can discuss comprehensively. Best Regards Iyad Mohammad al-Khatib.

1 0

[PATCH net-next 0/9] net: hns3: refactor and new features for flow director
by Huazhong Tan 19 Jun '21

19 Jun '21

This patchset refactor some functions and add some new features for flow director. patch 1~3: refactor large functions patch 4, 7: add traffic class and user-def field support for ethtool patch 5: use asynchronously configuration patch 6: clean up for hns3_del_all_fd_entries() patch 8, 9: add support for queue bonding mode Jian Shen (9): net: hns3: refactor out hclge_add_fd_entry() net: hns3: refactor out hclge_fd_get_tuple() net: hns3: refactor for function hclge_fd_convert_tuple net: hns3: add support for traffic class tuple support for flow director by ethtool net: hns3: refactor flow director configuration net: hns3: refine for hns3_del_all_fd_entries() net: hns3: add support for user-def data of flow director net: hns3: add support for queue bonding mode of flow director net: hns3: add queue bonding mode support for VF drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h | 8 + drivers/net/ethernet/hisilicon/hns3/hnae3.h | 9 +- drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 7 +- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 91 +- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 14 +- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 13 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 2 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 21 + .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 1570 ++++++++++++++------ .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 63 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 33 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 2 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 74 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 7 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 17 + 15 files changed, 1450 insertions(+), 481 deletions(-) -- 2.7.4

4 20

[PATCH net-next] net: fix mistake path for netdev_features_strings
by Jian Shen 18 Jun '21

18 Jun '21

Th_strings arrays netdev_features_strings, tunable_strings, and phy_tunable_strings has been moved to file net/ethtool/common.c. So fixes the comment. Signed-off-by: Jian Shen <shenjian15(a)huawei.com> --- include/linux/netdev_features.h | 2 +- include/uapi/linux/ethtool.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h index 3de38d6..2c6b9e4 100644 --- a/include/linux/netdev_features.h +++ b/include/linux/netdev_features.h @@ -93,7 +93,7 @@ enum { /* * Add your fresh new feature above and remember to update - * netdev_features_strings[] in net/core/ethtool.c and maybe + * netdev_features_strings[] in net/ethtool/common.c and maybe * some feature mask #defines below. Please also describe it * in Documentation/networking/netdev-features.rst. */ diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h index cfef6b0..67aa713 100644 --- a/include/uapi/linux/ethtool.h +++ b/include/uapi/linux/ethtool.h @@ -233,7 +233,7 @@ enum tunable_id { ETHTOOL_PFC_PREVENTION_TOUT, /* timeout in msecs */ /* * Add your fresh new tunable attribute above and remember to update - * tunable_strings[] in net/core/ethtool.c + * tunable_strings[] in net/ethtool/common.c */ __ETHTOOL_TUNABLE_COUNT, }; @@ -297,7 +297,7 @@ enum phy_tunable_id { ETHTOOL_PHY_EDPD, /* * Add your fresh new phy tunable attribute above and remember to update - * phy_tunable_strings[] in net/core/ethtool.c + * phy_tunable_strings[] in net/ethtool/common.c */ __ETHTOOL_PHY_TUNABLE_COUNT, }; -- 2.8.1

2 1

Invitation to Project Monitoring and Evaluation with Data Management and Analysis July 2021 Workshop
by Jackson From FDC-K Africa 17 Jun '21

17 Jun '21

1 0

[PATCH v7] ACPI / APEI: fix the regression of synchronous external aborts occur in user-mode
by Xiaofei Tan 17 Jun '21

17 Jun '21

Before commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work"), do_sea() would unconditionally signal the affected task from the arch code. Since that change, the GHES driver sends the signals. This exposes a problem as errors the GHES driver doesn't understand or doesn't handle effectively are silently ignored. It will cause the errors get taken again, and circulate endlessly. User-space task get stuck in this loop. Existing firmware on Kunpeng9xx systems reports cache errors with the 'ARM Processor Error' CPER records. Do memory failure handling for ARM Processor Error Section just like for Memory Error Section. Fixes: 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work") Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Reviewed-by: James Morse <james.morse(a)arm.com> --- Changes since v5: - Do some changes following James's suggestions: 1) optimize commit log 2) use err_info->length instead of err_info++' 3) some coding style advice. Changes since v4: - 1. Change the patch name from " ACPI / APEI: do memory failure on the physical address reported by ARM processor error section" to this more proper one. - 2. Add a comment in the code to tell why not filter out corrected error in an uncorrected section. Changes since v3: - Print unhandled error following James Morse's advice. Changes since v2: - Updated commit log --- drivers/acpi/apei/ghes.c | 81 ++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 64 insertions(+), 17 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index fce7ade..0c8330e 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -441,28 +441,35 @@ static void ghes_kick_task_work(struct callback_head *head) gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node, node_len); } -static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, - int sev) +static bool ghes_do_memory_failure(u64 physical_addr, int flags) { unsigned long pfn; - int flags = -1; - int sec_sev = ghes_severity(gdata->error_severity); - struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE)) return false; - if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) - return false; - - pfn = mem_err->physical_addr >> PAGE_SHIFT; + pfn = PHYS_PFN(physical_addr); if (!pfn_valid(pfn)) { pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid address in generic error data: %#llx\n", - mem_err->physical_addr); + physical_addr); return false; } + memory_failure_queue(pfn, flags); + return true; +} + +static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, + int sev) +{ + int flags = -1; + int sec_sev = ghes_severity(gdata->error_severity); + struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); + + if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) + return false; + /* iff following two events can be handled properly by now */ if (sec_sev == GHES_SEV_CORRECTED && (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED)) @@ -470,14 +477,56 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) flags = 0; - if (flags != -1) { - memory_failure_queue(pfn, flags); - return true; - } + if (flags != -1) + return ghes_do_memory_failure(mem_err->physical_addr, flags); return false; } +static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int sev) +{ + struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); + bool queued = false; + int sec_sev, i; + char *p; + + log_arm_hw_error(err); + + sec_sev = ghes_severity(gdata->error_severity); + if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE) + return false; + + p = (char *)(err + 1); + for (i = 0; i < err->err_info_num; i++) { + struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p; + bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR); + bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR); + const char *error_type = "unknown error"; + + /* + * The field (err_info->error_info & BIT(26)) is fixed to set to + * 1 in some old firmware of HiSilicon Kunpeng920. We assume that + * firmware won't mix corrected errors in an uncorrected section, + * and don't filter out 'corrected' error here. + */ + if (is_cache && has_pa) { + queued = ghes_do_memory_failure(err_info->physical_fault_addr, 0); + p += err_info->length; + continue; + } + + if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs)) + error_type = cper_proc_error_type_strs[err_info->type]; + + pr_warn_ratelimited(FW_WARN GHES_PFX + "Unhandled processor error type: %s\n", + error_type); + p += err_info->length; + } + + return queued; +} + /* * PCIe AER errors need to be sent to the AER driver for reporting and * recovery. The GHES severities map to the following AER severities and @@ -605,9 +654,7 @@ static bool ghes_do_proc(struct ghes *ghes, ghes_handle_aer(gdata); } else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) { - struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); - - log_arm_hw_error(err); + queued = ghes_handle_arm_hw_error(gdata, sev); } else { void *err = acpi_hest_get_payload(gdata); -- 2.8.1

2 3

questions about netdevice->features
by shenjian (K) 17 Jun '21

17 Jun '21

Hi, I noticed that the enum NETIF_F_XXX_BIT has already used 64 bits since NETIF_F_HW_HSR_DUP_BIT being added, while the prototype of netdev_features_t is u64. So there is no useable bit for new feature if I understand correct. Is there any solution or plan for it ? Thanks, shen jian

1 0

[PATCH net] net: sched: add barrier to ensure correct ordering for lockless qdisc
by Yunsheng Lin 16 Jun '21

16 Jun '21

The spin_trylock() is assumed to contain the implicit barrier needed to ensure the correct ordering between STATE_MISSED setting/clearing and STATE_MISSED checking in commit a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc"). But it turns out that spin_trylock() only has load-acquire semantic, for strongly-ordered system(like x86), the compiler barrier implicitly contained in spin_trylock() seems enough to ensure the correct ordering. But for weakly-orderly system (like arm64), the store-release semantic is needed to ensure the correct ordering as clear_bit() and test_bit() is store operation, see queued_spin_lock(). So add the explicit barrier to ensure the correct ordering for the above case. Signed-off-by: Yunsheng Lin <linyunsheng(a)huawei.com> --- The above ordering issue can easily cause out of order packet problem when testing lockless qdisc bypass patchset [1] with two iperf threads and one netdev queue in arm64 system. 1. https://lkml.org/lkml/2021/6/2/1417 --- include/net/sch_generic.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h index 1e62551..5771030 100644 --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h @@ -163,6 +163,12 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) if (spin_trylock(&qdisc->seqlock)) goto nolock_empty; + /* Paired with smp_mb__after_atomic() to make sure + * STATE_MISSED checking is synchronized with clearing + * in pfifo_fast_dequeue(). + */ + smp_mb__before_atomic(); + /* If the MISSED flag is set, it means other thread has * set the MISSED flag before second spin_trylock(), so * we can return false here to avoid multi cpus doing @@ -180,6 +186,12 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) */ set_bit(__QDISC_STATE_MISSED, &qdisc->state); + /* spin_trylock() only has load-acquire semantic, so use + * smp_mb__after_atomic() to ensure STATE_MISSED is set + * before doing the second spin_trylock(). + */ + smp_mb__after_atomic(); + /* Retry again in case other CPU may not see the new flag * after it releases the lock at the end of qdisc_run_end(). */ -- 2.7.4

1 0

[PATCH net-next v2 0/3] Some optimization for lockless qdisc
by Yunsheng Lin 16 Jun '21

16 Jun '21

Patch 1: remove unnecessary seqcount operation. Patch 2: implement TCQ_F_CAN_BYPASS. Patch 3: remove qdisc->empty. Performance data for pktgen in queue_xmit mode + dummy netdev with pfifo_fast: threads unpatched patched delta 1 2.60Mpps 3.21Mpps +23% 2 3.84Mpps 5.56Mpps +44% 4 5.52Mpps 5.58Mpps +1% 8 2.77Mpps 2.76Mpps -0.3% 16 2.24Mpps 2.23Mpps +0.4% Performance for IP forward testing: 1.05Mpps increases to 1.16Mpps, about 10% improvement. V2: Adjust the comment and commit log according to discussion in V1. V1: Drop RFC tag, Add nolock_qdisc_is_empty() and do the qdisc empty checking without the protection of qdisc->seqlock to aviod doing unnecessary spin_trylock() for contention case. RFC v4: Use STATE_MISSED and STATE_DRAINING to indicate non-empty qdisc, and add patch 1 and 3. Yunsheng Lin (3): net: sched: avoid unnecessary seqcount operation for lockless qdisc net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc net: sched: remove qdisc->empty for lockless qdisc include/net/sch_generic.h | 31 ++++++++++++++++++------------- net/core/dev.c | 27 +++++++++++++++++++++++++-- net/sched/sch_generic.c | 23 ++++++++++++++++------- 3 files changed, 59 insertions(+), 22 deletions(-) -- 2.7.4

3 8

[PATCH V2 net-next 0/7] net: hns3: updates for -next
by Yufeng Mo 15 Jun '21

15 Jun '21

This series includes some optimization in IO path for the HNS3 ethernet driver. --- Change log: V1 -> V2: 1. use sgt->orig_nents instead of sgt->nents in patch #5 2. fix a type mismatch issue in patch #5 Huazhong Tan (1): net: hns3: add support to query tx spare buffer size for pf Yunsheng Lin (6): net: hns3: minor refactor related to desc_cb handling net: hns3: refactor for hns3_fill_desc() function net: hns3: use tx bounce buffer for small packets net: hns3: support dma_map_sg() for multi frags skb net: hns3: optimize the rx page reuse handling process net: hns3: use bounce buffer when rx page can not be reused drivers/net/ethernet/hisilicon/hns3/hnae3.h | 8 +- drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 54 ++ drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 575 ++++++++++++++++++--- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 58 ++- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 66 +++ .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 2 + .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 14 + .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 2 + 8 files changed, 680 insertions(+), 99 deletions(-) -- 2.8.1

1 7

Re: [PATCH net-next 7/7] {topost} net: hns3: use bounce buffer when rx page can not be reused
by Salil Mehta 15 Jun '21

15 Jun '21

> From: moyufeng > Sent: Wednesday, June 2, 2021 1:13 PM > To: tanhuazhong <tanhuazhong(a)huawei.com>; shenjian (K) <shenjian15(a)huawei.com>; > lipeng (Y) <lipeng321(a)huawei.com>; Zhuangyuzeng (Yisen) > <yisen.zhuang(a)huawei.com>; linyunsheng <linyunsheng(a)huawei.com>; zhangjiaran > <zhangjiaran(a)huawei.com>; huangguangbin (A) <huangguangbin2(a)huawei.com>; > chenhao (DY) <chenhao288(a)hisilicon.com>; moyufeng <moyufeng(a)huawei.com>; Salil > Mehta <salil.mehta(a)huawei.com> > Subject: [PATCH net-next 7/7] {topost} net: hns3: use bounce buffer when rx page > can not be reused > > From: Yunsheng Lin <linyunsheng(a)huawei.com> > > Currently rx page will be reused to receive future packet when > the stack releases the previous skb quickly. If the old page > can not be reused, a new page will be allocated and mapped, > which comsumes a lot of cpu when IOMMU is in the strict mode, > especially when the application and irq/NAPI happens to run on > the same cpu. > > So allocate a new frag to memcpy the data to avoid the costly > IOMMU unmapping/mapping operation, and add "frag_alloc_err" > and "frag_alloc" stats in "ethtool -S ethX" cmd. > > The throughput improves above 50% when running single thread of > iperf using TCP when IOMMU is in strict mode and iperf shares the > same cpu with irq/NAPI(rx_copybreak = 2048 and mtu = 1500). Performance gains are quite good! Few questions: How we have ensured this will work efficiently in real world workloads and that there are no repercussions? Also, is there any impact on end-to-end *latency* or *jitter* because of this vis-a-vis without this approach? Also, have you checked why MLX5 driver has removed this copybreak concept for small packets but MLX4 did had this or why other latest drivers don't have this? Hope I have not missed this anywhere but what are the default values for both {rx,tx}_copybreak? Thanks

3 2

Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension
by Yunsheng Lin 10 Jun '21

10 Jun '21

On 2021/6/8 3:46, Jakub Kicinski wrote: > On Mon, 7 Jun 2021 09:36:38 +0800 Yunsheng Lin wrote: >> On 2021/6/5 2:41, Jakub Kicinski wrote: >>> On Fri, 4 Jun 2021 09:18:04 +0800 Yunsheng Lin wrote: >>>> My initial thinking is a id from a global IDA pool, which indeed may >>>> change on every boot. >>>> >>>> I am not really thinking much deeper about the controller id, just >>>> mirroring the bus identifiers for pcie device and ifindex for netdev, >>> >>> devlink instance id seems fine, but there's already a controller >>> concept in devlink so please steer clear of that naming. >> I am not sure if controller concept already existed is reusable for >> the devlink instance representing problem for multi-function which >> shares common resource in the same ASIC. If not, we do need to pick >> up other name. >> >> Another thing I am not really think throught is how is the VF represented >> by the devlink instance when VF is passed through to a VM. >> I was thinking about VF is represented as devlink port, just like PF(with >> different port flavour), and VF devlink port only exist on the same host >> as PF(which assumes PF is never passed through to a VM), so it may means >> the PF is responsible for creating the devlink port for VF when VF is passed >> through to a VM? >> >> Or do we need to create a devlink instance for VF in the VM too when the >> VF is passed through to a VM? Or more specificly, does user need to query >> or configure devlink info or configuration in a VM? If not, then devlink >> instance in VM seems unnecessary? > > I believe the current best practice is to create a devlink instance for > the VF with a devlink port of type "virtual". Such instance represents > a "virtualized" view of the device. Afer discussion with Parav in other thread, I undersood it was the current practice, but I am not sure I understand why it is current *best* practice. If we allow all PF of a ASCI to register to the same devlink instance, does it not make sense that all VF under one PF also register to the same devlink instance that it's PF is registering to when they are in the same host? For eswitch legacy mode, whether VF and PF are the same host or not, the VF can also provide the serial number of a ASIC to register to the devlink instance, if that devlink instance does not exist yet, just create that devlink instance according to the serial number, just like PF does. For eswitch DEVLINK_ESWITCH_MODE_SWITCHDEV mode, the flavour type for devlink port instance representing the netdev of VF function is FLAVOUR_VIRTUAL, the flavour type for devlink port instance representing the representor netdev of VF is FLAVOUR_PCI_VF, which are different type, so they can register to the same devlink instance even when both of the devlink port instance is in the same host? Is there any reason why VF use its own devlink instance? > >>>> which may change too if the device is pluged into different pci slot >>>> on every boot? >>> >>> Heh. What is someone reflashes the part to change it's serial number? :) >>> pci slot is reasonably stable, as proven by years of experience trying >>> to find stable naming for netdevs. >> >> I suppose that requires a booting to take effect and a vendor tool >> to reflash the serial number, it seems reasonable the vendor/user will >> try their best to not mess the serial number, otherwise service and >> maintenance based on serial number will not work? >> I was thinking about adding the vendor name besides the serial number >> to indicate a devlink instance, to avoid that case that two hw from >> different vendor having the same serial number accidentally. > > I'm not opposed to the use of attributes such as serial number for > selecting instance, in principle. I was just trying to prove that PCI > slot/PCI device name is as stable as any other attribute. > > In fact for mass-produced machines using PCI slot is far more > convenient than globally unique identifiers because it can be used > to talk to a specific device in a server for all machines of a given > model, hence easing automation. Make sense. > >>>> We could still allow devlink instances to have multiple names, >>>> which seems to be more like devlink tool problem? >>>> >>>> For example, devlink tool could use the id or the vendor_info/ >>>> serial_number to indicate a devlink instance according to user's >>>> request. >>> >>> Typing serial numbers seems pretty painful. >>> >>>> Aliase could be allowed too as long as devlink core provide a >>>> field and ops to set/get the field mirroring the ifalias for >>>> netdevice? >>> >>> I don't understand. >> >> I meant we could still allow the user to provide a more meaningful >> name to indicate a devlink instance besides the id. > > To clarify/summarize my statement above serial number may be a useful > addition but PCI device names should IMHO remain the primary > identifiers, even if it means devlink instances with multiple names. I am not sure I understand what does it mean by "devlink instances with multiple names"? Does that mean whenever a devlink port instance is registered to a devlink instance, that devlink instance get a new name according to the PCI device which the just registered devlink port instance corresponds to? > > In addition I don't think that user-controlled names/aliases are > necessarily a great idea for devlink. > > . >

3 14

[PATCH v6] ACPI / APEI: fix the regression of synchronous external aborts occur in user-mode
by Xiaofei Tan 10 Jun '21

10 Jun '21

Before commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work"), do_sea() would unconditionally signal the affected task from the arch code. Since that change, the GHES driver sends the signals. This exposes a problem as errors the GHES driver doesn't understand or doesn't handle effectively are silently ignored. It will cause the errors get taken again, and circulate endlessly. User-space task get stuck in this loop. Existing firmware on Kunpeng9xx systems reports cache errors with the 'ARM Processor Error' CPER records. Do memory failure handling for ARM Processor Error Section just like for Memory Error Section. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Reviewed-by: James Morse <james.morse(a)arm.com> --- Changes since v5: - Do some changes following James's suggestions: 1) optimize commit log 2) use err_info->length instead of err_info++' 3) some coding style advice. Changes since v4: - 1. Change the patch name from " ACPI / APEI: do memory failure on the physical address reported by ARM processor error section" to this more proper one. - 2. Add a comment in the code to tell why not filter out corrected error in an uncorrected section. Changes since v3: - Print unhandled error following James Morse's advice. Changes since v2: - Updated commit log --- drivers/acpi/apei/ghes.c | 81 ++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 64 insertions(+), 17 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index fce7ade..0c8330e 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -441,28 +441,35 @@ static void ghes_kick_task_work(struct callback_head *head) gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node, node_len); } -static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, - int sev) +static bool ghes_do_memory_failure(u64 physical_addr, int flags) { unsigned long pfn; - int flags = -1; - int sec_sev = ghes_severity(gdata->error_severity); - struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE)) return false; - if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) - return false; - - pfn = mem_err->physical_addr >> PAGE_SHIFT; + pfn = PHYS_PFN(physical_addr); if (!pfn_valid(pfn)) { pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid address in generic error data: %#llx\n", - mem_err->physical_addr); + physical_addr); return false; } + memory_failure_queue(pfn, flags); + return true; +} + +static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, + int sev) +{ + int flags = -1; + int sec_sev = ghes_severity(gdata->error_severity); + struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); + + if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) + return false; + /* iff following two events can be handled properly by now */ if (sec_sev == GHES_SEV_CORRECTED && (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED)) @@ -470,14 +477,56 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) flags = 0; - if (flags != -1) { - memory_failure_queue(pfn, flags); - return true; - } + if (flags != -1) + return ghes_do_memory_failure(mem_err->physical_addr, flags); return false; } +static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int sev) +{ + struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); + bool queued = false; + int sec_sev, i; + char *p; + + log_arm_hw_error(err); + + sec_sev = ghes_severity(gdata->error_severity); + if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE) + return false; + + p = (char *)(err + 1); + for (i = 0; i < err->err_info_num; i++) { + struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p; + bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR); + bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR); + const char *error_type = "unknown error"; + + /* + * The field (err_info->error_info & BIT(26)) is fixed to set to + * 1 in some old firmware of HiSilicon Kunpeng920. We assume that + * firmware won't mix corrected errors in an uncorrected section, + * and don't filter out 'corrected' error here. + */ + if (is_cache && has_pa) { + queued = ghes_do_memory_failure(err_info->physical_fault_addr, 0); + p += err_info->length; + continue; + } + + if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs)) + error_type = cper_proc_error_type_strs[err_info->type]; + + pr_warn_ratelimited(FW_WARN GHES_PFX + "Unhandled processor error type: %s\n", + error_type); + p += err_info->length; + } + + return queued; +} + /* * PCIe AER errors need to be sent to the AER driver for reporting and * recovery. The GHES severities map to the following AER severities and @@ -605,9 +654,7 @@ static bool ghes_do_proc(struct ghes *ghes, ghes_handle_aer(gdata); } else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) { - struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); - - log_arm_hw_error(err); + queued = ghes_handle_arm_hw_error(gdata, sev); } else { void *err = acpi_hest_get_payload(gdata); -- 2.8.1

2 2

Re: [PATCH RESEND iproute2-next] devlink: Add optional controller user input
by Yunsheng Lin 09 Jun '21

09 Jun '21

On 2021/6/7 14:10, Parav Pandit wrote: >> From: Yunsheng Lin <linyunsheng(a)huawei.com> >> Sent: Monday, June 7, 2021 9:01 AM >> >> On 2021/6/6 15:10, Parav Pandit wrote: >>> Hi Yunsheng, >>> >>>> From: Yunsheng Lin <linyunsheng(a)huawei.com> >>>> Sent: Friday, June 4, 2021 7:05 AM >>>> >>>> On 2021/6/3 19:19, Parav Pandit wrote: >>>>> A user optionally provides the external controller number when user >>>>> wants to create devlink port for the external controller. >>>> >>>> Hi, Parav >>>> I was planing to use controller id to solve the devlink instance >>>> representing problem for multi-function which shares common resource >>>> in the same ASIC, see [1]. >>>> >>>> It seems the controller id used here is to differentiate the function >>>> used in different host? >>>> >>> That’s correct. Controller holds one or more PCI functions (PF,VF,SF). >> >> I am not sure I understand the exact usage of controller and why controller id >> is in "devlink_port_*_attrs". >> >> Let's consider a simplified case where there is two PF(supposing both have >> VF enabled), and each PF has different controller and each PF corresponds to >> a different physical port(Or it is about multi-host case multi PF may sharing >> the same physical port?): > Typically single host with two PFs have their own physical ports. > Multi-host with two PFs, on each host they share respective physical ports. > > Single host: > Pf0.physical_port = p0 > Pf1.physical_port = p1. > > Multi-host (two) host setup > H1.pf0.phyical_port = p0. > H1.pf1.phyical_port = p1. > H2.pf0.phyical_port = p0. > H2.pf1.phyical_port = p1. Multi-host (two) host setup with separate physical port for each host: H1.pf0.phyical_port = p0 H2.pf0.phyical_port = p1 Does above use case make sense for mlx, it seems a common case for our internal use. > >> 1. I suppose each PF has it's devlink instance for mlx case(I suppose each >> VF can not have it's own devlink instance for VF shares the same physical >> port with PF, right?). > VF and SF ports are of flavour VIRTUAL. Which devlink instance does the flavour VIRTUAL port instance for VF and SF is registered to? Does it mean VF has it's own devlink instance in VM when it is passed a VM, and flavour VIRTUAL port instance for that VF is registered to that devlink instance in the VM too？ Even in the same host as PF, the VF also has it's own devlink instance? > >> 2. each PF's devlink instance has three types of port, which is >> FLAVOUR_PHYSICAL, FLAVOUR_PCI_PF and FLAVOUR_PCI_VF(supposing I >> understand >> port flavour correctly). >> > FLAVOUR_PCI_{PF,VF,SF} belongs to eswitch (representor) side on switchdev device. If devlink instance or eswitch is in DEVLINK_ESWITCH_MODE_LEGACY mode, the FLAVOUR_PCI_{PF,VF,SF} port instance does not need to created? > >> If I understand above correctly, all ports in the same devlink instance should >> have the same controller id, right? If yes, why not put the controller id in the >> devlink instance? > Need not be. All PCI_{PF,VF,SF} can have controller id different for different controllers. The point is that two VF from different PF may be in the different host, all VF of a specific PF need to be in the same host, right? otherwise it may break PCI enumeration process? If yes, as PCI_{PF,VF,SF} belongs to eswitch (representor) side on switchdev device(which means PCI_{PF,VF,SF} port instance is in the same host, as the host corresponding to "controller_num=0" in diagram [1]), so it seems all the PCI_{PF,VF,SF} of a specific PF should have the same controller id, and using a controller id of the devlink instance in "controller_num=0" in diagram [1] seems enough? > Usually each multi-host is a different controller. > Refer to this diagram [1] and detailed description. devlink instance does not exist in the host corresponding to "controller_num=1" in diagram [1]? Or devlink instance does exist in the host corresponding to "controller_num=1", but the mode of that devlink instance is DEVLINK_ESWITCH_MODE_LEGACY in diagram [1]? Also, eswitch mode can only be set on the devlink instance corresponding to PF, but not for VF/SF(supposing that VF/SF could have it's own devlink instance too), right? > >> >>> In your case if there is single devlink instance representing ASIC, it is better >> to have health reporters under this single instance. >>> >>> Devlink parameters do not span multiple devlink instance. >> >> Yes, that is what I try to do: shared status/parameters in devlink instance, >> physical port specific status/parameters in devlink port instance. >> >>> So if you need to control devlink instance parameters of each function >> byitself, you likely need devlink instance for each. >>> And still continue to have ASIC wide health reporters under single instance >> that represents whole ASIC. >> >> I do not think each function need a devlink instance if there is a devlink >> instance representing a whole ASIC, using the devlink port instance to >> represent the function seems enough? > 'devlink port function's is equivalent of hypervisor/nicvisor entity controlled by the network/sysadmin. > While devlink instance of a given PF,VF,SF is managed by the user of such function itself. 'devlink port function' means "struct devlink_port", right? It seems 'devlink port function' in the host is representing a VF when devlink instance of that VF is in the VM? > For example when a VF is mapped to a VM, devlink instance of this VF resides in the VM managed by the guest VM. Does the user in VM really care about devlink info or configuration when network/sysadmin has configured the VF through 'devlink port function' in the host? which devlink info or configuration does user need to query or configure in a VM? > > Before this VF is given to VM, usually hypervisor/nicvisor admin programs this function (such as mac address) explained in [3]. > So that a given VM always gets the same mac address regardless of which VF {a or b). > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… > [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… > >> >>> >>>> 1. https://lkml.org/lkml/2021/5/31/296 >

2 9

[PATCH 0/4] Free cached iovas when rmmod the driver of the last device in group
by chenxiang 08 Jun '21

08 Jun '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> When rmmod the driver of the last device in the group, cached iovas are not used, and it is better to free them to save memories. And also export function free_rcache_cached_iovas() and iommu_domain_to_iova(). Xiang Chen (4): iommu/iova: add a function to free all rcached iovas and export it iommu/iova: use function free_rcache_cached_iovas() to free all rcached iovas dma-iommu: add a interface to get iova_domain from iommu domain iommu: free cached iovas when rmmod the driver of the last device in the group drivers/iommu/dma-iommu.c | 7 +++++++ drivers/iommu/iommu.c | 7 +++++++ drivers/iommu/iova.c | 17 ++++++++++++----- include/linux/dma-iommu.h | 6 ++++++ include/linux/iova.h | 5 +++++ 5 files changed, 37 insertions(+), 5 deletions(-) -- 2.8.1

3 7

[PATCH v6] ACPI / APEI: fix the regression of synchronous external aborts occur in user-mode
by Xiaofei Tan 08 Jun '21

08 Jun '21

Before commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work"), do_sea() would unconditionally signal the affected task from the arch code. Since that change, the GHES driver sends the signals. This exposes a problem as errors the GHES driver doesn't understand or doesn't handle effectively are silently ignored. It will cause the errors get taken again, and circulate endlessly. User-space task get stuck in this loop. Existing firmware on Kunpeng9xx systems reports cache errors with the 'ARM Processor Error' CPER records. Do memory failure handling for ARM Processor Error Section just like for Memory Error Section. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Reviewed-by: James Morse <james.morse(a)arm.com> --- Changes since v5: - Do some changes following James's suggestions: 1) optimize commit log 2) use err_info->length instead of err_info++' 3) some coding style advice. Changes since v4: - 1. Change the patch name from " ACPI / APEI: do memory failure on the physical address reported by ARM processor error section" to this more proper one. - 2. Add a comment in the code to tell why not filter out corrected error in an uncorrected section. Changes since v3: - Print unhandled error following James Morse's advice. Changes since v2: - Updated commit log --- drivers/acpi/apei/ghes.c | 81 ++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 64 insertions(+), 17 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index fce7ade..0c8330e 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -441,28 +441,35 @@ static void ghes_kick_task_work(struct callback_head *head) gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node, node_len); } -static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, - int sev) +static bool ghes_do_memory_failure(u64 physical_addr, int flags) { unsigned long pfn; - int flags = -1; - int sec_sev = ghes_severity(gdata->error_severity); - struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE)) return false; - if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) - return false; - - pfn = mem_err->physical_addr >> PAGE_SHIFT; + pfn = PHYS_PFN(physical_addr); if (!pfn_valid(pfn)) { pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid address in generic error data: %#llx\n", - mem_err->physical_addr); + physical_addr); return false; } + memory_failure_queue(pfn, flags); + return true; +} + +static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, + int sev) +{ + int flags = -1; + int sec_sev = ghes_severity(gdata->error_severity); + struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); + + if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) + return false; + /* iff following two events can be handled properly by now */ if (sec_sev == GHES_SEV_CORRECTED && (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED)) @@ -470,14 +477,56 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) flags = 0; - if (flags != -1) { - memory_failure_queue(pfn, flags); - return true; - } + if (flags != -1) + return ghes_do_memory_failure(mem_err->physical_addr, flags); return false; } +static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int sev) +{ + struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); + bool queued = false; + int sec_sev, i; + char *p; + + log_arm_hw_error(err); + + sec_sev = ghes_severity(gdata->error_severity); + if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE) + return false; + + p = (char *)(err + 1); + for (i = 0; i < err->err_info_num; i++) { + struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p; + bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR); + bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR); + const char *error_type = "unknown error"; + + /* + * The field (err_info->error_info & BIT(26)) is fixed to set to + * 1 in some old firmware of HiSilicon Kunpeng920. We assume that + * firmware won't mix corrected errors in an uncorrected section, + * and don't filter out 'corrected' error here. + */ + if (is_cache && has_pa) { + queued = ghes_do_memory_failure(err_info->physical_fault_addr, 0); + p += err_info->length; + continue; + } + + if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs)) + error_type = cper_proc_error_type_strs[err_info->type]; + + pr_warn_ratelimited(FW_WARN GHES_PFX + "Unhandled processor error type: %s\n", + error_type); + p += err_info->length; + } + + return queued; +} + /* * PCIe AER errors need to be sent to the AER driver for reporting and * recovery. The GHES severities map to the following AER severities and @@ -605,9 +654,7 @@ static bool ghes_do_proc(struct ghes *ghes, ghes_handle_aer(gdata); } else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) { - struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); - - log_arm_hw_error(err); + queued = ghes_handle_arm_hw_error(gdata, sev); } else { void *err = acpi_hest_get_payload(gdata); -- 2.8.1

1 0

[PATCH v6 1/1] ACPI / APEI: fix the regression of synchronous external aborts occur in user-mode
by Xiaofei Tan 08 Jun '21

08 Jun '21

Before commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work"), do_sea() would unconditionally signal the affected task from the arch code. Since that change, the GHES driver sends the signals. This exposes a problem as errors the GHES driver doesn't understand or doesn't handle effectively are silently ignored. It will cause the errors get taken again, and circulate endlessly. User-space task get stuck in this loop. Existing firmware on Kunpeng9xx systems reports cache errors with the 'ARM Processor Error' CPER records. Do memory failure handling for ARM Processor Error Section just like for Memory Error Section. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Reviewed-by: James Morse <james.morse(a)arm.com> --- Chnages since v5: - Do some changes following James's suggestions: 1) optimize commit log 2) check error info length 3) some coding style advices. Changes since v4: - 1. Change the patch name from " ACPI / APEI: do memory failure on the physical address reported by ARM processor error section" to this more proper one. - 2. Add a comment in the code to tell why not filter out corrected error in an uncorrected section. Changes since v3: - Print unhandled error following James Morse's advice. Changes since v2: - Updated commit log --- drivers/acpi/apei/ghes.c | 85 ++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 68 insertions(+), 17 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index fce7ade..da25870 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -441,28 +441,35 @@ static void ghes_kick_task_work(struct callback_head *head) gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node, node_len); } -static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, - int sev) +static bool ghes_do_memory_failure(u64 physical_addr, int flags) { unsigned long pfn; - int flags = -1; - int sec_sev = ghes_severity(gdata->error_severity); - struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE)) return false; - if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) - return false; - - pfn = mem_err->physical_addr >> PAGE_SHIFT; + pfn = PHYS_PFN(physical_addr); if (!pfn_valid(pfn)) { pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid address in generic error data: %#llx\n", - mem_err->physical_addr); + physical_addr); return false; } + memory_failure_queue(pfn, flags); + return true; +} + +static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, + int sev) +{ + int flags = -1; + int sec_sev = ghes_severity(gdata->error_severity); + struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); + + if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) + return false; + /* iff following two events can be handled properly by now */ if (sec_sev == GHES_SEV_CORRECTED && (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED)) @@ -470,14 +477,60 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) flags = 0; - if (flags != -1) { - memory_failure_queue(pfn, flags); - return true; - } + if (flags != -1) + return ghes_do_memory_failure(mem_err->physical_addr, flags); return false; } +static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int sev) +{ + struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); + struct cper_arm_err_info *err_info; + bool queued = false; + int sec_sev, i; + + log_arm_hw_error(err); + + sec_sev = ghes_severity(gdata->error_severity); + if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE) + return false; + + err_info = (struct cper_arm_err_info *)(err + 1); + for (i = 0; i < err->err_info_num; i++, err_info++) { + bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR); + bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR); + const char *error_type = "unknown error"; + + if (err_info->length != sizeof(struct cper_arm_err_info)) { + pr_warn_ratelimited(FW_WARN GHES_PFX + "Error info length %d is invalid\n", + err_info->length); + break; + } + + /* + * The field (err_info->error_info & BIT(26)) is fixed to set to + * 1 in some old firmware of HiSilicon Kunpeng920. We assume that + * firmware won't mix corrected errors in an uncorrected section, + * and don't filter out 'corrected' error here. + */ + if (is_cache && has_pa) { + queued = ghes_do_memory_failure(err_info->physical_fault_addr, 0); + continue; + } + + if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs)) + error_type = cper_proc_error_type_strs[err_info->type]; + + pr_warn_ratelimited(FW_WARN GHES_PFX + "Unhandled processor error type: %s\n", + error_type); + } + + return queued; +} + /* * PCIe AER errors need to be sent to the AER driver for reporting and * recovery. The GHES severities map to the following AER severities and @@ -605,9 +658,7 @@ static bool ghes_do_proc(struct ghes *ghes, ghes_handle_aer(gdata); } else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) { - struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); - - log_arm_hw_error(err); + queued = ghes_handle_arm_hw_error(gdata, sev); } else { void *err = acpi_hest_get_payload(gdata); -- 2.8.1

2 2

[RESEND PATCH v3] iommu/iova: put free_iova_mem() outside of spinlock iova_rbtree_lock
by chenxiang 04 Jun '21

04 Jun '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> It is not necessary to put free_iova_mem() inside of spinlock/unlock iova_rbtree_lock which only leads to more completion for the spinlock. It has a small promote on the performance after the change. And also rename private_free_iova() as remove_iova() because the function will not free iova after that change. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> Reviewed-by: John Garry <john.garry(a)huawei.com> --- drivers/iommu/iova.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c index b7ecd5b..b6cf5f1 100644 --- a/drivers/iommu/iova.c +++ b/drivers/iommu/iova.c @@ -412,12 +412,11 @@ private_find_iova(struct iova_domain *iovad, unsigned long pfn) return NULL; } -static void private_free_iova(struct iova_domain *iovad, struct iova *iova) +static void remove_iova(struct iova_domain *iovad, struct iova *iova) { assert_spin_locked(&iovad->iova_rbtree_lock); __cached_rbnode_delete_update(iovad, iova); rb_erase(&iova->node, &iovad->rbroot); - free_iova_mem(iova); } /** @@ -452,8 +451,9 @@ __free_iova(struct iova_domain *iovad, struct iova *iova) unsigned long flags; spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); - private_free_iova(iovad, iova); + remove_iova(iovad, iova); spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); + free_iova_mem(iova); } EXPORT_SYMBOL_GPL(__free_iova); @@ -472,10 +472,13 @@ free_iova(struct iova_domain *iovad, unsigned long pfn) spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); iova = private_find_iova(iovad, pfn); - if (iova) - private_free_iova(iovad, iova); + if (!iova) { + spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); + return; + } + remove_iova(iovad, iova); spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); - + free_iova_mem(iova); } EXPORT_SYMBOL_GPL(free_iova); @@ -825,7 +828,8 @@ iova_magazine_free_pfns(struct iova_magazine *mag, struct iova_domain *iovad) if (WARN_ON(!iova)) continue; - private_free_iova(iovad, iova); + remove_iova(iovad, iova); + free_iova_mem(iova); } spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); -- 2.8.1

3 2

[PATCH net-next 0/3] Some optimization for lockless qdisc
by Yunsheng Lin 03 Jun '21

03 Jun '21

Patch 1: remove unnecessary seqcount operation. Patch 2: implement TCQ_F_CAN_BYPASS. Patch 3: remove qdisc->empty. Performance data for pktgen in queue_xmit mode + dummy netdev with pfifo_fast: threads unpatched patched delta 1 2.60Mpps 3.21Mpps +23% 2 3.84Mpps 5.56Mpps +44% 4 5.52Mpps 5.58Mpps +1% 8 2.77Mpps 2.76Mpps -0.3% 16 2.24Mpps 2.23Mpps +0.4% Performance for IP forward testing: 1.05Mpps increases to 1.16Mpps, about 10% improvement. V1: Drop RFC tag, Add nolock_qdisc_is_empty() and do the qdisc empty checking without the protection of qdisc->seqlock to aviod doing unnecessary spin_trylock() for contention case. RFC v4: Use STATE_MISSED and STATE_DRAINING to indicate non-empty qdisc, and add patch 1 and 3. Yunsheng Lin (3): net: sched: avoid unnecessary seqcount operation for lockless qdisc net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc net: sched: remove qdisc->empty for lockless qdisc include/net/sch_generic.h | 31 ++++++++++++++++++------------- net/core/dev.c | 26 ++++++++++++++++++++++++-- net/sched/sch_generic.c | 23 ++++++++++++++++------- 3 files changed, 58 insertions(+), 22 deletions(-) -- 2.7.4

3 18

[PATCH v2 0/3] use bin_attribute to avoid buff overflow
by Tian Tao 02 Jun '21

02 Jun '21

patch #1 adds a new function cpumap_print_to_buf and patch #2 uses this function in drivers/base/topology.c, and patch #3 uses this new function in drivers/base/node.c. v2: split the original patch #1 into two patches and use kasprintf() in patch #1 to simplify the code. do some minor formatting adjustments Tian Tao (3): lib: bitmap: introduce bitmap_print_to_buf topology: use bin_attribute to avoid buff overflow drivers/base/node.c: use bin_attribute to avoid buff overflow drivers/base/node.c | 52 ++++++++++++++-------- drivers/base/topology.c | 115 ++++++++++++++++++++++++++---------------------- include/linux/bitmap.h | 3 ++ include/linux/cpumask.h | 21 +++++++++ lib/bitmap.c | 38 +++++++++++++++- 5 files changed, 157 insertions(+), 72 deletions(-) -- 2.7.4

2 4

[RFC v2 plinth/topic-sas-5.12 0/6] Add support for IOMMU debugfs related to
by chenxiang 02 Jun '21

02 Jun '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> The first patch is to release those rcache when rmmod the driver of the last device to save memory. And patch2~6 is add support for IOMMU debugfs related to IOVA as follows: /sys/kernel/debug/iommu/iovad/iommu_domainx Under iommu_domainx dir, add debugfs file iova_rcache and drop_rcache. From debugfs file iova_rcache, we can get how many cpu_rcache / share rcache / iovas are used, and also we can drop those rcache by debugfs file drop_rcache: For cpu_rcache, [i]=x|y indicates that there are x iova in load iova_magazine and y iova in prev iova_magazine (128 at most). For share rcache, [i]=x indicates that there are x iova_magazines in use. estuary:/sys/kernel/debug/iommu/iovad/iommu_domain2$ cat iova_rcache [ 272.814457] cpu0 [0]=60|0 [1]=7|0 [2]=32|0 [3]=0|0 [4]=97|0 [5]=104|0 [ 272.820982] cpu1 [0]=0|0 [1]=3|0 [2]=14|0 [3]=76|0 [4]=15|0 [5]=64|0 [ 272.827399] cpu2 [0]=85|128 [1]=84|128 [2]=83|128 [3]=112|128 [4]=22|128 [5]=116|128 [ 272.835197] cpu3 [0]=0|0 [1]=91|0 [2]=101|0 [3]=29|0 [4]=0|0 [5]=36|0 [ 272.841699] cpu4 [0]=0|0 [1]=39|0 [2]=113|0 [3]=75|0 [4]=95|0 [5]=0|0 [ 272.848201] cpu5 [0]=27|0 [1]=48|0 [2]=82|0 [3]=0|0 [4]=19|0 [5]=36|0 [ 272.854702] cpu6 [0]=30|0 [1]=0|0 [2]=48|0 [3]=2|0 [4]=18|0 [5]=56|0 [ 272.861117] cpu7 [0]=27|0 [1]=89|0 [2]=101|0 [3]=59|0 [4]=28|0 [5]=0|0 [ 272.867706] cpu8 [0]=66|0 [1]=114|0 [2]=42|0 [3]=123|0 [4]=96|0 [5]=68|0 [ 272.874466] cpu9 [0]=71|0 [1]=61|0 [2]=28|0 [3]=118|0 [4]=116|0 [5]=41|0 [ 272.881227] cpu10 [0]=83|128 [1]=63|128 [2]=109|128 [3]=79|128 [4]=7|128 [5]=54|128 [ 272.888938] cpu11 [0]=90|0 [1]=34|0 [2]=88|0 [3]=58|0 [4]=20|0 [5]=35|0 [ 272.895611] cpu12 [0]=64|0 [1]=20|0 [2]=18|0 [3]=33|0 [4]=42|0 [5]=22|0 [ 272.902285] cpu13 [0]=17|0 [1]=70|0 [2]=115|0 [3]=59|0 [4]=108|0 [5]=58|0 [ 272.909132] cpu14 [0]=28|0 [1]=18|0 [2]=27|0 [3]=105|0 [4]=65|0 [5]=81|0 [ 272.915892] cpu15 [0]=75|0 [1]=3|0 [2]=73|0 [3]=104|0 [4]=127|0 [5]=102|0 [ 272.922738] cpu16 [0]=54|0 [1]=116|0 [2]=90|0 [3]=31|0 [4]=108|0 [5]=41|0 [ 272.929590] cpu17 [0]=47|0 [1]=82|0 [2]=3|0 [3]=66|0 [4]=68|0 [5]=66|0 [ 272.936179] cpu18 [0]=126|128 [1]=110|128 [2]=48|128 [3]=118|128 [4]=54|128 [5]=73|128 [ 272.944156] cpu19 [0]=31|0 [1]=13|0 [2]=104|0 [3]=45|0 [4]=108|0 [5]=96|0 [ 272.951006] cpu20 [0]=58|0 [1]=113|0 [2]=14|0 [3]=123|0 [4]=52|0 [5]=54|0 [ 272.957856] cpu21 [0]=116|0 [1]=47|0 [2]=96|0 [3]=60|0 [4]=47|0 [5]=126|0 [ 272.964701] cpu22 [0]=84|0 [1]=87|0 [2]=88|0 [3]=68|0 [4]=37|0 [5]=119|0 [ 272.971462] cpu23 [0]=13|0 [1]=63|0 [2]=124|0 [3]=3|0 [4]=7|0 [5]=38|0 [ 272.978051] cpu24 [0]=15|0 [1]=64|0 [2]=65|0 [3]=53|0 [4]=102|0 [5]=69|0 [ 272.984812] cpu25 [0]=94|0 [1]=108|0 [2]=67|0 [3]=125|0 [4]=107|0 [5]=8|0 [ 272.991663] cpu26 [0]=84|128 [1]=86|128 [2]=91|128 [3]=121|128 [4]=77|128 [5]=25|128 [ 272.999464] cpu27 [0]=60|0 [1]=105|0 [2]=61|0 [3]=91|0 [4]=79|0 [5]=6|0 [ 273.006141] cpu28 [0]=39|0 [1]=91|0 [2]=11|0 [3]=87|0 [4]=112|0 [5]=10|0 [ 273.012904] cpu29 [0]=88|0 [1]=43|0 [2]=0|0 [3]=77|0 [4]=10|0 [5]=79|0 [ 273.019492] cpu30 [0]=65|0 [1]=24|0 [2]=125|0 [3]=24|0 [4]=54|0 [5]=21|0 [ 273.026254] cpu31 [0]=26|0 [1]=90|0 [2]=42|0 [3]=17|0 [4]=73|0 [5]=35|0 [ 273.032929] cpu32 [0]=1|0 [1]=83|0 [2]=76|0 [3]=62|0 [4]=117|0 [5]=96|0 [ 273.039612] cpu33 [0]=50|0 [1]=55|0 [2]=63|0 [3]=79|0 [4]=86|0 [5]=15|0 [ 273.046293] cpu34 [0]=122|128 [1]=36|128 [2]=36|128 [3]=79|128 [4]=113|128 [5]=80|128 [ 273.054179] cpu35 [0]=101|0 [1]=18|0 [2]=7|0 [3]=10|0 [4]=7|0 [5]=112|0 [ 273.060854] cpu36 [0]=12|0 [1]=107|0 [2]=43|0 [3]=60|0 [4]=19|0 [5]=110|0 [ 273.067703] cpu37 [0]=90|0 [1]=34|0 [2]=66|0 [3]=91|0 [4]=85|0 [5]=31|0 [ 273.074378] cpu38 [0]=0|0 [1]=22|0 [2]=18|0 [3]=73|0 [4]=54|0 [5]=96|0 [ 273.080968] cpu39 [0]=109|0 [1]=54|0 [2]=124|0 [3]=21|0 [4]=88|0 [5]=61|0 [ 273.087816] cpu40 [0]=95|0 [1]=50|0 [2]=45|0 [3]=66|0 [4]=30|0 [5]=84|0 [ 273.094490] cpu41 [0]=99|0 [1]=47|0 [2]=8|0 [3]=81|0 [4]=0|0 [5]=95|0 [ 273.100992] cpu42 [0]=25|128 [1]=92|128 [2]=53|128 [3]=49|128 [4]=43|128 [5]=78|128 [ 273.108704] cpu43 [0]=88|0 [1]=42|0 [2]=10|0 [3]=124|0 [4]=4|0 [5]=105|0 [ 273.115464] cpu44 [0]=80|0 [1]=63|0 [2]=1|0 [3]=123|0 [4]=35|0 [5]=17|0 [ 273.122139] cpu45 [0]=31|0 [1]=92|0 [2]=8|0 [3]=60|0 [4]=74|0 [5]=92|0 [ 273.128727] cpu46 [0]=78|0 [1]=40|0 [2]=95|0 [3]=33|0 [4]=67|0 [5]=63|0 [ 273.135401] cpu47 [0]=112|0 [1]=93|0 [2]=96|0 [3]=24|0 [4]=93|0 [5]=15|0 [ 273.142162] cpu48 [0]=92|0 [1]=120|0 [2]=49|0 [3]=118|0 [4]=1|0 [5]=83|0 [ 273.148923] cpu49 [0]=101|0 [1]=7|0 [2]=108|0 [3]=15|0 [4]=69|0 [5]=116|0 [ 273.155771] cpu50 [0]=111|128 [1]=98|128 [2]=21|128 [3]=27|128 [4]=109|128 [5]=21|128 [ 273.163655] cpu51 [0]=31|0 [1]=33|0 [2]=82|0 [3]=117|0 [4]=98|0 [5]=1|0 [ 273.170329] cpu52 [0]=113|0 [1]=64|0 [2]=16|0 [3]=48|0 [4]=97|0 [5]=80|0 [ 273.177090] cpu53 [0]=95|0 [1]=39|0 [2]=26|0 [3]=107|0 [4]=2|0 [5]=18|0 [ 273.183764] cpu54 [0]=114|0 [1]=94|0 [2]=110|0 [3]=85|0 [4]=66|0 [5]=45|0 [ 273.190611] cpu55 [0]=52|0 [1]=89|0 [2]=43|0 [3]=117|0 [4]=115|0 [5]=91|0 [ 273.197460] cpu56 [0]=0|0 [1]=51|0 [2]=81|0 [3]=60|0 [4]=20|0 [5]=27|0 [ 273.204048] cpu57 [0]=124|0 [1]=121|0 [2]=56|0 [3]=0|0 [4]=77|0 [5]=59|0 [ 273.210807] cpu58 [0]=109|128 [1]=98|128 [2]=6|128 [3]=39|128 [4]=64|128 [5]=24|128 [ 273.218518] cpu59 [0]=57|0 [1]=62|0 [2]=66|0 [3]=55|0 [4]=95|0 [5]=47|0 [ 273.225192] cpu60 [0]=29|0 [1]=12|0 [2]=112|0 [3]=23|0 [4]=65|0 [5]=34|0 [ 273.231955] cpu61 [0]=92|0 [1]=5|0 [2]=19|0 [3]=91|0 [4]=101|0 [5]=97|0 [ 273.238629] cpu62 [0]=97|0 [1]=42|0 [2]=30|0 [3]=111|0 [4]=99|0 [5]=2|0 [ 273.245304] cpu63 [0]=77|0 [1]=79|0 [2]=62|0 [3]=56|0 [4]=17|0 [5]=76|0 [ 273.251982] cpu64 [0]=0|0 [1]=108|0 [2]=87|0 [3]=58|0 [4]=26|0 [5]=0|0 [ 273.258582] cpu65 [0]=0|0 [1]=114|0 [2]=99|0 [3]=73|0 [4]=33|0 [5]=0|0 [ 273.265174] cpu66 [0]=39|128 [1]=52|128 [2]=82|128 [3]=107|128 [4]=73|128 [5]=13|128 [ 273.272974] cpu67 [0]=0|0 [1]=123|0 [2]=87|0 [3]=49|0 [4]=27|0 [5]=98|0 [ 273.279651] cpu68 [0]=108|0 [1]=0|0 [2]=123|0 [3]=47|0 [4]=30|0 [5]=109|0 [ 273.286500] cpu69 [0]=92|0 [1]=110|0 [2]=92|0 [3]=59|0 [4]=42|0 [5]=104|0 [ 273.293351] cpu70 [0]=105|0 [1]=106|0 [2]=99|0 [3]=57|0 [4]=15|0 [5]=111|0 [ 273.300287] cpu71 [0]=106|0 [1]=108|0 [2]=108|0 [3]=58|0 [4]=35|0 [5]=98|0 [ 273.307222] cpu72 [0]=0|0 [1]=0|0 [2]=114|0 [3]=118|0 [4]=95|0 [5]=0|0 [ 273.313813] cpu73 [0]=0|0 [1]=0|0 [2]=0|0 [3]=98|0 [4]=95|0 [5]=124|0 [ 273.320318] cpu74 [0]=65|0 [1]=76|0 [2]=109|0 [3]=58|128 [4]=115|128 [5]=105|0 [ 273.327603] cpu75 [0]=0|0 [1]=0|0 [2]=123|0 [3]=102|0 [4]=109|0 [5]=0|0 [ 273.334279] cpu76 [0]=125|0 [1]=0|0 [2]=0|0 [3]=101|0 [4]=112|0 [5]=0|0 [ 273.340954] cpu77 [0]=124|0 [1]=124|0 [2]=0|0 [3]=103|0 [4]=100|0 [5]=0|0 [ 273.347803] cpu78 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=118|0 [5]=0|0 [ 273.354134] cpu79 [0]=124|0 [1]=0|0 [2]=116|0 [3]=104|0 [4]=120|0 [5]=0|0 [ 273.360981] cpu80 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.367138] cpu81 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.373292] cpu82 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.379447] cpu83 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.385601] cpu84 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.391755] cpu85 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.397910] cpu86 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.404065] cpu87 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.410220] cpu88 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.416376] cpu89 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.422532] cpu90 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.428687] cpu91 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.434841] cpu92 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.440997] cpu93 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.447152] cpu94 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.453311] cpu95 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 273.459468] cpu96 [0]=78|0 [1]=95|0 [2]=117|0 [3]=120|0 [4]=37|0 [5]=31|0 [ 273.466317] cpu97 [0]=105|0 [1]=99|0 [2]=37|0 [3]=24|0 [4]=86|0 [5]=39|0 [ 273.473080] cpu98 [0]=37|128 [1]=13|128 [2]=102|128 [3]=124|128 [4]=60|128 [5]=36|128 [ 273.480967] cpu99 [0]=69|0 [1]=12|0 [2]=84|0 [3]=49|0 [4]=108|0 [5]=127|0 [ 273.487818] cpu100 [0]=92|0 [1]=104|0 [2]=22|0 [3]=31|0 [4]=2|0 [5]=72|0 [ 273.494581] cpu101 [0]=0|0 [1]=31|0 [2]=44|0 [3]=8|0 [4]=13|0 [5]=50|0 [ 273.501170] cpu102 [0]=79|0 [1]=14|0 [2]=88|0 [3]=53|0 [4]=7|0 [5]=44|0 [ 273.507846] cpu103 [0]=10|0 [1]=117|0 [2]=53|0 [3]=112|0 [4]=11|0 [5]=71|0 [ 273.514781] cpu104 [0]=123|0 [1]=30|0 [2]=9|0 [3]=2|0 [4]=30|0 [5]=24|0 [ 273.521462] cpu105 [0]=116|0 [1]=44|0 [2]=29|0 [3]=104|0 [4]=71|0 [5]=3|0 [ 273.528309] cpu106 [0]=38|128 [1]=127|128 [2]=21|128 [3]=83|128 [4]=59|128 [5]=81|128 [ 273.536195] cpu107 [0]=127|0 [1]=126|0 [2]=125|0 [3]=79|0 [4]=12|0 [5]=115|0 [ 273.543303] cpu108 [0]=0|0 [1]=43|0 [2]=111|0 [3]=10|0 [4]=51|0 [5]=68|0 [ 273.550065] cpu109 [0]=37|0 [1]=63|0 [2]=11|0 [3]=10|0 [4]=58|0 [5]=9|0 [ 273.556742] cpu110 [0]=86|0 [1]=44|0 [2]=83|0 [3]=85|0 [4]=82|0 [5]=119|0 [ 273.563590] cpu111 [0]=114|0 [1]=27|0 [2]=111|0 [3]=11|0 [4]=45|0 [5]=56|0 [ 273.570524] cpu112 [0]=74|0 [1]=86|0 [2]=93|0 [3]=122|0 [4]=126|0 [5]=31|0 [ 273.577458] cpu113 [0]=51|0 [1]=81|0 [2]=7|0 [3]=124|0 [4]=71|0 [5]=5|0 [ 273.584133] cpu114 [0]=58|128 [1]=95|128 [2]=14|128 [3]=119|128 [4]=85|128 [5]=23|128 [ 273.592018] cpu115 [0]=59|0 [1]=66|0 [2]=1|0 [3]=50|0 [4]=77|0 [5]=6|0 [ 273.598607] cpu116 [0]=65|0 [1]=81|0 [2]=22|0 [3]=18|0 [4]=96|0 [5]=2|0 [ 273.605282] cpu117 [0]=23|0 [1]=41|0 [2]=19|0 [3]=69|0 [4]=108|0 [5]=126|0 [ 273.612216] cpu118 [0]=74|0 [1]=40|0 [2]=0|0 [3]=100|0 [4]=109|0 [5]=7|0 [ 273.618979] cpu119 [0]=47|0 [1]=31|0 [2]=103|0 [3]=65|0 [4]=84|0 [5]=124|0 [ 273.625914] cpu120 [0]=74|0 [1]=18|0 [2]=87|0 [3]=117|0 [4]=17|0 [5]=62|0 [ 273.632762] cpu121 [0]=64|0 [1]=73|0 [2]=3|0 [3]=127|0 [4]=120|0 [5]=105|0 [ 273.639698] cpu122 [0]=46|128 [1]=89|128 [2]=22|128 [3]=78|128 [4]=100|128 [5]=106|128 [ 273.647671] cpu123 [0]=36|0 [1]=71|0 [2]=25|0 [3]=23|0 [4]=126|0 [5]=86|0 [ 273.654521] cpu124 [0]=26|0 [1]=93|0 [2]=101|0 [3]=103|0 [4]=54|0 [5]=100|0 [ 273.661542] cpu125 [0]=58|0 [1]=57|0 [2]=116|0 [3]=35|0 [4]=73|0 [5]=12|0 [ 273.668392] cpu126 [0]=11|0 [1]=54|0 [2]=41|0 [3]=0|0 [4]=27|0 [5]=54|0 [ 273.675067] cpu127 [0]=70|0 [1]=38|0 [2]=58|0 [3]=123|0 [4]=47|0 [5]=21|0 [ 273.681913] share cache: [0]=0 [1]=4 [2]=9 [3]=3 [4]=6 [5]=5 [ 273.687633] rb_total: 59443 estuary:/sys/kernel/debug/iommu/iovad/iommu_domain2$ echo 1 > drop_rca che estuary:/sys/kernel/debug/iommu/iovad/iommu_domain2$ cat iova_rcache [ 295.489690] cpu0 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.495786] cpu1 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.501861] cpu2 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.507929] cpu3 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.514004] cpu4 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.520074] cpu5 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.526142] cpu6 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.532212] cpu7 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.538287] cpu8 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.544355] cpu9 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.550423] cpu10 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.556581] cpu11 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.562739] cpu12 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.568897] cpu13 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.575054] cpu14 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.581209] cpu15 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.587368] cpu16 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.593525] cpu17 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.599680] cpu18 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.605837] cpu19 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.611999] cpu20 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.618159] cpu21 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.624313] cpu22 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.630467] cpu23 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.636624] cpu24 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.642779] cpu25 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.648933] cpu26 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.655088] cpu27 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.661241] cpu28 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.667396] cpu29 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.673549] cpu30 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.679703] cpu31 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.685857] cpu32 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.692010] cpu33 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.698165] cpu34 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.704319] cpu35 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.710474] cpu36 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.716628] cpu37 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.722782] cpu38 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.728936] cpu39 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.735091] cpu40 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.741246] cpu41 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.747400] cpu42 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.753553] cpu43 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.759707] cpu44 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.765860] cpu45 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.772014] cpu46 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.778168] cpu47 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.784322] cpu48 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.790476] cpu49 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.796632] cpu50 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.802786] cpu51 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.808941] cpu52 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.815095] cpu53 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.821250] cpu54 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.827405] cpu55 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.833561] cpu56 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.839716] cpu57 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.845870] cpu58 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.852024] cpu59 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.858181] cpu60 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.864336] cpu61 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.870492] cpu62 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.876646] cpu63 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.882801] cpu64 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.888956] cpu65 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.895109] cpu66 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.901265] cpu67 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.907419] cpu68 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.913574] cpu69 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.919729] cpu70 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.925882] cpu71 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.932037] cpu72 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.938191] cpu73 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.944345] cpu74 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.950499] cpu75 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.956653] cpu76 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.962807] cpu77 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.968961] cpu78 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.975115] cpu79 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.981269] cpu80 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.987423] cpu81 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.993578] cpu82 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 295.999731] cpu83 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.005885] cpu84 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.012040] cpu85 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.018196] cpu86 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.024350] cpu87 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.030504] cpu88 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.036659] cpu89 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.042814] cpu90 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.048968] cpu91 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.055122] cpu92 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.061275] cpu93 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.067429] cpu94 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.073582] cpu95 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.079736] cpu96 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.085890] cpu97 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.092043] cpu98 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.098198] cpu99 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.104352] cpu100 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.110593] cpu101 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.116834] cpu102 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.123076] cpu103 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.129315] cpu104 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.135555] cpu105 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.141795] cpu106 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.148035] cpu107 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.154275] cpu108 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.160515] cpu109 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.166757] cpu110 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.172997] cpu111 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.179237] cpu112 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.185477] cpu113 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.191717] cpu114 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.197958] cpu115 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.204198] cpu116 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.210438] cpu117 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.216677] cpu118 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.222917] cpu119 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.229157] cpu120 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.235398] cpu121 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.241638] cpu122 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.247879] cpu123 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.254121] cpu124 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.260361] cpu125 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.266601] cpu126 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.272843] cpu127 [0]=0|0 [1]=0|0 [2]=0|0 [3]=0|0 [4]=0|0 [5]=0|0 [ 296.279083] share cache: [0]=0 [1]=0 [2]=0 [3]=0 [4]=0 [5]=0 [ 296.284804] rb_total: 4134 estuary:/sys/kernel/debug/iommu/iovad/iommu_domain2$ We can add more debugfs interfaces if we want to. c00284940 (6): {topost} iommu: free rcache iovas when rmmod the driver of the last device {topost} iommu/iova: create iovad debugfs dir under iommu debugfs dir {topost} iommu/iova: create iommu domain debugfs dir under iovad debugfs dir {topost} iommu/iova: create debugfs file related to iova {topost} iommu/iova: trace how many iovas are in use {topost} iommu/iova: add a debugfs file drop_rcache to drop rcache drivers/iommu/dma-iommu.c | 9 +++++ drivers/iommu/iommu-debugfs.c | 93 +++++++++++++++++++++++++++++++++++++++++++ drivers/iommu/iommu.c | 26 +++++------- drivers/iommu/iova.c | 43 ++++++++------------ include/linux/dma-iommu.h | 6 ++- include/linux/iommu.h | 32 ++++++++++++++- include/linux/iova.h | 29 +++++++++++++- 7 files changed, 193 insertions(+), 45 deletions(-) -- 2.8.1

3 10

[PATCH] libata: configure max sectors properly
by chenxiang 31 May '21

31 May '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> Max sectors of limitations for scsi host can be set through scsi_host_template->max_sectors in scsi driver. But we find that max sectors may exceed scsi_host_template->max_sectors for SATA disk even if we set it. We find that it may be overwrote in some scsi drivers (which calls the callback slave_configure and also calls function ata_scsi_dev_config in it). The invoking relationship is as follows: scsi_probe_and_add_lun ... scsi_alloc_sdev scsi_mq_alloc_queue ... __scsi_init_queue blk_queue_max_hw_sectors(q, shost->max_sectors) //max_sectors coming from sht->max_sectors scsi_change_queue_depth scsi_sysfs_device_initialize shost->hostt->slave_alloc() xxx_salve_configure ... ata_scsi_dev_config blk_queue_max_hw_sectors(q, dev->max_sectors) //max_sectors is overwrote by dev->max_sectors To avoid the issue, set q->limits.max_sectors with the minimum value between dev->max_sectors and q->limits.max_sectors. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- drivers/ata/libata-scsi.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 48b8934..fb7b243 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -1026,12 +1026,15 @@ EXPORT_SYMBOL_GPL(ata_scsi_dma_need_drain); int ata_scsi_dev_config(struct scsi_device *sdev, struct ata_device *dev) { struct request_queue *q = sdev->request_queue; + unsigned int max_sectors; if (!ata_id_has_unload(dev->id)) dev->flags |= ATA_DFLAG_NO_UNLOAD; /* configure max sectors */ - blk_queue_max_hw_sectors(q, dev->max_sectors); + max_sectors = min_t(unsigned int, dev->max_sectors, + q->limits.max_sectors); + blk_queue_max_hw_sectors(q, max_sectors); if (dev->class == ATA_DEV_ATAPI) { sdev->sector_size = ATA_SECT_SIZE; -- 2.8.1

3 2

[PATCH 0/2] use bin_attribute to avoid buff overflow
by Tian Tao 31 May '21

31 May '21

The first patch adds a new function cpumap_print_to_buf and uses this function in drivers/base/topology.c, and the second patch uses this new function in drivers/base/node.c Tian Tao (2): topology: use bin_attribute to avoid buff overflow drivers/base/node.c: use bin_attribute to avoid buff overflow drivers/base/node.c | 50 +++++++++++++-------- drivers/base/topology.c | 115 ++++++++++++++++++++++++++---------------------- include/linux/bitmap.h | 3 ++ include/linux/cpumask.h | 25 +++++++++++ lib/bitmap.c | 34 ++++++++++++++ 5 files changed, 157 insertions(+), 70 deletions(-) -- 2.7.4

1 2

[PATCH v8] topology: use bin_attribute to avoid buff overflow
by Tian Tao 29 May '21

29 May '21

Reading sys/devices/system/cpu/cpuX/topology/ returns cpu topology. However, the size of this file is limited to PAGE_SIZE because of the limitation for sysfs attribute. so we use bin_attribute instead of attribute to avoid NR_CPUS too big to cause buff overflow. This patch is based on the following discussion. https://www.spinics.net/lists/linux-doc/msg95921.html Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- v2: rewrite the function name##_read v3: remove the temp buffer. v4: rewrite the function name##_read v5: rewrite the patch v6: update the commit message v7: remove BUFF_SIZE, dynamic calculation of size v8: Extracting the public part as a subfunction --- drivers/base/topology.c | 115 ++++++++++++++++++++++++++---------------------- include/linux/bitmap.h | 3 ++ include/linux/cpumask.h | 25 +++++++++++ lib/bitmap.c | 34 ++++++++++++++ 4 files changed, 125 insertions(+), 52 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..013edbb 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -21,25 +21,27 @@ static ssize_t name##_show(struct device *dev, \ return sysfs_emit(buf, "%d\n", topology_##name(dev->id)); \ } -#define define_siblings_show_map(name, mask) \ -static ssize_t name##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - return cpumap_print_to_pagebuf(false, buf, topology_##mask(dev->id));\ +#define define_siblings_read_func(name, mask) \ +static ssize_t name##_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + \ + return cpumap_print_to_buf(false, buf, topology_##mask(dev->id), \ + off, count); \ +} \ + \ +static ssize_t name##_list_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + \ + return cpumap_print_to_buf(true, buf, topology_##mask(dev->id), \ + off, count); \ } -#define define_siblings_show_list(name, mask) \ -static ssize_t name##_list_show(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - return cpumap_print_to_pagebuf(true, buf, topology_##mask(dev->id));\ -} - -#define define_siblings_show_func(name, mask) \ - define_siblings_show_map(name, mask); \ - define_siblings_show_list(name, mask) - define_id_show_func(physical_package_id); static DEVICE_ATTR_RO(physical_package_id); @@ -49,71 +51,80 @@ static DEVICE_ATTR_RO(die_id); define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); -define_siblings_show_func(thread_siblings, sibling_cpumask); -static DEVICE_ATTR_RO(thread_siblings); -static DEVICE_ATTR_RO(thread_siblings_list); +define_siblings_read_func(thread_siblings, sibling_cpumask); +static BIN_ATTR_RO(thread_siblings, 0); +static BIN_ATTR_RO(thread_siblings_list, 0); -define_siblings_show_func(core_cpus, sibling_cpumask); -static DEVICE_ATTR_RO(core_cpus); -static DEVICE_ATTR_RO(core_cpus_list); +define_siblings_read_func(core_cpus, sibling_cpumask); +static BIN_ATTR_RO(core_cpus, 0); +static BIN_ATTR_RO(core_cpus_list, 0); -define_siblings_show_func(core_siblings, core_cpumask); -static DEVICE_ATTR_RO(core_siblings); -static DEVICE_ATTR_RO(core_siblings_list); +define_siblings_read_func(core_siblings, core_cpumask); +static BIN_ATTR_RO(core_siblings, 0); +static BIN_ATTR_RO(core_siblings_list, 0); -define_siblings_show_func(die_cpus, die_cpumask); -static DEVICE_ATTR_RO(die_cpus); -static DEVICE_ATTR_RO(die_cpus_list); +define_siblings_read_func(die_cpus, die_cpumask); +static BIN_ATTR_RO(die_cpus, 0); +static BIN_ATTR_RO(die_cpus_list, 0); -define_siblings_show_func(package_cpus, core_cpumask); -static DEVICE_ATTR_RO(package_cpus); -static DEVICE_ATTR_RO(package_cpus_list); +define_siblings_read_func(package_cpus, core_cpumask); +static BIN_ATTR_RO(package_cpus, 0); +static BIN_ATTR_RO(package_cpus_list, 0); #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); -define_siblings_show_func(book_siblings, book_cpumask); -static DEVICE_ATTR_RO(book_siblings); -static DEVICE_ATTR_RO(book_siblings_list); +define_siblings_read_func(book_siblings, book_cpumask); +static BIN_ATTR_RO(book_siblings, 0); +static BIN_ATTR_RO(book_siblings_list, 0); #endif #ifdef CONFIG_SCHED_DRAWER define_id_show_func(drawer_id); static DEVICE_ATTR_RO(drawer_id); -define_siblings_show_func(drawer_siblings, drawer_cpumask); -static DEVICE_ATTR_RO(drawer_siblings); -static DEVICE_ATTR_RO(drawer_siblings_list); +define_siblings_read_func(drawer_siblings, drawer_cpumask); +static BIN_ATTR_RO(drawer_siblings, 0); +static BIN_ATTR_RO(drawer_siblings_list, 0); #endif +static struct bin_attribute *bin_attrs[] = { + &bin_attr_core_cpus, + &bin_attr_core_cpus_list, + &bin_attr_thread_siblings, + &bin_attr_thread_siblings_list, + &bin_attr_core_siblings, + &bin_attr_core_siblings_list, + &bin_attr_die_cpus, + &bin_attr_die_cpus_list, + &bin_attr_package_cpus, + &bin_attr_package_cpus_list, +#ifdef CONFIG_SCHED_BOOK + &bin_attr_book_siblings, + &bin_attr_book_siblings_list, +#endif +#ifdef CONFIG_SCHED_DRAWER + &bin_attr_drawer_siblings, + &bin_attr_drawer_siblings_list, +#endif + NULL, +}; + static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, &dev_attr_core_id.attr, - &dev_attr_thread_siblings.attr, - &dev_attr_thread_siblings_list.attr, - &dev_attr_core_cpus.attr, - &dev_attr_core_cpus_list.attr, - &dev_attr_core_siblings.attr, - &dev_attr_core_siblings_list.attr, - &dev_attr_die_cpus.attr, - &dev_attr_die_cpus_list.attr, - &dev_attr_package_cpus.attr, - &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, - &dev_attr_book_siblings.attr, - &dev_attr_book_siblings_list.attr, #endif #ifdef CONFIG_SCHED_DRAWER &dev_attr_drawer_id.attr, - &dev_attr_drawer_siblings.attr, - &dev_attr_drawer_siblings_list.attr, #endif NULL }; static const struct attribute_group topology_attr_group = { .attrs = default_attrs, + .bin_attrs = bin_attrs, .name = "topology" }; diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h index 70a9324..bc401bd9b 100644 --- a/include/linux/bitmap.h +++ b/include/linux/bitmap.h @@ -219,6 +219,9 @@ extern unsigned int bitmap_ord_to_pos(const unsigned long *bitmap, unsigned int extern int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp, int nmaskbits); +extern int bitmap_print_to_buf(bool list, char *buf, + const unsigned long *maskp, int nmaskbits, loff_t off, size_t count); + #define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 1))) #define BITMAP_LAST_WORD_MASK(nbits) (~0UL >> (-(nbits) & (BITS_PER_LONG - 1))) diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h index 383684e..e4810b3e 100644 --- a/include/linux/cpumask.h +++ b/include/linux/cpumask.h @@ -928,6 +928,31 @@ cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask) nr_cpu_ids); } +/** + * cpumap_print_to_buf - copies the cpumask into the buffer either + * as comma-separated list of cpus or hex values of cpumask + * @list: indicates whether the cpumap must be list + * @mask: the cpumask to copy + * @buf: the buffer to copy into + * @off: the offset that buffer to copy into + * @count: the count thatbuffer to copy into + * + * the role of cpumap_print_to_buf and cpumap_print_to_pagebuf is + * the same, the difference is that the second parameter of + * bitmap_print_to_buf can be more than one pagesize. + * + * Returns the length of the (null-terminated) @buf string, zero if + * nothing is copied. + */ + +static inline ssize_t +cpumap_print_to_buf(bool list, char *buf, const struct cpumask *mask, + loff_t off, size_t count) +{ + return bitmap_print_to_buf(list, buf, cpumask_bits(mask), + nr_cpu_ids, off, count); +} + #if NR_CPUS <= BITS_PER_LONG #define CPU_MASK_ALL \ (cpumask_t) { { \ diff --git a/lib/bitmap.c b/lib/bitmap.c index 75006c4..5bf89f1 100644 --- a/lib/bitmap.c +++ b/lib/bitmap.c @@ -460,6 +460,40 @@ int bitmap_parse_user(const char __user *ubuf, EXPORT_SYMBOL(bitmap_parse_user); /** + * bitmap_print_to_buf - convert bitmap to list or hex format ASCII string + * @list: indicates whether the bitmap must be list + * @buf: page aligned buffer into which string is placed + * @maskp: pointer to bitmap to convert + * @nmaskbits: size of bitmap, in bits + * @off: offset in buf + * @count: count that already output + * + * the role of bitmap_print_to_buf and bitmap_print_to_pagebuf is + * the same, the difference is that the second parameter of + * bitmap_print_to_buf can be more than one pagesize. + */ +int bitmap_print_to_buf(bool list, char *buf, const unsigned long *maskp, + int nmaskbits, loff_t off, size_t count) +{ + int len, size; + void *data; + char *fmt = list ? "%*pbl\n" : "%*pb\n"; + + len = snprintf(NULL, 0, fmt, nmaskbits, maskp); + + data = kvmalloc(len+1, GFP_KERNEL); + if (!data) + return -ENOMEM; + + size = scnprintf(data, len+1, fmt, nmaskbits, maskp); + size = memory_read_from_buffer(buf, count, &off, data, size); + kvfree(data); + + return size; +} +EXPORT_SYMBOL(bitmap_print_to_buf); + +/** * bitmap_print_to_pagebuf - convert bitmap to list or hex format ASCII string * @list: indicates whether the bitmap must be list * @buf: page aligned buffer into which string is placed -- 2.7.4

1 0

[PATCH v2] mm,kmemleak-test: add the dependency on CONFIG_SAMPLES
by chenxiang 28 May '21

28 May '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> As kmemleak-test.c is moved to samples dir, it is not compiled if just setting CONFIG_DEBUG_KMEMLEAK_TEST as module and enabling CONFIG_DEBUG_KMEMLEAK. So move the DEBUG_KMEMLEAK_TEST option to samples dir as well and rename it to SAMPLE_KMEMLEAK_TEST. And also replace DEBUG_KMEMLEAK_TEST with SAMPLE_KMEMLEAK_TEST in some other places. Fixes: 1abbef4f5172 ("mm,kmemleak-test.c: move kmemleak-test.c to samples dir") Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- Documentation/dev-tools/kmemleak.rst | 2 +- lib/Kconfig.debug | 8 -------- samples/Kconfig | 8 ++++++++ samples/Makefile | 2 +- samples/kmemleak/Makefile | 2 +- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst index 1c935f4..997b35d 100644 --- a/Documentation/dev-tools/kmemleak.rst +++ b/Documentation/dev-tools/kmemleak.rst @@ -228,7 +228,7 @@ Testing with kmemleak-test -------------------------- To check if you have all set up to use kmemleak, you can use the kmemleak-test -module, a module that deliberately leaks memory. Set CONFIG_DEBUG_KMEMLEAK_TEST +module, a module that deliberately leaks memory. Set CONFIG_SAMPLE_KMEMLEAK_TEST as module (it can't be used as built-in) and boot the kernel with kmemleak enabled. Load the module and perform a scan with:: diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index e88287e..b40931e 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -723,14 +723,6 @@ config DEBUG_KMEMLEAK_MEM_POOL_SIZE fully initialised, this memory pool acts as an emergency one if slab allocations fail. -config DEBUG_KMEMLEAK_TEST - tristate "Simple test for the kernel memory leak detector" - depends on DEBUG_KMEMLEAK && m - help - This option enables a module that explicitly leaks memory. - - If unsure, say N. - config DEBUG_KMEMLEAK_DEFAULT_OFF bool "Default kmemleak to off" depends on DEBUG_KMEMLEAK diff --git a/samples/Kconfig b/samples/Kconfig index eaa06c0..3ce77c7 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -223,6 +223,14 @@ config SAMPLE_WATCH_QUEUE Build example userspace program to use the new mount_notify(), sb_notify() syscalls and the KEYCTL_WATCH_KEY keyctl() function. +config SAMPLE_KMEMLEAK_TEST + tristate "Simple test for the kernel memory leak detector" + depends on DEBUG_KMEMLEAK && m + help + This option enables a module that explicitly leaks memory. + + If unsure, say N. + source "samples/rust/Kconfig" endif # SAMPLES diff --git a/samples/Makefile b/samples/Makefile index 291663e..ffb404b 100644 --- a/samples/Makefile +++ b/samples/Makefile @@ -29,5 +29,5 @@ subdir-$(CONFIG_SAMPLE_VFS) += vfs obj-$(CONFIG_SAMPLE_INTEL_MEI) += mei/ subdir-$(CONFIG_SAMPLE_WATCHDOG) += watchdog subdir-$(CONFIG_SAMPLE_WATCH_QUEUE) += watch_queue -obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak/ +obj-$(CONFIG_SAMPLE_KMEMLEAK_TEST) += kmemleak/ obj-$(CONFIG_SAMPLES_RUST) += rust/ diff --git a/samples/kmemleak/Makefile b/samples/kmemleak/Makefile index 16b6132..ce10176 100644 --- a/samples/kmemleak/Makefile +++ b/samples/kmemleak/Makefile @@ -1,3 +1,3 @@ # SPDX-License-Identifier: GPL-2.0-only -obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o +obj-$(CONFIG_SAMPLE_KMEMLEAK_TEST) += kmemleak-test.o -- 2.8.1

2 1

Re: Thanks
by AL-Kuwari Mohammed 28 May '21

28 May '21

Hello How are you today? i hope all is well with you.I have an urgent information for you. I know you will like this, please reply for more information. Yours truly AL-Kuwari Mohammed

1 0

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Jason Gunthorpe 27 May '21

27 May '21

On Thu, May 13, 2021 at 05:52:56PM +0000, Shameerali Kolothum Thodi wrote: > Since the devices we are concerned here are all integrated endpoints and if the > above quirk is an acceptable one, then we can use the uAPI as done in this > series without overly complicating things here. IMHO such a quirk in the core code should not be done. You need to override this in your own driver like Max was showing. I think we are very close to having worked out a great solution to the lingering questions on Max's last RFC, hopefully we can post an updated version soon Jason

3 3

[PATCH v7] topology: use bin_attribute to avoid buff overflow
by Tian Tao 27 May '21

27 May '21

Reading sys/devices/system/cpu/cpuX/topology/ returns cpu topology. However, the size of this file is limited to PAGE_SIZE because of the limitation for sysfs attribute. so we use bin_attribute instead of attribute to avoid NR_CPUS too big to cause buff overflow. This patch is based on the following discussion. https://www.spinics.net/lists/linux-doc/msg95921.html Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- v2: rewrite the function name##_read v3: remove the temp buffer. v4: rewrite the function name##_read v5: rewrite the patch v6: update the commit message v7: remove BUFF_SIZE, dynamic calculation of size --- drivers/base/topology.c | 144 +++++++++++++++++++++++++++++++----------------- 1 file changed, 94 insertions(+), 50 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..883fa39 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -21,24 +21,59 @@ static ssize_t name##_show(struct device *dev, \ return sysfs_emit(buf, "%d\n", topology_##name(dev->id)); \ } -#define define_siblings_show_map(name, mask) \ -static ssize_t name##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - return cpumap_print_to_pagebuf(false, buf, topology_##mask(dev->id));\ -} +static int topology_snprintf(char *buf, ssize_t size, const char *fmt, ...) +{ + va_list args; + int i; -#define define_siblings_show_list(name, mask) \ -static ssize_t name##_list_show(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - return cpumap_print_to_pagebuf(true, buf, topology_##mask(dev->id));\ + va_start(args, fmt); + if (size <= 0) + i = vsnprintf(NULL, 0, fmt, args); + else + i = vscnprintf(buf, size, fmt, args); + va_end(args); + + return i; } -#define define_siblings_show_func(name, mask) \ - define_siblings_show_map(name, mask); \ - define_siblings_show_list(name, mask) +#define define_siblings_read_func(name, mask) \ +static ssize_t name##_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + int len; \ + void *data; \ + len = topology_snprintf(NULL, 0, "%*pb\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + data = kvmalloc(len+1, GFP_KERNEL); \ + if (!data) \ + return -ENOMEM; \ + len = topology_snprintf(data, len+1, "%*pb\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + len = memory_read_from_buffer(buf, count, &off, data, len); \ + kvfree(data); \ + return len; \ +} \ + \ +static ssize_t name##_list_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + int len; \ + void *data; \ + len = topology_snprintf(NULL, 0, "%*pbl\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + data = kvmalloc(len+1, GFP_KERNEL); \ + if (!data) \ + return -ENOMEM; \ + len = topology_snprintf(data, len+1, "%*pbl\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + len = memory_read_from_buffer(buf, count, &off, data, len); \ + kvfree(data); \ + return len; \ +} define_id_show_func(physical_package_id); static DEVICE_ATTR_RO(physical_package_id); @@ -49,71 +84,80 @@ static DEVICE_ATTR_RO(die_id); define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); -define_siblings_show_func(thread_siblings, sibling_cpumask); -static DEVICE_ATTR_RO(thread_siblings); -static DEVICE_ATTR_RO(thread_siblings_list); +define_siblings_read_func(thread_siblings, sibling_cpumask); +static BIN_ATTR_RO(thread_siblings, 0); +static BIN_ATTR_RO(thread_siblings_list, 0); -define_siblings_show_func(core_cpus, sibling_cpumask); -static DEVICE_ATTR_RO(core_cpus); -static DEVICE_ATTR_RO(core_cpus_list); +define_siblings_read_func(core_cpus, sibling_cpumask); +static BIN_ATTR_RO(core_cpus, 0); +static BIN_ATTR_RO(core_cpus_list, 0); -define_siblings_show_func(core_siblings, core_cpumask); -static DEVICE_ATTR_RO(core_siblings); -static DEVICE_ATTR_RO(core_siblings_list); +define_siblings_read_func(core_siblings, core_cpumask); +static BIN_ATTR_RO(core_siblings, 0); +static BIN_ATTR_RO(core_siblings_list, 0); -define_siblings_show_func(die_cpus, die_cpumask); -static DEVICE_ATTR_RO(die_cpus); -static DEVICE_ATTR_RO(die_cpus_list); +define_siblings_read_func(die_cpus, die_cpumask); +static BIN_ATTR_RO(die_cpus, 0); +static BIN_ATTR_RO(die_cpus_list, 0); -define_siblings_show_func(package_cpus, core_cpumask); -static DEVICE_ATTR_RO(package_cpus); -static DEVICE_ATTR_RO(package_cpus_list); +define_siblings_read_func(package_cpus, core_cpumask); +static BIN_ATTR_RO(package_cpus, 0); +static BIN_ATTR_RO(package_cpus_list, 0); #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); -define_siblings_show_func(book_siblings, book_cpumask); -static DEVICE_ATTR_RO(book_siblings); -static DEVICE_ATTR_RO(book_siblings_list); +define_siblings_read_func(book_siblings, book_cpumask); +static BIN_ATTR_RO(book_siblings, 0); +static BIN_ATTR_RO(book_siblings_list, 0); #endif #ifdef CONFIG_SCHED_DRAWER define_id_show_func(drawer_id); static DEVICE_ATTR_RO(drawer_id); -define_siblings_show_func(drawer_siblings, drawer_cpumask); -static DEVICE_ATTR_RO(drawer_siblings); -static DEVICE_ATTR_RO(drawer_siblings_list); +define_siblings_read_func(drawer_siblings, drawer_cpumask); +static BIN_ATTR_RO(drawer_siblings, 0); +static BIN_ATTR_RO(drawer_siblings_list, 0); +#endif + +static struct bin_attribute *bin_attrs[] = { + &bin_attr_core_cpus, + &bin_attr_core_cpus_list, + &bin_attr_thread_siblings, + &bin_attr_thread_siblings_list, + &bin_attr_core_siblings, + &bin_attr_core_siblings_list, + &bin_attr_die_cpus, + &bin_attr_die_cpus_list, + &bin_attr_package_cpus, + &bin_attr_package_cpus_list, +#ifdef CONFIG_SCHED_BOOK + &bin_attr_book_siblings, + &bin_attr_book_siblings_list, #endif +#ifdef CONFIG_SCHED_DRAWER + &bin_attr_drawer_siblings, + &bin_attr_drawer_siblings_list, +#endif + NULL, +}; static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, &dev_attr_core_id.attr, - &dev_attr_thread_siblings.attr, - &dev_attr_thread_siblings_list.attr, - &dev_attr_core_cpus.attr, - &dev_attr_core_cpus_list.attr, - &dev_attr_core_siblings.attr, - &dev_attr_core_siblings_list.attr, - &dev_attr_die_cpus.attr, - &dev_attr_die_cpus_list.attr, - &dev_attr_package_cpus.attr, - &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, - &dev_attr_book_siblings.attr, - &dev_attr_book_siblings_list.attr, #endif #ifdef CONFIG_SCHED_DRAWER &dev_attr_drawer_id.attr, - &dev_attr_drawer_siblings.attr, - &dev_attr_drawer_siblings_list.attr, #endif NULL }; static const struct attribute_group topology_attr_group = { .attrs = default_attrs, + .bin_attrs = bin_attrs, .name = "topology" }; -- 2.7.4

3 2

[PATCH] mm,kmemleak-test: add the dependency on CONFIG_SAMPLES
by chenxiang 27 May '21

27 May '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> As kmemleak-test.c is moved to samples dir, it is not compiled if just setting CONFIG_DEBUG_KMEMLEAK_TEST as module and enabling CONFIG_DEBUG_KMEMLEAK. Because it depends on CONFIG_SAMPLES after it is moved to samples dir. So the dependency on CONFIG_SAMPLES is added. Fixes: 1abbef4f5172 ("mm,kmemleak-test.c: move kmemleak-test.c to samples dir") Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- lib/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 2779c29..9950542 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -716,7 +716,7 @@ config DEBUG_KMEMLEAK_MEM_POOL_SIZE config DEBUG_KMEMLEAK_TEST tristate "Simple test for the kernel memory leak detector" - depends on DEBUG_KMEMLEAK && m + depends on DEBUG_KMEMLEAK && SAMPLES && m help This option enables a module that explicitly leaks memory. -- 2.8.1

3 2

[PATCH v6] topology: use bin_attribute to avoid buff overflow
by Tian Tao 26 May '21

26 May '21

Reading sys/devices/system/cpu/cpu0/topology/ returns cpu topology. However, the size of this file is limited to PAGE_SIZE because of the limitation for sysfs attribute. so we use bin_attribute instead of attribute to avoid NR_CPUS too big to cause buff overflow. This patch is based on the following discussion. https://www.spinics.net/lists/linux-doc/msg95921.html Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- v2: rewrite the function name##_read v3: remove the temp buffer. v4: rewrite the function name##_read v5: rewrite the patch v6: update the commit message --- drivers/base/topology.c | 135 +++++++++++++++++++++++++++++------------------- 1 file changed, 83 insertions(+), 52 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..c46b217 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -14,6 +14,9 @@ #include <linux/hardirq.h> #include <linux/topology.h> +/* BUFF_SIZE need 9 chars per 32 bits. */ +#define BUFF_SIZE ((NR_CPUS/32)*9) + #define define_id_show_func(name) \ static ssize_t name##_show(struct device *dev, \ struct device_attribute *attr, char *buf) \ @@ -21,25 +24,41 @@ static ssize_t name##_show(struct device *dev, \ return sysfs_emit(buf, "%d\n", topology_##name(dev->id)); \ } -#define define_siblings_show_map(name, mask) \ -static ssize_t name##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - return cpumap_print_to_pagebuf(false, buf, topology_##mask(dev->id));\ +#define define_siblings_read_func(name, mask) \ +static ssize_t name##_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + int len; \ + void *data; \ + data = kvmalloc(BUFF_SIZE, GFP_KERNEL); \ + if (!data) \ + return -ENOMEM; \ + len = scnprintf(data, BUFF_SIZE, "%*pb\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + len = memory_read_from_buffer(buf, count, &off, data, len); \ + kvfree(data); \ + return len; \ +} \ + \ +static ssize_t name##_list_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + int len; \ + void *data; \ + data = kvmalloc(BUFF_SIZE, GFP_KERNEL); \ + if (!data) \ + return -ENOMEM; \ + len = scnprintf(data, BUFF_SIZE, "%*pbl\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + len = memory_read_from_buffer(buf, count, &off, data, len); \ + kvfree(data); \ + return len; \ } -#define define_siblings_show_list(name, mask) \ -static ssize_t name##_list_show(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - return cpumap_print_to_pagebuf(true, buf, topology_##mask(dev->id));\ -} - -#define define_siblings_show_func(name, mask) \ - define_siblings_show_map(name, mask); \ - define_siblings_show_list(name, mask) - define_id_show_func(physical_package_id); static DEVICE_ATTR_RO(physical_package_id); @@ -49,71 +68,83 @@ static DEVICE_ATTR_RO(die_id); define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); -define_siblings_show_func(thread_siblings, sibling_cpumask); -static DEVICE_ATTR_RO(thread_siblings); -static DEVICE_ATTR_RO(thread_siblings_list); +define_siblings_read_func(thread_siblings, sibling_cpumask); +static BIN_ATTR_RO(thread_siblings, 0); +static BIN_ATTR_RO(thread_siblings_list, 0); + +define_siblings_read_func(core_cpus, sibling_cpumask); +static BIN_ATTR_RO(core_cpus, 0); +static BIN_ATTR_RO(core_cpus_list, 0); -define_siblings_show_func(core_cpus, sibling_cpumask); -static DEVICE_ATTR_RO(core_cpus); -static DEVICE_ATTR_RO(core_cpus_list); +define_siblings_read_func(core_siblings, core_cpumask); +static BIN_ATTR_RO(core_siblings, 0); +static BIN_ATTR_RO(core_siblings_list, 0); -define_siblings_show_func(core_siblings, core_cpumask); -static DEVICE_ATTR_RO(core_siblings); -static DEVICE_ATTR_RO(core_siblings_list); -define_siblings_show_func(die_cpus, die_cpumask); -static DEVICE_ATTR_RO(die_cpus); -static DEVICE_ATTR_RO(die_cpus_list); +define_siblings_read_func(die_cpus, die_cpumask); +static BIN_ATTR_RO(die_cpus, 0); +static BIN_ATTR_RO(die_cpus_list, 0); + + +define_siblings_read_func(package_cpus, core_cpumask); +static BIN_ATTR_RO(package_cpus, 0); +static BIN_ATTR_RO(package_cpus_list, 0); -define_siblings_show_func(package_cpus, core_cpumask); -static DEVICE_ATTR_RO(package_cpus); -static DEVICE_ATTR_RO(package_cpus_list); #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); -define_siblings_show_func(book_siblings, book_cpumask); -static DEVICE_ATTR_RO(book_siblings); -static DEVICE_ATTR_RO(book_siblings_list); +define_siblings_read_func(book_siblings, book_cpumask); +static BIN_ATTR_RO(book_siblings, 0); +static BIN_ATTR_RO(book_siblings_list, 0); #endif #ifdef CONFIG_SCHED_DRAWER define_id_show_func(drawer_id); static DEVICE_ATTR_RO(drawer_id); -define_siblings_show_func(drawer_siblings, drawer_cpumask); -static DEVICE_ATTR_RO(drawer_siblings); -static DEVICE_ATTR_RO(drawer_siblings_list); +define_siblings_read_func(drawer_siblings, drawer_cpumask); +static BIN_ATTR_RO(drawer_siblings, 0); +static BIN_ATTR_RO(drawer_siblings_list, 0); +#endif + +static struct bin_attribute *bin_attrs[] = { + &bin_attr_core_cpus, + &bin_attr_core_cpus_list, + &bin_attr_thread_siblings, + &bin_attr_thread_siblings_list, + &bin_attr_core_siblings, + &bin_attr_core_siblings_list, + &bin_attr_die_cpus, + &bin_attr_die_cpus_list, + &bin_attr_package_cpus, + &bin_attr_package_cpus_list, +#ifdef CONFIG_SCHED_BOOK + &bin_attr_book_siblings, + &bin_attr_book_siblings_list, +#endif +#ifdef CONFIG_SCHED_DRAWER + &bin_attr_drawer_siblings, + &bin_attr_drawer_siblings_list, #endif + NULL, +}; static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, &dev_attr_core_id.attr, - &dev_attr_thread_siblings.attr, - &dev_attr_thread_siblings_list.attr, - &dev_attr_core_cpus.attr, - &dev_attr_core_cpus_list.attr, - &dev_attr_core_siblings.attr, - &dev_attr_core_siblings_list.attr, - &dev_attr_die_cpus.attr, - &dev_attr_die_cpus_list.attr, - &dev_attr_package_cpus.attr, - &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, - &dev_attr_book_siblings.attr, - &dev_attr_book_siblings_list.attr, #endif #ifdef CONFIG_SCHED_DRAWER &dev_attr_drawer_id.attr, - &dev_attr_drawer_siblings.attr, - &dev_attr_drawer_siblings_list.attr, #endif NULL }; static const struct attribute_group topology_attr_group = { .attrs = default_attrs, + .bin_attrs = bin_attrs, .name = "topology" }; -- 2.7.4

3 2

Re: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks within one LLC
by Dietmar Eggemann 26 May '21

26 May '21

On 03/05/2021 13:35, Song Bao Hua (Barry Song) wrote: [...] >> From: Song Bao Hua (Barry Song) [...] >>> From: Dietmar Eggemann [mailto:dietmar.eggemann@arm.com] [...] >>> On 29/04/2021 00:41, Song Bao Hua (Barry Song) wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Dietmar Eggemann [mailto:dietmar.eggemann@arm.com] >>> >>> [...] >>> >>>>>>>> From: Dietmar Eggemann [mailto:dietmar.eggemann@arm.com] >>>>> >>>>> [...] >>>>> >>>>>>>> On 20/04/2021 02:18, Barry Song wrote: [...] > > On the other hand, according to "sched: Implement smarter wake-affine logic" > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… > > Proper factor in wake_wide is mainly beneficial of 1:n tasks like postgresql/pgbench. > So using the smaller cluster size as factor might help make wake_affine false so > improve pgbench. > > From the commit log, while clients = 2*cpus, the commit made the biggest > improvement. In my case, It should be clients=48 for a machine whose LLC > size is 24. > > In Linux, I created a 240MB database and ran "pgbench -c 48 -S -T 20 pgbench" > under two different scenarios: > 1. page cache always hit, so no real I/O for database read > 2. echo 3 > /proc/sys/vm/drop_caches > > For case 1, using cluster_size and using llc_size will result in similar > tps= ~108000, all of 24 cpus have 100% cpu utilization. > > For case 2, using llc_size still shows better performance. > > tps for each test round(cluster size as factor in wake_wide): > 1398.450887 1275.020401 1632.542437 1412.241627 1611.095692 1381.354294 1539.877146 > avg tps = 1464 > > tps for each test round(llc size as factor in wake_wide): > 1718.402983 1443.169823 1502.353823 1607.415861 1597.396924 1745.651814 1876.802168 > avg tps = 1641 (+12%) > > so it seems using cluster_size as factor in "slave >= factor && master >= slave * > factor" isn't a good choice for my machine at least. So SD size = 4 (instead of 24) seems to be too small for `-c 48`. Just curious, have you seen the benefit of using wake wide on SD size = 24 (LLC) compared to not using it at all?

2 4

[PATCH v5] topology: use bin_attribute to avoid buff overflow
by Tian Tao 25 May '21

25 May '21

Use bin_attribute to display thread_siblings/core_cpus/core_siblings, die_cpus/package_cpus/book_siblings/drawer_siblings,avoiding NR_CPUS too big to cause buff overflow. This patch is based on the following discussion. https://www.spinics.net/lists/linux-doc/msg95921.html Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- v2: rewrite the function name##_read v3: remove the temp buffer. v4: rewrite the function name##_read v4: rewrite the patch --- drivers/base/topology.c | 139 ++++++++++++++++++++++++++++++------------------ 1 file changed, 87 insertions(+), 52 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..443e2b8 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -14,6 +14,9 @@ #include <linux/hardirq.h> #include <linux/topology.h> +/* BUFF_SIZE need 9 chars per 32 bits. */ +#define BUFF_SIZE ((NR_CPUS/32)*9) + #define define_id_show_func(name) \ static ssize_t name##_show(struct device *dev, \ struct device_attribute *attr, char *buf) \ @@ -21,25 +24,41 @@ static ssize_t name##_show(struct device *dev, \ return sysfs_emit(buf, "%d\n", topology_##name(dev->id)); \ } -#define define_siblings_show_map(name, mask) \ -static ssize_t name##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - return cpumap_print_to_pagebuf(false, buf, topology_##mask(dev->id));\ +#define define_siblings_read_func(name, mask) \ +static ssize_t name##_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + int len; \ + void *data; \ + data = kvmalloc(BUFF_SIZE, GFP_KERNEL); \ + if (!data) \ + return -ENOMEM; \ + len = scnprintf(data, BUFF_SIZE, "%*pb\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + len = memory_read_from_buffer(buf, count, &off, data, len); \ + kvfree(data); \ + return len; \ +} \ + \ +static ssize_t name##_list_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + int len; \ + void *data; \ + data = kvmalloc(BUFF_SIZE, GFP_KERNEL); \ + if (!data) \ + return -ENOMEM; \ + len = scnprintf(data, BUFF_SIZE, "%*pbl\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + len = memory_read_from_buffer(buf, count, &off, data, len); \ + kvfree(data); \ + return len; \ } -#define define_siblings_show_list(name, mask) \ -static ssize_t name##_list_show(struct device *dev, \ - struct device_attribute *attr, \ - char *buf) \ -{ \ - return cpumap_print_to_pagebuf(true, buf, topology_##mask(dev->id));\ -} - -#define define_siblings_show_func(name, mask) \ - define_siblings_show_map(name, mask); \ - define_siblings_show_list(name, mask) - define_id_show_func(physical_package_id); static DEVICE_ATTR_RO(physical_package_id); @@ -49,71 +68,87 @@ static DEVICE_ATTR_RO(die_id); define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); -define_siblings_show_func(thread_siblings, sibling_cpumask); -static DEVICE_ATTR_RO(thread_siblings); -static DEVICE_ATTR_RO(thread_siblings_list); +define_siblings_read_func(thread_siblings, sibling_cpumask); +static BIN_ATTR_RO(thread_siblings, 0); +static BIN_ATTR_RO(thread_siblings_list, 0); + + +define_siblings_read_func(core_cpus, sibling_cpumask); +static BIN_ATTR_RO(core_cpus, 0); +static BIN_ATTR_RO(core_cpus_list, 0); + +define_siblings_read_func(core_siblings, core_cpumask); +static BIN_ATTR_RO(core_siblings, 0); +static BIN_ATTR_RO(core_siblings_list, 0); -define_siblings_show_func(core_cpus, sibling_cpumask); -static DEVICE_ATTR_RO(core_cpus); -static DEVICE_ATTR_RO(core_cpus_list); -define_siblings_show_func(core_siblings, core_cpumask); -static DEVICE_ATTR_RO(core_siblings); -static DEVICE_ATTR_RO(core_siblings_list); +define_siblings_read_func(die_cpus, die_cpumask); +static BIN_ATTR_RO(die_cpus, 0); +static BIN_ATTR_RO(die_cpus_list, 0); -define_siblings_show_func(die_cpus, die_cpumask); -static DEVICE_ATTR_RO(die_cpus); -static DEVICE_ATTR_RO(die_cpus_list); -define_siblings_show_func(package_cpus, core_cpumask); -static DEVICE_ATTR_RO(package_cpus); -static DEVICE_ATTR_RO(package_cpus_list); +define_siblings_read_func(package_cpus, core_cpumask); +static BIN_ATTR_RO(package_cpus, 0); +static BIN_ATTR_RO(package_cpus_list, 0); + #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); -define_siblings_show_func(book_siblings, book_cpumask); -static DEVICE_ATTR_RO(book_siblings); -static DEVICE_ATTR_RO(book_siblings_list); +define_siblings_read_func(book_siblings, book_cpumask); +static BIN_ATTR_RO(book_siblings, 0); +static BIN_ATTR_RO(book_siblings_list, 0); + #endif #ifdef CONFIG_SCHED_DRAWER define_id_show_func(drawer_id); static DEVICE_ATTR_RO(drawer_id); -define_siblings_show_func(drawer_siblings, drawer_cpumask); -static DEVICE_ATTR_RO(drawer_siblings); -static DEVICE_ATTR_RO(drawer_siblings_list); +define_siblings_read_func(drawer_siblings, drawer_cpumask); +static BIN_ATTR_RO(drawer_siblings, 0); +static BIN_ATTR_RO(drawer_siblings_list, 0); + +#endif + + +static struct bin_attribute *bin_attrs[] = { + &bin_attr_core_cpus, + &bin_attr_core_cpus_list, + &bin_attr_thread_siblings, + &bin_attr_thread_siblings_list, + &bin_attr_core_siblings, + &bin_attr_core_siblings_list, + &bin_attr_die_cpus, + &bin_attr_die_cpus_list, + &bin_attr_package_cpus, + &bin_attr_package_cpus_list, +#ifdef CONFIG_SCHED_BOOK + &bin_attr_book_siblings, + &bin_attr_book_siblings_list, #endif +#ifdef CONFIG_SCHED_DRAWER + &bin_attr_drawer_siblings, + &bin_attr_drawer_siblings_list, +#endif + NULL, +}; static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, &dev_attr_core_id.attr, - &dev_attr_thread_siblings.attr, - &dev_attr_thread_siblings_list.attr, - &dev_attr_core_cpus.attr, - &dev_attr_core_cpus_list.attr, - &dev_attr_core_siblings.attr, - &dev_attr_core_siblings_list.attr, - &dev_attr_die_cpus.attr, - &dev_attr_die_cpus_list.attr, - &dev_attr_package_cpus.attr, - &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, - &dev_attr_book_siblings.attr, - &dev_attr_book_siblings_list.attr, #endif #ifdef CONFIG_SCHED_DRAWER &dev_attr_drawer_id.attr, - &dev_attr_drawer_siblings.attr, - &dev_attr_drawer_siblings_list.attr, #endif NULL }; static const struct attribute_group topology_attr_group = { .attrs = default_attrs, + .bin_attrs = bin_attrs, .name = "topology" }; -- 2.7.4

1 0

[PATCH v4] topology: use bin_attribute to avoid buff overflow
by Tian Tao 25 May '21

25 May '21

Use bin_attribute to display thread_siblings/core_cpus/core_siblings, die_cpus/package_cpus/book_siblings/drawer_siblings,avoiding NR_CPUS too big to cause buff overflow. This patch is based on the following discussion. https://www.spinics.net/lists/linux-doc/msg95921.html Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- v2: rewrite the function name##_read v3: remove the temp buffer. v4: rewrite the function name##_read --- drivers/base/topology.c | 64 +++++++++++++++++++++++++++++++++---------------- 1 file changed, 44 insertions(+), 20 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..6b160ea 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -14,6 +14,9 @@ #include <linux/hardirq.h> #include <linux/topology.h> +/* BUFF_SIZE need 9 chars per 32 bits. */ +#define BUFF_SIZE ((NR_CPUS/32)*9) + #define define_id_show_func(name) \ static ssize_t name##_show(struct device *dev, \ struct device_attribute *attr, char *buf) \ @@ -21,11 +24,22 @@ static ssize_t name##_show(struct device *dev, \ return sysfs_emit(buf, "%d\n", topology_##name(dev->id)); \ } -#define define_siblings_show_map(name, mask) \ -static ssize_t name##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - return cpumap_print_to_pagebuf(false, buf, topology_##mask(dev->id));\ +#define define_siblings_read(name, mask) \ +static ssize_t name##_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + int len; \ + void *data; \ + data = kvmalloc(BUFF_SIZE, GFP_KERNEL); \ + if (!data) \ + return -ENOMEM; \ + len = scnprintf(data, BUFF_SIZE, "%*pb\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + len = memory_read_from_buffer(buf, count, &off, data, len); \ + kvfree(data); \ + return len; \ } #define define_siblings_show_list(name, mask) \ @@ -37,7 +51,7 @@ static ssize_t name##_list_show(struct device *dev, \ } #define define_siblings_show_func(name, mask) \ - define_siblings_show_map(name, mask); \ + define_siblings_read(name, mask); \ define_siblings_show_list(name, mask) define_id_show_func(physical_package_id); @@ -50,30 +64,30 @@ define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); define_siblings_show_func(thread_siblings, sibling_cpumask); -static DEVICE_ATTR_RO(thread_siblings); +static BIN_ATTR_RO(thread_siblings, 0); static DEVICE_ATTR_RO(thread_siblings_list); define_siblings_show_func(core_cpus, sibling_cpumask); -static DEVICE_ATTR_RO(core_cpus); +static BIN_ATTR_RO(core_cpus, 0); static DEVICE_ATTR_RO(core_cpus_list); define_siblings_show_func(core_siblings, core_cpumask); -static DEVICE_ATTR_RO(core_siblings); +static BIN_ATTR_RO(core_siblings, 0); static DEVICE_ATTR_RO(core_siblings_list); define_siblings_show_func(die_cpus, die_cpumask); -static DEVICE_ATTR_RO(die_cpus); +static BIN_ATTR_RO(die_cpus, 0); static DEVICE_ATTR_RO(die_cpus_list); define_siblings_show_func(package_cpus, core_cpumask); -static DEVICE_ATTR_RO(package_cpus); +static BIN_ATTR_RO(package_cpus, 0); static DEVICE_ATTR_RO(package_cpus_list); #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); define_siblings_show_func(book_siblings, book_cpumask); -static DEVICE_ATTR_RO(book_siblings); +static BIN_ATTR_RO(book_siblings, 0); static DEVICE_ATTR_RO(book_siblings_list); #endif @@ -81,32 +95,41 @@ static DEVICE_ATTR_RO(book_siblings_list); define_id_show_func(drawer_id); static DEVICE_ATTR_RO(drawer_id); define_siblings_show_func(drawer_siblings, drawer_cpumask); -static DEVICE_ATTR_RO(drawer_siblings); +static BIN_ATTR_RO(drawer_siblings, 0; static DEVICE_ATTR_RO(drawer_siblings_list); #endif + +static struct bin_attribute *bin_attrs[] = { + &bin_attr_thread_siblings, + &bin_attr_core_cpus, + &bin_attr_core_siblings, + &bin_attr_die_cpus, + &bin_attr_package_cpus, +#ifdef CONFIG_SCHED_BOOK + &bin_attr_book_siblings, +#endif +#ifdef CONFIG_SCHED_DRAWER + &bin_attr_drawer_siblings, +#endif + NULL, +}; + static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, &dev_attr_core_id.attr, - &dev_attr_thread_siblings.attr, &dev_attr_thread_siblings_list.attr, - &dev_attr_core_cpus.attr, &dev_attr_core_cpus_list.attr, - &dev_attr_core_siblings.attr, &dev_attr_core_siblings_list.attr, - &dev_attr_die_cpus.attr, &dev_attr_die_cpus_list.attr, - &dev_attr_package_cpus.attr, &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, - &dev_attr_book_siblings.attr, &dev_attr_book_siblings_list.attr, #endif #ifdef CONFIG_SCHED_DRAWER &dev_attr_drawer_id.attr, - &dev_attr_drawer_siblings.attr, &dev_attr_drawer_siblings_list.attr, #endif NULL @@ -114,6 +137,7 @@ static struct attribute *default_attrs[] = { static const struct attribute_group topology_attr_group = { .attrs = default_attrs, + .bin_attrs = bin_attrs, .name = "topology" }; -- 2.7.4

4 3

[PATCH RFC v4 0/3] Some optimization for lockless qdisc
by Yunsheng Lin 21 May '21

21 May '21

Patch 1: remove unnecessary seqcount operation. Patch 2: implement TCQ_F_CAN_BYPASS. Patch 3: remove qdisc->empty. RFC v4: Use STATE_MISSED and STATE_DRAINING to indicate non-empty qdisc, and add patch 1 and 3. Yunsheng Lin (3): net: sched: avoid unnecessary seqcount operation for lockless qdisc net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc net: sched: remove qdisc->empty for lockless qdisc include/net/sch_generic.h | 26 +++++++++++++------------- net/core/dev.c | 22 ++++++++++++++++++++-- net/sched/sch_generic.c | 23 ++++++++++++++++------- 3 files changed, 49 insertions(+), 22 deletions(-) -- 2.7.4

2 6

[PATCH] dma-iommu: Add a check to avoid dereference null pointer in function iommu_dma_map_sg()
by chenxiang 21 May '21

21 May '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> The issue is reported by tool TscanCode, and it is possible to deference null pointer when prev is NULL which is the initial value. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- drivers/iommu/dma-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 4cb63b2..88a4f34 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -1042,7 +1042,7 @@ static int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg, * iova_len == 0, thus we cannot dereference prev the first * time through here (i.e. before it has a meaningful value). */ - if (pad_len && pad_len < s_length - 1) { + if (prev && pad_len && pad_len < s_length - 1) { prev->length += pad_len; iova_len += pad_len; } -- 2.8.1

3 2

Re: [PATCH 6/9] tty: hvc_console: Fix coding style issues of block comments
by Johan Hovold 21 May '21

21 May '21

On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote: > Fix coding style issues of block comments, reported by checkpatch.pl. > Besides, add a period at the end of the sentenses. > > Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> > --- > drivers/tty/hvc/hvc_console.c | 15 ++++++++++----- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c > index 39018e5..a61cdf0 100644 > --- a/drivers/tty/hvc/hvc_console.c > +++ b/drivers/tty/hvc/hvc_console.c > @@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b, > r = cons_ops[index]->put_chars(vtermnos[index], c, i); > if (r <= 0) { > /* throw away characters on error > - * but spin in case of -EAGAIN */ > + * but spin in case of -EAGAIN. > + */ How is this an improvement? First, the multi-line comment style is /* * ... */ Second, that sentence is not capitalised so why do add a period? Third, why are you sending checkpatch.pl cleanups for files outside of staging? Unless doing some real changes to the files in question as well this is mostly just churn and noise that makes it harder to backport fixes and do code forensics for no real gain. Greg may disagree, but I don't think we should be encouraging this kind of patches. Johan

3 7

[PATCH v3] topology: use bin_attribute to avoid buff overflow
by Tian Tao 21 May '21

21 May '21

Use bin_attribute to display thread_siblings/core_cpus/core_siblings, die_cpus/package_cpus/book_siblings/drawer_siblings,avoiding NR_CPUS too big to cause buff overflow. This patch is based on the following discussion. https://www.spinics.net/lists/linux-doc/msg95921.html Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- v2: rewrite the function name##_read v3: remove the temp buffer. --- drivers/base/topology.c | 55 +++++++++++++++++++++++++++++++------------------ 1 file changed, 35 insertions(+), 20 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..87bddd0 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -21,11 +21,16 @@ static ssize_t name##_show(struct device *dev, \ return sysfs_emit(buf, "%d\n", topology_##name(dev->id)); \ } -#define define_siblings_show_map(name, mask) \ -static ssize_t name##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - return cpumap_print_to_pagebuf(false, buf, topology_##mask(dev->id));\ +#define define_siblings_read(name, mask) \ +static ssize_t name##_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + if (off != 0) \ + return 0; \ + return scnprintf(buf, count, "%*pb\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ } #define define_siblings_show_list(name, mask) \ @@ -37,7 +42,7 @@ static ssize_t name##_list_show(struct device *dev, \ } #define define_siblings_show_func(name, mask) \ - define_siblings_show_map(name, mask); \ + define_siblings_read(name, mask); \ define_siblings_show_list(name, mask) define_id_show_func(physical_package_id); @@ -50,30 +55,30 @@ define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); define_siblings_show_func(thread_siblings, sibling_cpumask); -static DEVICE_ATTR_RO(thread_siblings); +static BIN_ATTR_RO(thread_siblings, 0); static DEVICE_ATTR_RO(thread_siblings_list); define_siblings_show_func(core_cpus, sibling_cpumask); -static DEVICE_ATTR_RO(core_cpus); +static BIN_ATTR_RO(core_cpus, 0); static DEVICE_ATTR_RO(core_cpus_list); define_siblings_show_func(core_siblings, core_cpumask); -static DEVICE_ATTR_RO(core_siblings); +static BIN_ATTR_RO(core_siblings, 0); static DEVICE_ATTR_RO(core_siblings_list); define_siblings_show_func(die_cpus, die_cpumask); -static DEVICE_ATTR_RO(die_cpus); +static BIN_ATTR_RO(die_cpus, 0); static DEVICE_ATTR_RO(die_cpus_list); define_siblings_show_func(package_cpus, core_cpumask); -static DEVICE_ATTR_RO(package_cpus); +static BIN_ATTR_RO(package_cpus, 0); static DEVICE_ATTR_RO(package_cpus_list); #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); define_siblings_show_func(book_siblings, book_cpumask); -static DEVICE_ATTR_RO(book_siblings); +static BIN_ATTR_RO(book_siblings, 0); static DEVICE_ATTR_RO(book_siblings_list); #endif @@ -81,32 +86,41 @@ static DEVICE_ATTR_RO(book_siblings_list); define_id_show_func(drawer_id); static DEVICE_ATTR_RO(drawer_id); define_siblings_show_func(drawer_siblings, drawer_cpumask); -static DEVICE_ATTR_RO(drawer_siblings); +static BIN_ATTR_RO(drawer_siblings, 0; static DEVICE_ATTR_RO(drawer_siblings_list); #endif + +static struct bin_attribute *bin_attrs[] = { + &bin_attr_thread_siblings, + &bin_attr_core_cpus, + &bin_attr_core_siblings, + &bin_attr_die_cpus, + &bin_attr_package_cpus, +#ifdef CONFIG_SCHED_BOOK + &bin_attr_book_siblings, +#endif +#ifdef CONFIG_SCHED_DRAWER + &bin_attr_drawer_siblings, +#endif + NULL, +}; + static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, &dev_attr_core_id.attr, - &dev_attr_thread_siblings.attr, &dev_attr_thread_siblings_list.attr, - &dev_attr_core_cpus.attr, &dev_attr_core_cpus_list.attr, - &dev_attr_core_siblings.attr, &dev_attr_core_siblings_list.attr, - &dev_attr_die_cpus.attr, &dev_attr_die_cpus_list.attr, - &dev_attr_package_cpus.attr, &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, - &dev_attr_book_siblings.attr, &dev_attr_book_siblings_list.attr, #endif #ifdef CONFIG_SCHED_DRAWER &dev_attr_drawer_id.attr, - &dev_attr_drawer_siblings.attr, &dev_attr_drawer_siblings_list.attr, #endif NULL @@ -114,6 +128,7 @@ static struct attribute *default_attrs[] = { static const struct attribute_group topology_attr_group = { .attrs = default_attrs, + .bin_attrs = bin_attrs, .name = "topology" }; -- 2.7.4

1 0

[PATCH RESEND] tty: hvc_console: Remove the repeated words 'no' and 'from'
by Xiaofei Tan 21 May '21

21 May '21

Remove the repeated words 'no' and 'from', reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index cdcc64e..bdd8d2b 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -292,7 +292,7 @@ int hvc_instantiate(uint32_t vtermno, int index, const struct hv_ops *ops) if (vtermnos[index] != -1) return -1; - /* make sure no no tty has been registered in this index */ + /* make sure no tty has been registered in this index */ hp = hvc_get_by_index(index); if (hp) { tty_port_put(&hp->port); @@ -620,7 +620,7 @@ static u32 timeout = MIN_TIMEOUT; /* * Maximum number of bytes to get from the console driver if hvc_poll is * called from driver (and can't sleep). Any more than this and we break - * and start polling with khvcd. This value was derived from from an OpenBMC + * and start polling with khvcd. This value was derived from an OpenBMC * console with the OPAL driver that results in about 0.25ms interrupts off * latency. */ -- 2.8.1

1 0

Re: [PATCH 0/9] tty: hvc_console: Fix some coding style issues
by Greg KH 21 May '21

21 May '21

On Mon, May 17, 2021 at 02:37:04PM +0800, Xiaofei Tan wrote: > Fix some issues reported by checkpatch.pl. All of them are > coding style issues, no function changes. > > Xiaofei Tan (9): > tty: hvc_console: Fix spaces required around that '=' > tty: hvc_console: Fix "foo * bar" should be "foo *bar" > tty: hvc_console: Remove trailing whitespace > tty: hvc_console: Fix issues of code indent should use tabs > tty: hvc_console: Delete spaces prohibited around open parenthesis '(' > and ')' > tty: hvc_console: Fix coding style issues of block comments > tty: hvc_console: Add a blank line after declarations > tty: hvc_console: Remove the repeated words 'no' and 'from' > tty: hvc_console: Move open brace { on the previous line > > drivers/tty/hvc/hvc_console.c | 37 ++++++++++++++++++++++--------------- > 1 file changed, 22 insertions(+), 15 deletions(-) Do you use this driver? If so, great, I'm sure there are other "real" issues in it that need some work. But as Johan points out, doing drive-by checkpatch cleanups on random files that you do not use, isn't the best thing to do. If you just want to do this type of work, please do so in drivers/staging/ as it is most welcome there if you wish to get involved in kernel work to get experience before doing "real" stuff. thanks, g reg k-h

2 1

[PATCH 0/5] Use pm_runtime_resume_and_get()
by Tian Tao 20 May '21

20 May '21

patch#1,#2,#3,#4,#5 use pm_runtime_resume_and_get() to replace pm_runtime_get_sync and pm_runtime_put_noidle. This change is just to simplify the code, no actual functional changes. Tian Tao (5): spi: Use pm_runtime_resume_and_get() to replace open coding spi: spi-mem: Use pm_runtime_resume_and_get() to replace open coding spi: imx: Use pm_runtime_resume_and_get() to replace open coding spi: spi-ti-qspi: Use pm_runtime_resume_and_get() to replace open coding spi: sprd: Use pm_runtime_resume_and_get() to replace open coding drivers/spi/spi-imx.c | 6 ++---- drivers/spi/spi-mem.c | 3 +-- drivers/spi/spi-sprd.c | 3 +-- drivers/spi/spi-ti-qspi.c | 3 +-- drivers/spi/spi.c | 9 +++------ 5 files changed, 8 insertions(+), 16 deletions(-) -- 2.7.4

2 9

[PATCH] spi: Use pm_runtime_resume_and_get() to replace open coding
by Tian Tao 20 May '21

20 May '21

Found using coccicheck script under review at: https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/ Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- drivers/spi/spi.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 57120de..2664b4a 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -1486,9 +1486,8 @@ static void __spi_pump_messages(struct spi_controller *ctlr, bool in_kthread) mutex_lock(&ctlr->io_mutex); if (!was_busy && ctlr->auto_runtime_pm) { - ret = pm_runtime_get_sync(ctlr->dev.parent); + ret = pm_runtime_resume_and_get(ctlr->dev.parent); if (ret < 0) { - pm_runtime_put_noidle(ctlr->dev.parent); dev_err(&ctlr->dev, "Failed to power device: %d\n", ret); mutex_unlock(&ctlr->io_mutex); @@ -3426,10 +3425,9 @@ int spi_setup(struct spi_device *spi) } if (spi->controller->auto_runtime_pm && spi->controller->set_cs) { - status = pm_runtime_get_sync(spi->controller->dev.parent); + status = pm_runtime_resume_and_get(spi->controller->dev.parent); if (status < 0) { mutex_unlock(&spi->controller->io_mutex); - pm_runtime_put_noidle(spi->controller->dev.parent); dev_err(&spi->controller->dev, "Failed to power device: %d\n", status); return status; @@ -3491,10 +3489,9 @@ int spi_set_cs_timing(struct spi_device *spi, struct spi_delay *setup, mutex_lock(&spi->controller->io_mutex); if (spi->controller->auto_runtime_pm) { - status = pm_runtime_get_sync(parent); + status = pm_runtime_resume_and_get(parent); if (status < 0) { mutex_unlock(&spi->controller->io_mutex); - pm_runtime_put_noidle(parent); dev_err(&spi->controller->dev, "Failed to power device: %d\n", status); return status; -- 2.7.4

2 1

[RFC 1/1] kernfs: Remove the limit of pagesize in the read of sysfs
by Tian Tao 20 May '21

20 May '21

Currently we use sysfs to display cpu topology, but when the number of cpus is very large, it may exceed a pagesize, so here we remove the pagesize limit from the read function first. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- fs/kernfs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c index c757193..da25e94 100644 --- a/fs/kernfs/file.c +++ b/fs/kernfs/file.c @@ -184,7 +184,7 @@ static const struct seq_operations kernfs_seq_ops = { static ssize_t kernfs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter) { struct kernfs_open_file *of = kernfs_of(iocb->ki_filp); - ssize_t len = min_t(size_t, iov_iter_count(iter), PAGE_SIZE); + ssize_t len = iov_iter_count(iter); const struct kernfs_ops *ops; char *buf; -- 2.7.4

1 0

[PATCH v2] topology: use bin_attribute to avoid buff overflow
by Tian Tao 19 May '21

19 May '21

Use bin_attribute to display thread_siblings/core_cpus/core_siblings, die_cpus/package_cpus/book_siblings/drawer_siblings,avoiding NR_CPUS too big to cause buff overflow. This patch is based on the following discussion. https://www.spinics.net/lists/linux-doc/msg95921.html Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- v2: rewrite the function name##_read --- drivers/base/topology.c | 57 ++++++++++++++++++++++++++++++++----------------- 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..1b74ff5 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -14,6 +14,8 @@ #include <linux/hardirq.h> #include <linux/topology.h> +#define BUFF_SIZE ((NR_CPUS/32)*9) + #define define_id_show_func(name) \ static ssize_t name##_show(struct device *dev, \ struct device_attribute *attr, char *buf) \ @@ -21,11 +23,16 @@ static ssize_t name##_show(struct device *dev, \ return sysfs_emit(buf, "%d\n", topology_##name(dev->id)); \ } -#define define_siblings_show_map(name, mask) \ -static ssize_t name##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - return cpumap_print_to_pagebuf(false, buf, topology_##mask(dev->id));\ +#define define_siblings_read(name, mask) \ +static ssize_t name##_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + char temp[BUFF_SIZE] = {0}; \ + scnprintf(temp, BUFF_SIZE, "%*pb\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + return memory_read_from_buffer(buf, count, &off, temp, BUFF_SIZE); \ } #define define_siblings_show_list(name, mask) \ @@ -37,7 +44,7 @@ static ssize_t name##_list_show(struct device *dev, \ } #define define_siblings_show_func(name, mask) \ - define_siblings_show_map(name, mask); \ + define_siblings_read(name, mask); \ define_siblings_show_list(name, mask) define_id_show_func(physical_package_id); @@ -50,30 +57,30 @@ define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); define_siblings_show_func(thread_siblings, sibling_cpumask); -static DEVICE_ATTR_RO(thread_siblings); +static BIN_ATTR_RO(thread_siblings, 0); static DEVICE_ATTR_RO(thread_siblings_list); define_siblings_show_func(core_cpus, sibling_cpumask); -static DEVICE_ATTR_RO(core_cpus); +static BIN_ATTR_RO(core_cpus, 0); static DEVICE_ATTR_RO(core_cpus_list); define_siblings_show_func(core_siblings, core_cpumask); -static DEVICE_ATTR_RO(core_siblings); +static BIN_ATTR_RO(core_siblings, 0); static DEVICE_ATTR_RO(core_siblings_list); define_siblings_show_func(die_cpus, die_cpumask); -static DEVICE_ATTR_RO(die_cpus); +static BIN_ATTR_RO(die_cpus, 0); static DEVICE_ATTR_RO(die_cpus_list); define_siblings_show_func(package_cpus, core_cpumask); -static DEVICE_ATTR_RO(package_cpus); +static BIN_ATTR_RO(package_cpus, 0); static DEVICE_ATTR_RO(package_cpus_list); #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); define_siblings_show_func(book_siblings, book_cpumask); -static DEVICE_ATTR_RO(book_siblings); +static BIN_ATTR_RO(book_siblings, 0); static DEVICE_ATTR_RO(book_siblings_list); #endif @@ -81,32 +88,41 @@ static DEVICE_ATTR_RO(book_siblings_list); define_id_show_func(drawer_id); static DEVICE_ATTR_RO(drawer_id); define_siblings_show_func(drawer_siblings, drawer_cpumask); -static DEVICE_ATTR_RO(drawer_siblings); +static BIN_ATTR_RO(drawer_siblings, 0); static DEVICE_ATTR_RO(drawer_siblings_list); #endif + +static struct bin_attribute *bin_attrs[] = { + &bin_attr_thread_siblings, + &bin_attr_core_cpus, + &bin_attr_core_siblings, + &bin_attr_die_cpus, + &bin_attr_package_cpus, +#ifdef CONFIG_SCHED_BOOK + &bin_attr_book_siblings, +#endif +#ifdef CONFIG_SCHED_DRAWER + &bin_attr_drawer_siblings, +#endif + NULL, +}; + static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, &dev_attr_core_id.attr, - &dev_attr_thread_siblings.attr, &dev_attr_thread_siblings_list.attr, - &dev_attr_core_cpus.attr, &dev_attr_core_cpus_list.attr, - &dev_attr_core_siblings.attr, &dev_attr_core_siblings_list.attr, - &dev_attr_die_cpus.attr, &dev_attr_die_cpus_list.attr, - &dev_attr_package_cpus.attr, &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, - &dev_attr_book_siblings.attr, &dev_attr_book_siblings_list.attr, #endif #ifdef CONFIG_SCHED_DRAWER &dev_attr_drawer_id.attr, - &dev_attr_drawer_siblings.attr, &dev_attr_drawer_siblings_list.attr, #endif NULL @@ -114,6 +130,7 @@ static struct attribute *default_attrs[] = { static const struct attribute_group topology_attr_group = { .attrs = default_attrs, + .bin_attrs = bin_attrs, .name = "topology" }; -- 2.7.4

2 1

Re: [RFC PATCH v2 5/6] hw/arm/virt-acpi-build: Add PPTT table
by Salil Mehta 19 May '21

19 May '21

> From: Qemu-arm [mailto:qemu-arm-bounces+salil.mehta=huawei.com@nongnu.org] > On Behalf Of wangyanan (Y) > Sent: Thursday, May 13, 2021 6:10 AM > > Hi Drew, > > I got a question below, and hope your reply. Thanks! > On 2021/4/13 16:07, Yanan Wang wrote: > > Add the Processor Properties Topology Table (PPTT) to present > > CPU topology information to ACPI guests. Note, while a DT boot > > Linux guest with a non-flat CPU topology will see socket and > > core IDs being sequential integers starting from zero, e.g. > > with -smp 4,sockets=2,cores=2,threads=1 > > > > a DT boot produces > > > > cpu: 0 package_id: 0 core_id: 0 > > cpu: 1 package_id: 0 core_id: 1 > > cpu: 2 package_id: 1 core_id: 0 > > cpu: 3 package_id: 1 core_id: 1 > > > > an ACPI boot produces > > > > cpu: 0 package_id: 36 core_id: 0 > > cpu: 1 package_id: 36 core_id: 1 > > cpu: 2 package_id: 96 core_id: 2 > > cpu: 3 package_id: 96 core_id: 3 > > > > This is due to several reasons: > > > > 1) DT cpu nodes do not have an equivalent field to what the PPTT > > ACPI Processor ID must be, i.e. something equal to the MADT CPU > > UID or equal to the UID of an ACPI processor container. In both > > ACPI cases those are platform dependant IDs assigned by the > > vendor. > > > > 2) While QEMU is the vendor for a guest, if the topology specifies > > SMT (> 1 thread), then, with ACPI, it is impossible to assign a > > core-id the same value as a package-id, thus it is not possible > > to have package-id=0 and core-id=0. This is because package and > > core containers must be in the same ACPI namespace and therefore > > must have unique UIDs. > > > > 3) ACPI processor containers are not required for PPTT tables to > > be used and, due to the limitations of which IDs are selected > > described above in (2), they are not helpful for QEMU, so we > > don't build them with this patch. In the absence of them, Linux > > assigns its own unique IDs. The maintainers have chosen not to use > > counters from zero, but rather ACPI table offsets, which explains > > why the numbers are so much larger than with DT. > > > > 4) When there is no SMT (threads=1) the core IDs for ACPI boot guests > > match the logical CPU IDs, because these IDs must be equal to the > > MADT CPU UID (as no processor containers are present), and QEMU > > uses the logical CPU ID for these MADT IDs. > > > > Tested-by: Jiajie Li <lijiajie11(a)huawei.com> > > Signed-off-by: Andrew Jones <drjones(a)redhat.com> > > Signed-off-by: Ying Fang <fangying1(a)huawei.com> > > Signed-off-by: Yanan Wang <wangyanan55(a)huawei.com> > > --- > > hw/arm/virt-acpi-build.c | 63 ++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 63 insertions(+) > > > > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c > > index 2ad5dad1bf..03fd812d5a 100644 > > --- a/hw/arm/virt-acpi-build.c > > +++ b/hw/arm/virt-acpi-build.c > > @@ -436,6 +436,64 @@ build_srat(GArray *table_data, BIOSLinker *linker, > VirtMachineState *vms) > > vms->oem_table_id); > > } > > > > +/* PPTT */ > > +static void > > +build_pptt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) > > +{ > > + int pptt_start = table_data->len; > > + int uid = 0, cpus = 0, socket = 0; > > + MachineState *ms = MACHINE(vms); > > + unsigned int smp_cores = ms->smp.cores; > > + unsigned int smp_threads = ms->smp.threads; > > + > > + acpi_data_push(table_data, sizeof(AcpiTableHeader)); > > + > > + for (socket = 0; cpus < ms->possible_cpus->len; socket++) { > > + uint32_t socket_offset = table_data->len - pptt_start; > > + int core; > > + > > + build_processor_hierarchy_node( > > + table_data, 1, /* Physical package */ > > + 0, socket, /* No parent */ > > + NULL, 0); /* No private resources */ > > + > > + for (core = 0; core < smp_cores; core++) { > > + uint32_t core_offset = table_data->len - pptt_start; > > + int thread; > > + > > + if (smp_threads <= 1) { > > + build_processor_hierarchy_node( > > + table_data, > > + (1 << 1) | /* ACPI Processor ID valid */ > > + (1 << 3), /* ACPI 6.3 - Node is a Leaf */ > > + socket_offset, uid++, /* Parent is a Socket */ > > + NULL, 0); /* No private resources */ > > + } else { > > + build_processor_hierarchy_node( > > + table_data, 0, > > + socket_offset, core, /* Parent is a Socket */ > > + NULL, 0); /* No private resources */ > > + > > + for (thread = 0; thread < smp_threads; thread++) { > > + build_processor_hierarchy_node( > > + table_data, > > + (1 << 1) | /* ACPI Processor ID valid */ > > + (1 << 2) | /* ACPI 6.3 - Processor is a Thread */ > > + (1 << 3), /* ACPI 6.3 - Node is a Leaf */ > > + core_offset, uid++, /* Parent is a Core */ > > + NULL, 0); /* No private resources */ > > + } > > + } > > + } > > + cpus += smp_cores * smp_threads; > > + } > > + > > + build_header(linker, table_data, > > + (void *)(table_data->data + pptt_start), "PPTT", > > + table_data->len - pptt_start, 2, > > + vms->oem_id, vms->oem_table_id); > > +} > > + > > /* GTDT */ > > static void > > build_gtdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) > > @@ -707,6 +765,11 @@ void virt_acpi_build(VirtMachineState *vms, > AcpiBuildTables *tables) > > acpi_add_table(table_offsets, tables_blob); > > build_madt(tables_blob, tables->linker, vms); > > > > + if (ms->smp.cpus > 1 && !vmc->no_cpu_topology) { > I'm not really sure why we need to care about "ms->smp.cpus > 1" here? > > IMO, just like MADT in which we create both ENABLED and DISABLED > gicc nodes no matter of number of ENABLED nodes is one or not, we > should create PPTT table for all the possible cpus and not care about > number of smp cpus, too. This will be more consistent with the ACPI > specification and the PPTT table will be used for ACPI cpu hotplug in > the future even with "smp.cpus == 1". A humble request: Let us not anticipate the changes of vcpu Hotplug here. Things are fluid with respect to the vcpu Hotplug right now and I think it will not be right to base PPTT Table changes in anticipation of something we are not sure of what it looks like. Any such decisions should be postponed and be made part of the actual vcpu Hotplug changes when(and if ever) they come for ARM64. This will also ensure proper review of such changes and useful in that particular context. Thanks > > Care of "smp.cpus > 1" in the DT cpu-map part makes sense to me, > because we are required to only add present cpu nodes to the DT and > Linux Doc says that a cpu-map is not needed for uniprocessor systems. > > Thanks, > Yanan > > + acpi_add_table(table_offsets, tables_blob); > > + build_pptt(tables_blob, tables->linker, vms); > > + } > > + > > acpi_add_table(table_offsets, tables_blob); > > build_gtdt(tables_blob, tables->linker, vms); > >

3 13

[PATCH] topology: use bin_attribute to avoid buff overflow
by Tian Tao 19 May '21

19 May '21

Use bin_attribute to display thread_siblings/core_cpus/core_siblings, die_cpus/package_cpus/book_siblings/drawer_siblings,avoiding NR_CPUS too big to cause buff overflow. This patch is based on the following discussion. https://www.spinics.net/lists/linux-doc/msg95921.html Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- drivers/base/topology.c | 54 +++++++++++++++++++++++++++++++------------------ 1 file changed, 34 insertions(+), 20 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..be589b6b 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -21,11 +21,15 @@ static ssize_t name##_show(struct device *dev, \ return sysfs_emit(buf, "%d\n", topology_##name(dev->id)); \ } -#define define_siblings_show_map(name, mask) \ -static ssize_t name##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - return cpumap_print_to_pagebuf(false, buf, topology_##mask(dev->id));\ +#define define_siblings_read(name, mask) \ +static ssize_t name##_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + char temp[(NR_CPUS/32)*9] = {0}; \ + cpumap_print_to_pagebuf(false, temp, topology_##mask(dev->id)); \ + return memory_read_from_buffer(buf, count, &off, temp, (NR_CPUS/32)*9); \ } #define define_siblings_show_list(name, mask) \ @@ -37,7 +41,7 @@ static ssize_t name##_list_show(struct device *dev, \ } #define define_siblings_show_func(name, mask) \ - define_siblings_show_map(name, mask); \ + define_siblings_read(name, mask); \ define_siblings_show_list(name, mask) define_id_show_func(physical_package_id); @@ -50,30 +54,30 @@ define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); define_siblings_show_func(thread_siblings, sibling_cpumask); -static DEVICE_ATTR_RO(thread_siblings); +static BIN_ATTR_RO(thread_siblings, 0); static DEVICE_ATTR_RO(thread_siblings_list); define_siblings_show_func(core_cpus, sibling_cpumask); -static DEVICE_ATTR_RO(core_cpus); +static BIN_ATTR_RO(core_cpus, 0); static DEVICE_ATTR_RO(core_cpus_list); define_siblings_show_func(core_siblings, core_cpumask); -static DEVICE_ATTR_RO(core_siblings); +static BIN_ATTR_RO(core_siblings, 0); static DEVICE_ATTR_RO(core_siblings_list); define_siblings_show_func(die_cpus, die_cpumask); -static DEVICE_ATTR_RO(die_cpus); +static BIN_ATTR_RO(die_cpus, 0); static DEVICE_ATTR_RO(die_cpus_list); define_siblings_show_func(package_cpus, core_cpumask); -static DEVICE_ATTR_RO(package_cpus); +static BIN_ATTR_RO(package_cpus, 0); static DEVICE_ATTR_RO(package_cpus_list); #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); define_siblings_show_func(book_siblings, book_cpumask); -static DEVICE_ATTR_RO(book_siblings); +static BIN_ATTR_RO(book_siblings, 0); static DEVICE_ATTR_RO(book_siblings_list); #endif @@ -81,32 +85,41 @@ static DEVICE_ATTR_RO(book_siblings_list); define_id_show_func(drawer_id); static DEVICE_ATTR_RO(drawer_id); define_siblings_show_func(drawer_siblings, drawer_cpumask); -static DEVICE_ATTR_RO(drawer_siblings); +static BIN_ATTR_RO(drawer_siblings, 0); static DEVICE_ATTR_RO(drawer_siblings_list); #endif + +static struct bin_attribute *bin_attrs[] = { + &bin_attr_thread_siblings, + &bin_attr_core_cpus, + &bin_attr_core_siblings, + &bin_attr_die_cpus, + &bin_attr_package_cpus, +#ifdef CONFIG_SCHED_BOOK + &bin_attr_book_siblings, +#endif +#ifdef CONFIG_SCHED_DRAWER + &bin_attr_drawer_siblings, +#endif + NULL, +}; + static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, &dev_attr_core_id.attr, - &dev_attr_thread_siblings.attr, &dev_attr_thread_siblings_list.attr, - &dev_attr_core_cpus.attr, &dev_attr_core_cpus_list.attr, - &dev_attr_core_siblings.attr, &dev_attr_core_siblings_list.attr, - &dev_attr_die_cpus.attr, &dev_attr_die_cpus_list.attr, - &dev_attr_package_cpus.attr, &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, - &dev_attr_book_siblings.attr, &dev_attr_book_siblings_list.attr, #endif #ifdef CONFIG_SCHED_DRAWER &dev_attr_drawer_id.attr, - &dev_attr_drawer_siblings.attr, &dev_attr_drawer_siblings_list.attr, #endif NULL @@ -114,6 +127,7 @@ static struct attribute *default_attrs[] = { static const struct attribute_group topology_attr_group = { .attrs = default_attrs, + .bin_attrs = bin_attrs, .name = "topology" }; -- 2.7.4

1 0

Re: [RFC PATCH v3 4/9] hw/arm/virt: Initialize the present cpu members
by Salil Mehta 19 May '21

19 May '21

> From: wangyanan (Y) > Sent: Tuesday, May 18, 2021 5:43 AM > > Hi Salil, > > On 2021/5/18 4:48, Salil Mehta wrote: > >> From: Qemu-arm > [mailto:qemu-arm-bounces+salil.mehta=huawei.com@nongnu.org] > >> On Behalf Of Yanan Wang > >> Sent: Sunday, May 16, 2021 11:29 AM > >> To: Peter Maydell <peter.maydell(a)linaro.org>; Andrew Jones > >> <drjones(a)redhat.com>; Michael S . Tsirkin <mst(a)redhat.com>; Igor Mammedov > >> <imammedo(a)redhat.com>; Shannon Zhao <shannon.zhaosl(a)gmail.com>; Alistair > >> Francis <alistair.francis(a)wdc.com>; David Gibson > >> <david(a)gibson.dropbear.id.au>; qemu-devel(a)nongnu.org; qemu-arm(a)nongnu.org > >> Cc: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; zhukeqian > >> <zhukeqian1(a)huawei.com>; yangyicong <yangyicong(a)huawei.com>; Zengtao (B) > >> <prime.zeng(a)hisilicon.com>; Wanghaibin (D) <wanghaibin.wang(a)huawei.com>; > >> yuzenghui <yuzenghui(a)huawei.com>; Paolo Bonzini <pbonzini(a)redhat.com>; > >> Philippe Mathieu-Daudé <philmd(a)redhat.com> > >> Subject: [RFC PATCH v3 4/9] hw/arm/virt: Initialize the present cpu members > >> > >> We create and initialize a cpuobj for each present cpu in > >> machvirt_init(). Now we also initialize the cpu member of > >> structure CPUArchId for each present cpu in the function. > > [...] > > > >> qdev_realize(DEVICE(cpuobj), NULL, &error_fatal); > >> + > >> + /* > >> + * As ARM cpu hotplug is not supported yet, we initialize > >> + * the present cpu members here. > >> + */ > >> + machine->possible_cpus->cpus[n].cpu = cpuobj; > > > > when vcpu Hotplug is not supported yet, what necessitates this change now? > > > The initialization will gives a way to determine whether a CPU is > present or not. > At least, for now it will be used when generating ACPI tables, e.g. > DSDT, MADT. > See patch 5 and 6. yes, but why do you require it now as part of the vcpu topology change? As-far-as-i-can-see, PPTT table changes(part of patch 5/9) do not require this change. Change in Patch 5/9 has also been done in anticipation of some future requirement(vcpu Hotplug?). Please correct me here if I am wrong? Thanks

2 2

Re: [RFC PATCH v3 6/9] hw/arm/virt-acpi-build: Use possible cpus in generation of MADT
by Salil Mehta 18 May '21

18 May '21

> From: wangyanan (Y) > Sent: Tuesday, May 18, 2021 6:03 AM > > Hi Salil, > > On 2021/5/18 1:07, Salil Mehta wrote: > >> From: Qemu-arm > [mailto:qemu-arm-bounces+salil.mehta=huawei.com@nongnu.org] > >> On Behalf Of Yanan Wang > >> Sent: Sunday, May 16, 2021 11:29 AM > >> To: Peter Maydell <peter.maydell(a)linaro.org>; Andrew Jones > >> <drjones(a)redhat.com>; Michael S . Tsirkin <mst(a)redhat.com>; Igor Mammedov > >> <imammedo(a)redhat.com>; Shannon Zhao <shannon.zhaosl(a)gmail.com>; Alistair > >> Francis <alistair.francis(a)wdc.com>; David Gibson > >> <david(a)gibson.dropbear.id.au>; qemu-devel(a)nongnu.org; qemu-arm(a)nongnu.org > >> Cc: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; zhukeqian > >> <zhukeqian1(a)huawei.com>; yangyicong <yangyicong(a)huawei.com>; Zengtao (B) > >> <prime.zeng(a)hisilicon.com>; Wanghaibin (D) <wanghaibin.wang(a)huawei.com>; > >> yuzenghui <yuzenghui(a)huawei.com>; Paolo Bonzini <pbonzini(a)redhat.com>; > >> Philippe Mathieu-Daudé <philmd(a)redhat.com> > >> Subject: [RFC PATCH v3 6/9] hw/arm/virt-acpi-build: Use possible cpus in > >> generation of MADT > >> > >> When building ACPI tables regarding CPUs we should always build > >> them for the number of possible CPUs, not the number of present > >> CPUs. So we create gicc nodes in MADT for possible cpus and then > >> ensure only the present CPUs are marked ENABLED. Furthermore, it > >> also needed if we are going to support CPU hotplug in the future. > > Hi Yanan, > > Yes, these changes are part of the QEMU patch-set I floated last year. > > > > Link: https://www.mail-archive.com/qemu-devel@nongnu.org/msg712018.html > Yes, I noticed this. Thanks! > > > > Perhaps I am missing something, but how this patch is related to the vcpu > > topology support? > No related actually. But this patch together with patch 5 aim to provide > complete information (all cpus including enabled and the others) to guest, > which will be more consistent with requirement in ACPI spec. Well, if it is not related to the cpu topology support then this and other similar patches included with the same line of thought should not be part of this patch-set. I am already working with ARM folks in this regard. Thanks > > We don't consider cpu hotplug at all in this patch, but it indeed pave way > for cpu hotplug in the future. > > Thanks, > Yanan > > Thanks > > > >> Co-developed-by: Andrew Jones <drjones(a)redhat.com> > >> Signed-off-by: Andrew Jones <drjones(a)redhat.com> > >> Co-developed-by: Ying Fang <fangying1(a)huawei.com> > >> Signed-off-by: Ying Fang <fangying1(a)huawei.com> > >> Co-developed-by: Yanan Wang <wangyanan55(a)huawei.com> > >> Signed-off-by: Yanan Wang <wangyanan55(a)huawei.com> > >> --- > >> hw/arm/virt-acpi-build.c | 29 +++++++++++++++++++++++++---- > >> 1 file changed, 25 insertions(+), 4 deletions(-) > >> > >> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c > >> index a2d8e87616..4d64aeb865 100644 > >> --- a/hw/arm/virt-acpi-build.c > >> +++ b/hw/arm/virt-acpi-build.c > >> @@ -481,6 +481,9 @@ build_madt(GArray *table_data, BIOSLinker *linker, > >> VirtMachineState *vms) > >> const int *irqmap = vms->irqmap; > >> AcpiMadtGenericDistributor *gicd; > >> AcpiMadtGenericMsiFrame *gic_msi; > >> + MachineClass *mc = MACHINE_GET_CLASS(vms); > >> + const CPUArchIdList *possible_cpus = > >> mc->possible_cpu_arch_ids(MACHINE(vms)); > >> + bool pmu; > >> int i; > >> > >> acpi_data_push(table_data, sizeof(AcpiMultipleApicTable)); > >> @@ -491,11 +494,21 @@ build_madt(GArray *table_data, BIOSLinker *linker, > >> VirtMachineState *vms) > >> gicd->base_address = cpu_to_le64(memmap[VIRT_GIC_DIST].base); > >> gicd->version = vms->gic_version; > >> > >> - for (i = 0; i < MACHINE(vms)->smp.cpus; i++) { > >> + for (i = 0; i < possible_cpus->len; i++) { > >> AcpiMadtGenericCpuInterface *gicc = acpi_data_push(table_data, > >> sizeof(*gicc)); > >> ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(i)); > >> > >> + /* > >> + * PMU should have been either implemented for all CPUs or not, > >> + * so we only get information from the first CPU, which could > >> + * represent the others. > >> + */ > >> + if (i == 0) { > >> + pmu = arm_feature(&armcpu->env, ARM_FEATURE_PMU); > >> + } > >> + assert(!armcpu || arm_feature(&armcpu->env, ARM_FEATURE_PMU) == > pmu); > >> + > >> gicc->type = ACPI_APIC_GENERIC_CPU_INTERFACE; > >> gicc->length = sizeof(*gicc); > >> if (vms->gic_version == 2) { > >> @@ -504,11 +517,19 @@ build_madt(GArray *table_data, BIOSLinker *linker, > >> VirtMachineState *vms) > >> gicc->gicv_base_address = > >> cpu_to_le64(memmap[VIRT_GIC_VCPU].base); > >> } > >> gicc->cpu_interface_number = cpu_to_le32(i); > >> - gicc->arm_mpidr = cpu_to_le64(armcpu->mp_affinity); > >> + gicc->arm_mpidr = cpu_to_le64(possible_cpus->cpus[i].arch_id); > >> gicc->uid = cpu_to_le32(i); > >> - gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED); > >> > >> - if (arm_feature(&armcpu->env, ARM_FEATURE_PMU)) { > >> + /* > >> + * ACPI spec says that LAPIC entry for non present CPU may be > >> + * omitted from MADT or it must be marked as disabled. Here we > >> + * choose to also keep the disabled ones in MADT. > >> + */ > >> + if (possible_cpus->cpus[i].cpu != NULL) { > >> + gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED); > >> + } > >> + > >> + if (pmu) { > >> gicc->performance_interrupt = > cpu_to_le32(PPI(VIRTUAL_PMU_IRQ)); > >> } > >> if (vms->virt) { > >> -- > >> 2.19.1 > >> > > .

2 1

Re: [PATCH v3] iommu/iova: put free_iova_mem() outside of spinlock iova_rbtree_lock
by Joerg Roedel 18 May '21

18 May '21

On Mon, Apr 19, 2021 at 03:13:35PM +0800, chenxiang wrote: > From: Xiang Chen <chenxiang66(a)hisilicon.com> > > It is not necessary to put free_iova_mem() inside of spinlock/unlock > iova_rbtree_lock which only leads to more completion for the spinlock. > It has a small promote on the performance after the change. And also > rename private_free_iova() as remove_iova() because the function will not > free iova after that change. > > Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> > --- > drivers/iommu/iova.c | 18 +++++++++++------- > 1 file changed, 11 insertions(+), 7 deletions(-) Looks good to me, but I'll wait for Robins opinion before applying.

3 3

Re: [RFC PATCH v3 4/4] hw/arm/virt: Parse -smp cluster parameter in virt_smp_parse
by Salil Mehta 18 May '21

18 May '21

> From: wangyanan (Y) > > Hi Salil, > > On 2021/5/17 23:17, Salil Mehta wrote: > >> From: Qemu-devel > >> [mailto:qemu-devel-bounces+salil.mehta=huawei.com@nongnu.org] On Behalf Of > >> Yanan Wang > >> Sent: Sunday, May 16, 2021 11:32 AM > >> To: Peter Maydell <peter.maydell(a)linaro.org>; Paolo Bonzini > >> <pbonzini(a)redhat.com>; Andrew Jones <drjones(a)redhat.com>; Michael S . Tsirkin > >> <mst(a)redhat.com>; Igor Mammedov <imammedo(a)redhat.com>; Shannon Zhao > >> <shannon.zhaosl(a)gmail.com>; qemu-devel(a)nongnu.org; qemu-arm(a)nongnu.org > >> Cc: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; Philippe > >> Mathieu-Daudé <philmd(a)redhat.com>; wangyanan (Y) <wangyanan55(a)huawei.com>; > >> Zengtao (B) <prime.zeng(a)hisilicon.com>; Wanghaibin (D) > >> <wanghaibin.wang(a)huawei.com>; yuzenghui <yuzenghui(a)huawei.com>; yangyicong > >> <yangyicong(a)huawei.com>; zhukeqian <zhukeqian1(a)huawei.com> > >> Subject: [RFC PATCH v3 4/4] hw/arm/virt: Parse -smp cluster parameter in > >> virt_smp_parse > >> > >> There is a separate function virt_smp_parse() in hw/virt/arm.c used > >> to parse cpu topology for the ARM machines. So add parsing of -smp > >> cluster parameter in it, then total number of logical cpus will be > >> calculated like: max_cpus = sockets * clusters * cores * threads. > >> > >> Note, we will assume multi-cluster in one socket is not supported > >> and default the value of clusters to 1, if it's not explicitly > >> specified in -smp cmdline. > >> > >> Signed-off-by: Yanan Wang <wangyanan55(a)huawei.com> > >> --- > >> hw/arm/virt.c | 32 ++++++++++++++++++-------------- > >> 1 file changed, 18 insertions(+), 14 deletions(-) > >> > >> diff --git a/hw/arm/virt.c b/hw/arm/virt.c > >> index 7de822e491..678d5ef36c 100644 > >> --- a/hw/arm/virt.c > >> +++ b/hw/arm/virt.c > >> @@ -2642,8 +2642,8 @@ static int virt_kvm_type(MachineState *ms, const char > >> *type_str) > >> * with the -smp cmdlines when parsing them. > >> * > >> * We require that at least one of cpus or maxcpus must be provided. > >> - * Threads will default to 1 if not provided. Sockets and cores must > >> - * be either both provided or both not. > >> + * Clusters and threads will default to 1 if they are not provided. > >> + * Sockets and cores must be either both provided or both not. > >> * > >> * Note, if neither sockets nor cores are specified, we will calculate > >> * all the missing values just like smp_parse() does, but will disable > >> @@ -2652,15 +2652,18 @@ static int virt_kvm_type(MachineState *ms, const char > >> *type_str) > >> static void virt_smp_parse(MachineState *ms, QemuOpts *opts) > >> { > >> VirtMachineClass *vmc = VIRT_MACHINE_GET_CLASS(ms); > >> + VirtMachineState *vms = VIRT_MACHINE(ms); > >> > >> if (opts) { > >> unsigned cpus = qemu_opt_get_number(opts, "cpus", 0); > >> unsigned maxcpus = qemu_opt_get_number(opts, "maxcpus", 0); > >> unsigned sockets = qemu_opt_get_number(opts, "sockets", 0); > >> + unsigned clusters = qemu_opt_get_number(opts, "clusters", 0); > >> unsigned cores = qemu_opt_get_number(opts, "cores", 0); > >> unsigned threads = qemu_opt_get_number(opts, "threads", 0); > >> > >> - /* Default threads to 1 if not provided */ > >> + /* Default clusters and threads to 1 if not provided */ > >> + clusters = clusters > 0 ? clusters : 1; > >> threads = threads > 0 ? threads : 1; > >> > >> if (cpus == 0 && maxcpus == 0) { > >> @@ -2676,13 +2679,13 @@ static void virt_smp_parse(MachineState *ms, QemuOpts > >> *opts) > >> cores = 1; > >> if (cpus == 0) { > >> sockets = 1; > >> - cpus = sockets * cores * threads; > >> + cpus = sockets * clusters * cores * threads; > >> } else { > >> maxcpus = maxcpus > 0 ? maxcpus : cpus; > >> - sockets = maxcpus / (cores * threads); > >> + sockets = maxcpus / (clusters * cores * threads); > >> } > >> } else if (sockets > 0 && cores > 0) { > >> - cpus = cpus > 0 ? cpus : sockets * cores * threads; > >> + cpus = cpus > 0 ? cpus : sockets * clusters * cores * threads; > >> maxcpus = maxcpus > 0 ? maxcpus : cpus; > >> } else { > >> error_report("sockets and cores must be both provided " > >> @@ -2695,25 +2698,26 @@ static void virt_smp_parse(MachineState *ms, QemuOpts > >> *opts) > >> exit(1); > >> } > >> > >> - if (sockets * cores * threads < cpus) { > >> + if (sockets * clusters * cores * threads < cpus) { > >> error_report("cpu topology: " > >> - "sockets (%u) * cores (%u) * threads (%u) < " > >> - "smp_cpus (%u)", > >> - sockets, cores, threads, cpus); > >> + "sockets (%u) * clusters (%u) * cores (%u) * " > >> + "threads (%u) < smp_cpus (%u)", > >> + sockets, clusters, cores, threads, cpus); > >> exit(1); > >> } > >> > >> - if (sockets * cores * threads != maxcpus) { > >> + if (sockets * clusters * cores * threads != maxcpus) { > >> error_report("cpu topology: " > >> - "sockets (%u) * cores (%u) * threads (%u) " > >> - "!= maxcpus (%u)", > >> - sockets, cores, threads, maxcpus); > >> + "sockets (%u) * clusters (%u) * cores (%u) * " > >> + "threads (%u) != maxcpus (%u)", > >> + sockets, clusters, cores, threads, maxcpus); > >> exit(1); > >> } > >> > >> ms->smp.cpus = cpus; > >> ms->smp.max_cpus = maxcpus; > >> ms->smp.sockets = sockets; > >> + vms->smp_clusters = clusters; > > > > This variable naming *smp_clusters* looks out-of-sorts. I thought a similar > > variable *smp_cpus* was destined to be removed for the reason given in below > > link - a patch by Andrew Jones? > > > > Link: https://lists.gnu.org/archive/html/qemu-arm/2020-12/msg00418.html > > > > Am I missing anything here? > The smp_clusters is added in VirtMachineState and nowhere else because > it's currently only used for ARM. But I think maybe I should also move it to > CpuTopology structure like [1] is doing to move dies to CpuTopology. yes, that’s the idea. It is always good to have right place holders so that the code comprehension/usage(in this case) becomes easy and obvious. > > Move clusters to CpuTopology won't affect other architectures that don't > support it yet, and will also make it easy if they want to in the future. > > [1] From Paolo: > https://patchwork.kernel.org/project/qemu-devel/patch/20210513162901.131023 > 9-10-pbonzini(a)redhat.com/ sure. > > Thanks, > Yanan > > Salil. > > > >> ms->smp.cores = cores; > >> ms->smp.threads = threads; > >> }

1 0

Re: [PATCH net v8 1/3] net: sched: fix packet stuck problem for lockless qdisc
by Cong Wang 18 May '21

18 May '21

On Fri, May 14, 2021 at 7:25 PM Yunsheng Lin <linyunsheng(a)huawei.com> wrote: > > On 2021/5/15 8:17, Jakub Kicinski wrote: > > On Fri, 14 May 2021 16:57:29 -0700 Cong Wang wrote: > >> On Fri, May 14, 2021 at 4:39 PM Jakub Kicinski <kuba(a)kernel.org> wrote: > >>> > >>> On Fri, 14 May 2021 16:36:16 -0700 Cong Wang wrote: > >> [...] > >>>> > >>>> We have test_and_clear_bit() which is atomic, test_bit()+clear_bit() > >>>> is not. > >>> > >>> It doesn't have to be atomic, right? I asked to split the test because > >>> test_and_clear is a locked op on x86, test by itself is not. > >> > >> It depends on whether you expect the code under the true condition > >> to run once or multiple times, something like: > >> > >> if (test_bit()) { > >> clear_bit(); > >> // this code may run multiple times > >> } > >> > >> With the atomic test_and_clear_bit(), it only runs once: > >> > >> if (test_and_clear_bit()) { > >> // this code runs once > >> } > > I am not sure if the above really matter when the test and clear > does not need to be atomic. > > In order for the above to happens, the MISSED has to set between > test and clear, right? Nope, see the following: // MISSED bit is already set CPU0 CPU1 if (test_bit(MISSED) ( //true if (test_bit(MISSED)) { // also true clear_bit(MISSED); do_something(); clear_bit(MISSED); do_something(); } } Now do_something() is called twice instead of once. This may or may not be a problem, hence I asked this question. > > >> > >> This is why __netif_schedule() uses test_and_set_bit() instead of > >> test_bit()+set_bit(). > > I think test_and_set_bit() is needed in __netif_schedule() mainly > because STATE_SCHED is also used to indicate if the qdisc is in > sd->output_queue, so it has to be atomic. If you replace the "do_something()" above with __netif_reschedule(), this is exactly my point. An entry can not be inserted twice into a list, hence it should never be called twice like above. Thanks.

1 0

Re: [RFC PATCH v3 6/9] hw/arm/virt-acpi-build: Use possible cpus in generation of MADT
by Salil Mehta 18 May '21

18 May '21

> From: Qemu-arm [mailto:qemu-arm-bounces+salil.mehta=huawei.com@nongnu.org] > On Behalf Of Yanan Wang > Sent: Sunday, May 16, 2021 11:29 AM > To: Peter Maydell <peter.maydell(a)linaro.org>; Andrew Jones > <drjones(a)redhat.com>; Michael S . Tsirkin <mst(a)redhat.com>; Igor Mammedov > <imammedo(a)redhat.com>; Shannon Zhao <shannon.zhaosl(a)gmail.com>; Alistair > Francis <alistair.francis(a)wdc.com>; David Gibson > <david(a)gibson.dropbear.id.au>; qemu-devel(a)nongnu.org; qemu-arm(a)nongnu.org > Cc: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; zhukeqian > <zhukeqian1(a)huawei.com>; yangyicong <yangyicong(a)huawei.com>; Zengtao (B) > <prime.zeng(a)hisilicon.com>; Wanghaibin (D) <wanghaibin.wang(a)huawei.com>; > yuzenghui <yuzenghui(a)huawei.com>; Paolo Bonzini <pbonzini(a)redhat.com>; > Philippe Mathieu-Daudé <philmd(a)redhat.com> > Subject: [RFC PATCH v3 6/9] hw/arm/virt-acpi-build: Use possible cpus in > generation of MADT > > When building ACPI tables regarding CPUs we should always build > them for the number of possible CPUs, not the number of present > CPUs. So we create gicc nodes in MADT for possible cpus and then > ensure only the present CPUs are marked ENABLED. Furthermore, it > also needed if we are going to support CPU hotplug in the future. Hi Yanan, Yes, these changes are part of the QEMU patch-set I floated last year. Link: https://www.mail-archive.com/qemu-devel@nongnu.org/msg712018.html Perhaps I am missing something, but how this patch is related to the vcpu topology support? Thanks > > Co-developed-by: Andrew Jones <drjones(a)redhat.com> > Signed-off-by: Andrew Jones <drjones(a)redhat.com> > Co-developed-by: Ying Fang <fangying1(a)huawei.com> > Signed-off-by: Ying Fang <fangying1(a)huawei.com> > Co-developed-by: Yanan Wang <wangyanan55(a)huawei.com> > Signed-off-by: Yanan Wang <wangyanan55(a)huawei.com> > --- > hw/arm/virt-acpi-build.c | 29 +++++++++++++++++++++++++---- > 1 file changed, 25 insertions(+), 4 deletions(-) > > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c > index a2d8e87616..4d64aeb865 100644 > --- a/hw/arm/virt-acpi-build.c > +++ b/hw/arm/virt-acpi-build.c > @@ -481,6 +481,9 @@ build_madt(GArray *table_data, BIOSLinker *linker, > VirtMachineState *vms) > const int *irqmap = vms->irqmap; > AcpiMadtGenericDistributor *gicd; > AcpiMadtGenericMsiFrame *gic_msi; > + MachineClass *mc = MACHINE_GET_CLASS(vms); > + const CPUArchIdList *possible_cpus = > mc->possible_cpu_arch_ids(MACHINE(vms)); > + bool pmu; > int i; > > acpi_data_push(table_data, sizeof(AcpiMultipleApicTable)); > @@ -491,11 +494,21 @@ build_madt(GArray *table_data, BIOSLinker *linker, > VirtMachineState *vms) > gicd->base_address = cpu_to_le64(memmap[VIRT_GIC_DIST].base); > gicd->version = vms->gic_version; > > - for (i = 0; i < MACHINE(vms)->smp.cpus; i++) { > + for (i = 0; i < possible_cpus->len; i++) { > AcpiMadtGenericCpuInterface *gicc = acpi_data_push(table_data, > sizeof(*gicc)); > ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(i)); > > + /* > + * PMU should have been either implemented for all CPUs or not, > + * so we only get information from the first CPU, which could > + * represent the others. > + */ > + if (i == 0) { > + pmu = arm_feature(&armcpu->env, ARM_FEATURE_PMU); > + } > + assert(!armcpu || arm_feature(&armcpu->env, ARM_FEATURE_PMU) == pmu); > + > gicc->type = ACPI_APIC_GENERIC_CPU_INTERFACE; > gicc->length = sizeof(*gicc); > if (vms->gic_version == 2) { > @@ -504,11 +517,19 @@ build_madt(GArray *table_data, BIOSLinker *linker, > VirtMachineState *vms) > gicc->gicv_base_address = > cpu_to_le64(memmap[VIRT_GIC_VCPU].base); > } > gicc->cpu_interface_number = cpu_to_le32(i); > - gicc->arm_mpidr = cpu_to_le64(armcpu->mp_affinity); > + gicc->arm_mpidr = cpu_to_le64(possible_cpus->cpus[i].arch_id); > gicc->uid = cpu_to_le32(i); > - gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED); > > - if (arm_feature(&armcpu->env, ARM_FEATURE_PMU)) { > + /* > + * ACPI spec says that LAPIC entry for non present CPU may be > + * omitted from MADT or it must be marked as disabled. Here we > + * choose to also keep the disabled ones in MADT. > + */ > + if (possible_cpus->cpus[i].cpu != NULL) { > + gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED); > + } > + > + if (pmu) { > gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ)); > } > if (vms->virt) { > -- > 2.19.1 >

1 0

Re: [RFC PATCH v3 4/4] hw/arm/virt: Parse -smp cluster parameter in virt_smp_parse
by Salil Mehta 17 May '21

17 May '21

> From: Qemu-devel > [mailto:qemu-devel-bounces+salil.mehta=huawei.com@nongnu.org] On Behalf Of > Yanan Wang > Sent: Sunday, May 16, 2021 11:32 AM > To: Peter Maydell <peter.maydell(a)linaro.org>; Paolo Bonzini > <pbonzini(a)redhat.com>; Andrew Jones <drjones(a)redhat.com>; Michael S . Tsirkin > <mst(a)redhat.com>; Igor Mammedov <imammedo(a)redhat.com>; Shannon Zhao > <shannon.zhaosl(a)gmail.com>; qemu-devel(a)nongnu.org; qemu-arm(a)nongnu.org > Cc: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; Philippe > Mathieu-Daudé <philmd(a)redhat.com>; wangyanan (Y) <wangyanan55(a)huawei.com>; > Zengtao (B) <prime.zeng(a)hisilicon.com>; Wanghaibin (D) > <wanghaibin.wang(a)huawei.com>; yuzenghui <yuzenghui(a)huawei.com>; yangyicong > <yangyicong(a)huawei.com>; zhukeqian <zhukeqian1(a)huawei.com> > Subject: [RFC PATCH v3 4/4] hw/arm/virt: Parse -smp cluster parameter in > virt_smp_parse > > There is a separate function virt_smp_parse() in hw/virt/arm.c used > to parse cpu topology for the ARM machines. So add parsing of -smp > cluster parameter in it, then total number of logical cpus will be > calculated like: max_cpus = sockets * clusters * cores * threads. > > Note, we will assume multi-cluster in one socket is not supported > and default the value of clusters to 1, if it's not explicitly > specified in -smp cmdline. > > Signed-off-by: Yanan Wang <wangyanan55(a)huawei.com> > --- > hw/arm/virt.c | 32 ++++++++++++++++++-------------- > 1 file changed, 18 insertions(+), 14 deletions(-) > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c > index 7de822e491..678d5ef36c 100644 > --- a/hw/arm/virt.c > +++ b/hw/arm/virt.c > @@ -2642,8 +2642,8 @@ static int virt_kvm_type(MachineState *ms, const char > *type_str) > * with the -smp cmdlines when parsing them. > * > * We require that at least one of cpus or maxcpus must be provided. > - * Threads will default to 1 if not provided. Sockets and cores must > - * be either both provided or both not. > + * Clusters and threads will default to 1 if they are not provided. > + * Sockets and cores must be either both provided or both not. > * > * Note, if neither sockets nor cores are specified, we will calculate > * all the missing values just like smp_parse() does, but will disable > @@ -2652,15 +2652,18 @@ static int virt_kvm_type(MachineState *ms, const char > *type_str) > static void virt_smp_parse(MachineState *ms, QemuOpts *opts) > { > VirtMachineClass *vmc = VIRT_MACHINE_GET_CLASS(ms); > + VirtMachineState *vms = VIRT_MACHINE(ms); > > if (opts) { > unsigned cpus = qemu_opt_get_number(opts, "cpus", 0); > unsigned maxcpus = qemu_opt_get_number(opts, "maxcpus", 0); > unsigned sockets = qemu_opt_get_number(opts, "sockets", 0); > + unsigned clusters = qemu_opt_get_number(opts, "clusters", 0); > unsigned cores = qemu_opt_get_number(opts, "cores", 0); > unsigned threads = qemu_opt_get_number(opts, "threads", 0); > > - /* Default threads to 1 if not provided */ > + /* Default clusters and threads to 1 if not provided */ > + clusters = clusters > 0 ? clusters : 1; > threads = threads > 0 ? threads : 1; > > if (cpus == 0 && maxcpus == 0) { > @@ -2676,13 +2679,13 @@ static void virt_smp_parse(MachineState *ms, QemuOpts > *opts) > cores = 1; > if (cpus == 0) { > sockets = 1; > - cpus = sockets * cores * threads; > + cpus = sockets * clusters * cores * threads; > } else { > maxcpus = maxcpus > 0 ? maxcpus : cpus; > - sockets = maxcpus / (cores * threads); > + sockets = maxcpus / (clusters * cores * threads); > } > } else if (sockets > 0 && cores > 0) { > - cpus = cpus > 0 ? cpus : sockets * cores * threads; > + cpus = cpus > 0 ? cpus : sockets * clusters * cores * threads; > maxcpus = maxcpus > 0 ? maxcpus : cpus; > } else { > error_report("sockets and cores must be both provided " > @@ -2695,25 +2698,26 @@ static void virt_smp_parse(MachineState *ms, QemuOpts > *opts) > exit(1); > } > > - if (sockets * cores * threads < cpus) { > + if (sockets * clusters * cores * threads < cpus) { > error_report("cpu topology: " > - "sockets (%u) * cores (%u) * threads (%u) < " > - "smp_cpus (%u)", > - sockets, cores, threads, cpus); > + "sockets (%u) * clusters (%u) * cores (%u) * " > + "threads (%u) < smp_cpus (%u)", > + sockets, clusters, cores, threads, cpus); > exit(1); > } > > - if (sockets * cores * threads != maxcpus) { > + if (sockets * clusters * cores * threads != maxcpus) { > error_report("cpu topology: " > - "sockets (%u) * cores (%u) * threads (%u) " > - "!= maxcpus (%u)", > - sockets, cores, threads, maxcpus); > + "sockets (%u) * clusters (%u) * cores (%u) * " > + "threads (%u) != maxcpus (%u)", > + sockets, clusters, cores, threads, maxcpus); > exit(1); > } > > ms->smp.cpus = cpus; > ms->smp.max_cpus = maxcpus; > ms->smp.sockets = sockets; > + vms->smp_clusters = clusters; This variable naming *smp_clusters* looks out-of-sorts. I thought a similar variable *smp_cpus* was destined to be removed for the reason given in below link - a patch by Andrew Jones? Link: https://lists.gnu.org/archive/html/qemu-arm/2020-12/msg00418.html Am I missing anything here? Salil. > ms->smp.cores = cores; > ms->smp.threads = threads; > }

1 0

[PATCH 8/9] tty: hvc_console: Remove the repeated words 'no' and 'from'
by Xiaofei Tan 17 May '21

17 May '21

Remove the repeated words 'no' and 'from', reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index f31efeb..b6720b0 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -293,7 +293,7 @@ int hvc_instantiate(uint32_t vtermno, int index, const struct hv_ops *ops) if (vtermnos[index] != -1) return -1; - /* make sure no no tty has been registered in this index */ + /* make sure no tty has been registered in this index */ hp = hvc_get_by_index(index); if (hp) { tty_port_put(&hp->port); @@ -622,7 +622,7 @@ static u32 timeout = MIN_TIMEOUT; /* * Maximum number of bytes to get from the console driver if hvc_poll is * called from driver (and can't sleep). Any more than this and we break - * and start polling with khvcd. This value was derived from from an OpenBMC + * and start polling with khvcd. This value was derived from an OpenBMC * console with the OPAL driver that results in about 0.25ms interrupts off * latency. */ -- 2.8.1

1 0

[PATCH 7/9] tty: hvc_console: Add a blank line after declarations
by Xiaofei Tan 17 May '21

17 May '21

Add a blank line after declarations, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index a61cdf0..f31efeb 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -922,6 +922,7 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data, /* We wait until a driver actually comes along */ if (atomic_inc_not_zero(&hvc_needs_init)) { int err = hvc_init(); + if (err) return ERR_PTR(err); } -- 2.8.1

1 0

[PATCH 5/9] tty: hvc_console: Delete spaces prohibited around open parenthesis '(' and ')'
by Xiaofei Tan 17 May '21

17 May '21

Delete spaces prohibited after that open parenthesis '(' and before that close parenthesis ')', reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index 2e5c133..39018e5 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -689,7 +689,7 @@ static int __hvc_poll(struct hvc_struct *hp, bool may_sleep) spin_unlock_irqrestore(&hp->lock, flags); tty_hangup(tty); spin_lock_irqsave(&hp->lock, flags); - } else if ( n == -EAGAIN ) { + } else if (n == -EAGAIN) { /* * Some back-ends can only ensure a certain min * num of bytes read, which may be > 'count'. -- 2.8.1

1 0

[PATCH 3/9] tty: hvc_console: Remove trailing whitespace
by Xiaofei Tan 17 May '21

17 May '21

Remove trailing whitespace, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index ddf07ff..13f63d5 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -204,7 +204,7 @@ static struct tty_driver *hvc_console_device(struct console *c, int *index) } static int hvc_console_setup(struct console *co, char *options) -{ +{ if (co->index < 0 || co->index >= MAX_NR_HVC_CONSOLES) return -ENODEV; -- 2.8.1

1 0

[PATCH 2/9] tty: hvc_console: Fix "foo * bar" should be "foo *bar"
by Xiaofei Tan 17 May '21

17 May '21

Fix "foo * bar" should be "foo *bar", reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index a1eca9d..ddf07ff 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -344,7 +344,7 @@ static int hvc_install(struct tty_driver *driver, struct tty_struct *tty) * The TTY interface won't be used until after the vio layer has exposed the vty * adapter to the kernel. */ -static int hvc_open(struct tty_struct *tty, struct file * filp) +static int hvc_open(struct tty_struct *tty, struct file *filp) { struct hvc_struct *hp = tty->driver_data; unsigned long flags; @@ -386,7 +386,7 @@ static int hvc_open(struct tty_struct *tty, struct file * filp) return rc; } -static void hvc_close(struct tty_struct *tty, struct file * filp) +static void hvc_close(struct tty_struct *tty, struct file *filp) { struct hvc_struct *hp = tty->driver_data; unsigned long flags; -- 2.8.1

1 0

[PATCH 1/9] tty: hvc_console: Fix spaces required around that '='
by Xiaofei Tan 17 May '21

17 May '21

Fix spaces required around that '=', reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index d0f0253..a1eca9d 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -944,7 +944,7 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data, * find index to use: * see if this vterm id matches one registered for console. */ - for (i=0; i < MAX_NR_HVC_CONSOLES; i++) + for (i = 0; i < MAX_NR_HVC_CONSOLES; i++) if (vtermnos[i] == hp->vtermno && cons_ops[i] == hp->ops) break; -- 2.8.1

1 0

Re: [PATCH net v8 1/3] net: sched: fix packet stuck problem for lockless qdisc
by Cong Wang 15 May '21

15 May '21

On Thu, May 13, 2021 at 7:27 PM Yunsheng Lin <linyunsheng(a)huawei.com> wrote: > struct qdisc_size_table { > @@ -159,8 +160,33 @@ static inline bool qdisc_is_empty(const struct Qdisc *qdisc) > static inline bool qdisc_run_begin(struct Qdisc *qdisc) > { > if (qdisc->flags & TCQ_F_NOLOCK) { > + if (spin_trylock(&qdisc->seqlock)) > + goto nolock_empty; > + > + /* If the MISSED flag is set, it means other thread has > + * set the MISSED flag before second spin_trylock(), so > + * we can return false here to avoid multi cpus doing > + * the set_bit() and second spin_trylock() concurrently. > + */ > + if (test_bit(__QDISC_STATE_MISSED, &qdisc->state)) > + return false; > + > + /* Set the MISSED flag before the second spin_trylock(), > + * if the second spin_trylock() return false, it means > + * other cpu holding the lock will do dequeuing for us > + * or it will see the MISSED flag set after releasing > + * lock and reschedule the net_tx_action() to do the > + * dequeuing. > + */ > + set_bit(__QDISC_STATE_MISSED, &qdisc->state); > + > + /* Retry again in case other CPU may not see the new flag > + * after it releases the lock at the end of qdisc_run_end(). > + */ > if (!spin_trylock(&qdisc->seqlock)) > return false; > + > +nolock_empty: > WRITE_ONCE(qdisc->empty, false); > } else if (qdisc_is_running(qdisc)) { > return false; > @@ -176,8 +202,15 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) > static inline void qdisc_run_end(struct Qdisc *qdisc) > { > write_seqcount_end(&qdisc->running); > - if (qdisc->flags & TCQ_F_NOLOCK) > + if (qdisc->flags & TCQ_F_NOLOCK) { > spin_unlock(&qdisc->seqlock); > + > + if (unlikely(test_bit(__QDISC_STATE_MISSED, > + &qdisc->state))) { > + clear_bit(__QDISC_STATE_MISSED, &qdisc->state); We have test_and_clear_bit() which is atomic, test_bit()+clear_bit() is not. > + __netif_schedule(qdisc); > + } > + } > } > > static inline bool qdisc_may_bulk(const struct Qdisc *qdisc) > diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c > index 44991ea..795d986 100644 > --- a/net/sched/sch_generic.c > +++ b/net/sched/sch_generic.c > @@ -640,8 +640,10 @@ static struct sk_buff *pfifo_fast_dequeue(struct Qdisc *qdisc) > { > struct pfifo_fast_priv *priv = qdisc_priv(qdisc); > struct sk_buff *skb = NULL; > + bool need_retry = true; > int band; > > +retry: > for (band = 0; band < PFIFO_FAST_BANDS && !skb; band++) { > struct skb_array *q = band2list(priv, band); > > @@ -652,6 +654,23 @@ static struct sk_buff *pfifo_fast_dequeue(struct Qdisc *qdisc) > } > if (likely(skb)) { > qdisc_update_stats_at_dequeue(qdisc, skb); > + } else if (need_retry && > + test_bit(__QDISC_STATE_MISSED, &qdisc->state)) { > + /* Delay clearing the STATE_MISSED here to reduce > + * the overhead of the second spin_trylock() in > + * qdisc_run_begin() and __netif_schedule() calling > + * in qdisc_run_end(). > + */ > + clear_bit(__QDISC_STATE_MISSED, &qdisc->state); Ditto. > + > + /* Make sure dequeuing happens after clearing > + * STATE_MISSED. > + */ > + smp_mb__after_atomic(); > + > + need_retry = false; > + > + goto retry; Two concurrent pfifo_fast_dequeue() would possibly retry it at the same time when they test __QDISC_STATE_MISSED at the same time and get true. Is this a problem? Also, any reason why you want pfifo_fast to handle a generic Qdisc flag? IOW, why not handle this logic in, for example, qdisc_restart()? Thanks.

2 3

Re: [PATCH net v8 0/3] fix packet stuck problem for lockless qdisc
by patchwork-bot+netdevbpf＠kernel.org 15 May '21

15 May '21

Hello: This series was applied to netdev/net.git (refs/heads/master): On Fri, 14 May 2021 11:16:58 +0800 you wrote: > This patchset fixes the packet stuck problem mentioned in [1]. > > Patch 1: Add STATE_MISSED flag to fix packet stuck problem. > Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED > flag is added in patch 1. > Patch 3: Fix the significantly higher CPU consumption problem when > multiple threads are competing on a saturated outgoing > device. > > [...] Here is the summary with links: - [net,v8,1/3] net: sched: fix packet stuck problem for lockless qdisc https://git.kernel.org/netdev/net/c/a90c57f2cedd - [net,v8,2/3] net: sched: fix tx action rescheduling issue during deactivation https://git.kernel.org/netdev/net/c/102b55ee92f9 - [net,v8,3/3] net: sched: fix tx action reschedule issue with stopped queue https://git.kernel.org/netdev/net/c/dcad9ee9e066 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html

1 0

Re: [PATCH net v8 0/3] fix packet stuck problem for lockless qdisc
by Yunsheng Lin 14 May '21

14 May '21

On 2021/5/14 10:26, Yunsheng Lin wrote: > This patchset fixes the packet stuck problem mentioned in [1]. > > Patch 1: Add STATE_MISSED flag to fix packet stuck problem. > Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED > flag is added in patch 1. > Patch 3: Fix the significantly higher CPU consumption problem when > multiple threads are competing on a saturated outgoing > device. > > V8: Change function name in patch 3 as suggested by Jakub, adjust > commit log in patch 2, and add Acked-by from Jakub. Please ignore this patchset, there is some typo in patch 3. > V7: Fix netif_tx_wake_queue() data race noted by Jakub. > V6: Some performance optimization in patch 1 suggested by Jakub > and drop NET_XMIT_DROP checking in patch 3. > V5: add patch 3 to fix the problem reported by Michal Kubecek. > V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED and add patch 2. > > [1]. https://lkml.org/lkml/2019/10/9/42 > > Yunsheng Lin (3): > net: sched: fix packet stuck problem for lockless qdisc > net: sched: fix tx action rescheduling issue during deactivation > net: sched: fix tx action reschedule issue with stopped queue > > include/net/pkt_sched.h | 7 +------ > include/net/sch_generic.h | 35 ++++++++++++++++++++++++++++++++- > net/core/dev.c | 29 ++++++++++++++++++++++----- > net/sched/sch_generic.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-- > 4 files changed, 107 insertions(+), 14 deletions(-) >

1 0

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Alex Williamson 14 May '21

14 May '21

On Thu, 13 May 2021 17:52:56 +0000 Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com> wrote: > Hi Alex, > > > -----Original Message----- > > From: Alex Williamson [mailto:alex.williamson@redhat.com] > > Sent: 13 May 2021 18:04 > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com> > > Cc: Jason Gunthorpe <jgg(a)nvidia.com>; liulongfang > > <liulongfang(a)huawei.com>; cohuck(a)redhat.com; > > linux-kernel(a)vger.kernel.org; linuxarm(a)openeuler.org > > Subject: [Linuxarm] Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to > > vfio > > > > On Thu, 13 May 2021 15:49:25 +0000 > > Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com> > > wrote: > > > > > > -----Original Message----- > > > > From: Jason Gunthorpe [mailto:jgg@nvidia.com] > > > > Sent: 13 May 2021 14:44 > > > > To: liulongfang <liulongfang(a)huawei.com> > > > > Cc: Alex Williamson <alex.williamson(a)redhat.com>; cohuck(a)redhat.com; > > > > linux-kernel(a)vger.kernel.org; linuxarm(a)openeuler.org > > > > Subject: [Linuxarm] Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to > > > > vfio > > > > > > > > On Thu, May 13, 2021 at 10:08:28AM +0800, liulongfang wrote: > > > > > On 2021/5/12 20:10, Jason Gunthorpe wrote: > > > > > > On Wed, May 12, 2021 at 04:39:43PM +0800, liulongfang wrote: > > > > > > > > > > > >> Therefore, this method of limiting the length of the BAR > > > > > >> configuration space can prevent unsafe operations of the memory. > > > > > > > > > > > > The issue is DMA controlled by the guest accessing the secure BAR > > > > > > area, not the guest CPU. > > > > > > > > > > > > Jason > > > > > > . > > > > > > > > > > > This secure BAR area is not presented to the Guest, > > > > > which makes it impossible for the Guest to obtain the secure BAR area > > > > > when establishing the DMA mapping of the configuration space. > > > > > If the DMA controller accesses the secure BAR area, the access will > > > > > be blocked by the SMMU. > > > > > > > > There are scenarios where this is not true. > > > > > > > > At a minimum the mdev driver should refuse to work in those cases. > > > > > > > > > > Hi, > > > > > > I think the idea here is not a generic solution, but a quirk for this specific dev. > > > > > > Something like, > > > > > > --- a/drivers/vfio/pci/vfio_pci.c > > > +++ b/drivers/vfio/pci/vfio_pci.c > > > @@ -866,7 +866,12 @@ static long vfio_pci_ioctl(struct vfio_device > > *core_vdev, > > > break; > > > case VFIO_PCI_BAR0_REGION_INDEX ... > > VFIO_PCI_BAR5_REGION_INDEX: > > > info.offset = > > VFIO_PCI_INDEX_TO_OFFSET(info.index); > > > - info.size = pci_resource_len(pdev, info.index); > > > + > > > + if (check_hisi_acc_quirk(pdev, info)) > > > + info.size = new_size;// BAR is limited > > without migration region. > > > + else > > > + info.size = pci_resource_len(pdev, > > info.index); > > > + > > > if (!info.size) { > > > info.flags = 0; > > > break; > > > > > > Is this an acceptable/workable solution here? > > > > As Jason says, this only restricts CPU access to the BAR, the issue is > > DMA access. As the hardware vendor you may be able to guarantee that > > a DMA transaction generated by the device targeting the remainder of > > the BAR will always go upstream, but can you guarantee the routing > > between the device and the SMMU? For instance if this device can be > > implemented as a plugin card, then it can be installed into a > > downstream port that may not support ACS. That downstream port may > > implement request redirection allowing the transaction to reflect back > > to the device without IOMMU translation. At that point the userspace > > driver can target the kernel driver half of the BAR and potentially > > expose a security risk. Thanks, > > The ACC devices on this platform are not pluggable devices. They are exposed > as integrated endpoint devices. So I am not sure the above concern is valid in this > case. > > I had a look at the userspace driver approach you suggested. But unfortunately > the migration state change for the vf has to check some of the pf registers for > confirming the state. So even if we move the implementation to Qemu, we > still may have to use the migration uAPI to access the pf device registers. > > Since the devices we are concerned here are all integrated endpoints and if the > above quirk is an acceptable one, then we can use the uAPI as done in this > series without overly complicating things here. If you expect this device to appear only as an integrated endpoint, then I think Jason's suggestion above is correct. Your driver that supports migration can refuse to load for devices there the topology is other than expected and you're effectively guaranteeing DMA isolation of the user and in-kernel drivers by hardware DMA semantics and topology. Requiring access to the PF to support the migration protocol also suggests that an in-kernel driver to support migration is our best option. Thanks, Alex

3 2

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Alex Williamson 14 May '21

14 May '21

On Thu, 13 May 2021 15:49:25 +0000 Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com> wrote: > > -----Original Message----- > > From: Jason Gunthorpe [mailto:jgg@nvidia.com] > > Sent: 13 May 2021 14:44 > > To: liulongfang <liulongfang(a)huawei.com> > > Cc: Alex Williamson <alex.williamson(a)redhat.com>; cohuck(a)redhat.com; > > linux-kernel(a)vger.kernel.org; linuxarm(a)openeuler.org > > Subject: [Linuxarm] Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to > > vfio > > > > On Thu, May 13, 2021 at 10:08:28AM +0800, liulongfang wrote: > > > On 2021/5/12 20:10, Jason Gunthorpe wrote: > > > > On Wed, May 12, 2021 at 04:39:43PM +0800, liulongfang wrote: > > > > > > > >> Therefore, this method of limiting the length of the BAR > > > >> configuration space can prevent unsafe operations of the memory. > > > > > > > > The issue is DMA controlled by the guest accessing the secure BAR > > > > area, not the guest CPU. > > > > > > > > Jason > > > > . > > > > > > > This secure BAR area is not presented to the Guest, > > > which makes it impossible for the Guest to obtain the secure BAR area > > > when establishing the DMA mapping of the configuration space. > > > If the DMA controller accesses the secure BAR area, the access will > > > be blocked by the SMMU. > > > > There are scenarios where this is not true. > > > > At a minimum the mdev driver should refuse to work in those cases. > > > > Hi, > > I think the idea here is not a generic solution, but a quirk for this specific dev. > > Something like, > > --- a/drivers/vfio/pci/vfio_pci.c > +++ b/drivers/vfio/pci/vfio_pci.c > @@ -866,7 +866,12 @@ static long vfio_pci_ioctl(struct vfio_device *core_vdev, > break; > case VFIO_PCI_BAR0_REGION_INDEX ... VFIO_PCI_BAR5_REGION_INDEX: > info.offset = VFIO_PCI_INDEX_TO_OFFSET(info.index); > - info.size = pci_resource_len(pdev, info.index); > + > + if (check_hisi_acc_quirk(pdev, info)) > + info.size = new_size;// BAR is limited without migration region. > + else > + info.size = pci_resource_len(pdev, info.index); > + > if (!info.size) { > info.flags = 0; > break; > > Is this an acceptable/workable solution here? As Jason says, this only restricts CPU access to the BAR, the issue is DMA access. As the hardware vendor you may be able to guarantee that a DMA transaction generated by the device targeting the remainder of the BAR will always go upstream, but can you guarantee the routing between the device and the SMMU? For instance if this device can be implemented as a plugin card, then it can be installed into a downstream port that may not support ACS. That downstream port may implement request redirection allowing the transaction to reflect back to the device without IOMMU translation. At that point the userspace driver can target the kernel driver half of the BAR and potentially expose a security risk. Thanks, Alex

1 0

[PATCH net v7 0/3] fix packet stuck problem for lockless qdisc
by Yunsheng Lin 13 May '21

13 May '21

This patchset fixes the packet stuck problem mentioned in [1]. Patch 1: Add STATE_MISSED flag to fix packet stuck problem. Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED flag is added in patch 1. Patch 3: Fix the significantly higher CPU consumption problem when multiple threads are competing on a saturated outgoing device. V7: Fix netif_tx_wake_queue() data race noted by Jakub. V6: Some performance optimization in patch 1 suggested by Jakub and drop NET_XMIT_DROP checking in patch 3. V5: add patch 3 to fix the problem reported by Michal Kubecek. V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED and add patch 2. [1]. https://lkml.org/lkml/2019/10/9/42 Yunsheng Lin (3): net: sched: fix packet stuck problem for lockless qdisc net: sched: fix endless tx action reschedule during deactivation net: sched: fix tx action reschedule issue with stopped queue include/net/pkt_sched.h | 7 +------ include/net/sch_generic.h | 35 ++++++++++++++++++++++++++++++++- net/core/dev.c | 29 ++++++++++++++++++++++----- net/sched/sch_generic.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-- 4 files changed, 107 insertions(+), 14 deletions(-) -- 2.7.4

2 5

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Jason Gunthorpe 13 May '21

13 May '21

On Thu, May 13, 2021 at 10:08:28AM +0800, liulongfang wrote: > On 2021/5/12 20:10, Jason Gunthorpe wrote: > > On Wed, May 12, 2021 at 04:39:43PM +0800, liulongfang wrote: > > > >> Therefore, this method of limiting the length of the BAR > >> configuration space can prevent unsafe operations of the memory. > > > > The issue is DMA controlled by the guest accessing the secure BAR > > area, not the guest CPU. > > > > Jason > > . > > > This secure BAR area is not presented to the Guest, > which makes it impossible for the Guest to obtain the secure BAR area > when establishing the DMA mapping of the configuration space. > If the DMA controller accesses the secure BAR area, the access will > be blocked by the SMMU. There are scenarios where this is not true. At a minimum the mdev driver should refuse to work in those cases. Jason

1 0

[PATCH net v6 0/3] fix packet stuck problem for lockless qdisc
by Yunsheng Lin 13 May '21

13 May '21

This patchset fixes the packet stuck problem mentioned in [1]. Patch 1: Add STATE_MISSED flag to fix packet stuck problem. Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED flag is added in patch 1. Patch 3: Fix the significantly higher CPU consumption problem when multiple threads are competing on a saturated outgoing device. V6: Some performance optimization in patch 1 suggested by Jakub and drop NET_XMIT_DROP checking in patch 3. V5: add patch 3 to fix the problem reported by Michal Kubecek. V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED and add patch 2. [1]. https://lkml.org/lkml/2019/10/9/42 Yunsheng Lin (3): net: sched: fix packet stuck problem for lockless qdisc net: sched: fix endless tx action reschedule during deactivation net: sched: fix tx action reschedule issue with stopped queue include/net/pkt_sched.h | 7 +------ include/net/sch_generic.h | 33 ++++++++++++++++++++++++++++++++- net/core/dev.c | 29 ++++++++++++++++++++++++----- net/sched/sch_generic.c | 31 +++++++++++++++++++++++++++++-- 4 files changed, 86 insertions(+), 14 deletions(-) -- 2.7.4

2 9

Re: [Intel-wired-lan] [PATCH V3 net] ice: Re-organizes reqstd/avail {R, T}XQ check/code for efficiency
by Brelinski, TonyX 12 May '21

12 May '21

> -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces(a)osuosl.org> On Behalf Of > Salil Mehta > Sent: Thursday, April 22, 2021 5:00 PM > To: davem(a)davemloft.net; kuba(a)kernel.org > Cc: salil.mehta(a)huawei.com; netdev(a)vger.kernel.org; > linuxarm(a)huawei.com; linuxarm(a)openeuler.org; linux- > kernel(a)vger.kernel.org; intel-wired-lan(a)lists.osuosl.org > Subject: [Intel-wired-lan] [PATCH V3 net] ice: Re-organizes reqstd/avail {R, > T}XQ check/code for efficiency > > If user has explicitly requested the number of {R,T}XQs, then it is > unnecessary to get the count of already available {R,T}XQs from the PF > avail_{r,t}xqs bitmap. This value will get overridden by user specified value in > any case. > > Re-organize this code for improving the flow, readability and efficiency. > This scope of improvement was found during the review of the ICE driver > code. > > Fixes: 87324e747fde ("ice: Implement ethtool ops for channels") > Cc: intel-wired-lan(a)lists.osuosl.org > Tested-by: Tony Brelinski <tonyx.brelinski(a)intel.com> > Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> > --- > Change: > V2->V3 > (*) Addressed some comments from Paul Menzel > Link: https://lkml.org/lkml/2021/4/21/136 > V1->V2 > (*) Fixed the comments from Anthony Nguyen(Intel) > Link: https://lkml.org/lkml/2021/4/12/1997 > --- > drivers/net/ethernet/intel/ice/ice_lib.c | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) Tested-by: Tony Brelinski <tonyx.brelinski(a)intel.com> (A Contingent Worker at Intel)

1 0

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Jason Gunthorpe 12 May '21

12 May '21

On Wed, May 12, 2021 at 04:39:43PM +0800, liulongfang wrote: > Therefore, this method of limiting the length of the BAR > configuration space can prevent unsafe operations of the memory. The issue is DMA controlled by the guest accessing the secure BAR area, not the guest CPU. Jason

1 0

[PATCH 00/17] tty: Fix some coding style issues
by Xiaofei Tan 12 May '21

12 May '21

Fix some issues reported by checkpatch.pl. All of them are coding style issues, no function changes. Xiaofei Tan (17): tty: tty_baudrate: Remove unnecessary tab and spaces in comment sentence tty: tty_baudrate: Fix coding style issues of block comments tty: tty_buffer: Add a blank line after declarations tty: tty_buffer: Remove the repeated word 'the' tty: tty_buffer: Fix coding style issues of block comments tty: tty_io: Remove spaces before tabs tty: tty_io: Add a blank line after declarations tty: tty_io: Fix spaces required around that ':' tty: tty_io: Fix trailing whitespace issues tty: tty_io: Fix coding style issues of block comments tty: tty_io: Remove the repeated word 'can' tty: tty_io: Fix an issue of code indent for conditional statements tty: tty_io: Delete a blank line before EXPORT_SYMBOL(foo) tty: tty_io: Remove return in void function tty: tty_port: Delete a blank line before EXPORT_SYMBOL(foo) tty: tty_port: Add a blank line after declarations tty: tty_port: Fix coding style issues of block comments drivers/tty/tty_baudrate.c | 13 ++++++---- drivers/tty/tty_buffer.c | 20 +++++++++++---- drivers/tty/tty_io.c | 61 ++++++++++++++++++++++++++-------------------- drivers/tty/tty_port.c | 16 +++++++----- 4 files changed, 67 insertions(+), 43 deletions(-) -- 2.8.1

1 6

[PATCH] RDMA/ucma: Cleanup to reduce duplicate code
by Xiaofei Tan 12 May '21

12 May '21

The lable "err1" does the same thing as the branch of copy_to_user() failed in the function ucma_create_id(). Just jump to the label directly to reduce duplicate code. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/infiniband/core/ucma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c index 15d57ba..1f198c1 100644 --- a/drivers/infiniband/core/ucma.c +++ b/drivers/infiniband/core/ucma.c @@ -468,8 +468,8 @@ static ssize_t ucma_create_id(struct ucma_file *file, const char __user *inbuf, resp.id = ctx->id; if (copy_to_user(u64_to_user_ptr(cmd.response), &resp, sizeof(resp))) { - ucma_destroy_private_ctx(ctx); - return -EFAULT; + ret = -EFAULT; + goto err1; } mutex_lock(&file->mut); -- 2.8.1

3 2

Re: [dpdk-dev] [PATCH v3] eal: fix use wrong time API
by Thomas Monjalon 11 May '21

11 May '21

05/05/2021 05:43, Chengwen Feng: > Currently, the mp uses gettimeofday() API to get the time, and used as > timeout parameter. > > But the time which gets from gettimeofday() API isn't monotonically > increasing. The process may fail if the system time is changed. > > This fixes it by using clock_gettime() API with monotonic attribution. > > Fixes: 783b6e54971d ("eal: add synchronous multi-process communication") > Fixes: f05e26051c15 ("eal: add IPC asynchronous request") > Cc: stable(a)dpdk.org > > Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> > Signed-off-by: Min Hu (Connor) <humin29(a)huawei.com> > Acked-by: Morten Brørup <mb(a)smartsharesystems.com> > --- > v3: > * add acked-by. > * change patch's author. I did some comments on v2 about potential errors to catch, but you sent this v3 without participating in v2 discussion.

2 1

Re: [PATCH net v5 1/3] net: sched: fix packet stuck problem for lockless qdisc
by Jakub Kicinski 08 May '21

08 May '21

On Sat, 8 May 2021 10:55:19 +0800 Yunsheng Lin wrote: > >> + * the flag set after releasing lock and reschedule the > >> + * net_tx_action() to do the dequeuing. > > > > I don't understand why MISSED is checked before the trylock. > > Could you explain why it can't be tested directly here? > The initial thinking was: > Just like the set_bit() before the second trylock, If MISSED is set > before first trylock, it means other thread has set the MISSED flag > for this thread before doing the first trylock, so that this thread > does not need to do the set_bit(). > > But the initial thinking seems over thinking, as thread 3' setting the > MISSED before the second trylock has ensure either thread 3' second > trylock returns ture or thread 2 holding the lock will see the MISSED > flag, so thread 1 can do the test_bit() before or after the first > trylock, as below: > > thread 1 thread 2 thread 3 > holding q->seqlock > first trylock failed first trylock failed > unlock q->seqlock > test_bit(MISSED) return false > test_bit(MISSED) return false > and not reschedule > set_bit(MISSED) > trylock success > test_bit(MISSED) retun ture > and not retry second trylock > > If the above is correct, it seems we could: > 1. do test_bit(MISSED) before the first trylock to avoid doing the > first trylock for contended case. > or > 2. do test_bit(MISSED) after the first trylock to avoid doing the > test_bit() for un-contended case. > > Which one do you prefer? No strong preference but testing after the trylock seems more obvious as it saves the temporary variable. For the contended case could we potentially move or add a MISSED test before even the first try_lock()? I'm not good at optimizing things, but it could save us the atomic op, right? (at least on x86)

1 0

[PATCH net v5 0/3] fix packet stuck problem for lockless qdisc
by Yunsheng Lin 08 May '21

08 May '21

This patchset fixes the packet stuck problem mentioned in [1]. Patch 1: Add STATE_MISSED flag to fix packet stuck problem. Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED flag is added in patch 1. Patch 3: Fix the significantly higher CPU consumption problem when multiple threads are competing on a saturated outgoing device. V5: add patch 3 to fix the problem reported by Michal Kubecek. V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED and add patch 2. [1]. https://lkml.org/lkml/2019/10/9/42 Yunsheng Lin (3): net: sched: fix packet stuck problem for lockless qdisc net: sched: fix endless tx action reschedule during deactivation net: sched: fix tx action reschedule issue with stopped queue include/net/pkt_sched.h | 7 +------ include/net/sch_generic.h | 37 ++++++++++++++++++++++++++++++++++++- net/core/dev.c | 30 +++++++++++++++++++++++++----- net/sched/sch_generic.c | 24 ++++++++++++++++++++++-- 4 files changed, 84 insertions(+), 14 deletions(-) -- 2.7.4

2 4

[PATCH] RDMA/ucma: Cleanup of reducing duplicate code
by Xiaofei Tan 06 May '21

06 May '21

The lable "err1" does the same thing as the branch of copy_to_user() failed in the function ucma_create_id(). Just jump to the label directly to reduce duplicate code. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/infiniband/core/ucma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c index 15d57ba..1f198c1 100644 --- a/drivers/infiniband/core/ucma.c +++ b/drivers/infiniband/core/ucma.c @@ -468,8 +468,8 @@ static ssize_t ucma_create_id(struct ucma_file *file, const char __user *inbuf, resp.id = ctx->id; if (copy_to_user(u64_to_user_ptr(cmd.response), &resp, sizeof(resp))) { - ucma_destroy_private_ctx(ctx); - return -EFAULT; + ret = -EFAULT; + goto err1; } mutex_lock(&file->mut); -- 2.8.1

1 0

[PATCH v3 0/2] fix bugs for librte eal
by Chengwen Feng 06 May '21

06 May '21

This patchset fixed some bugs for librte_eal. v3: * change patch's author v2: * set variables an unsigned type. Chengwen Feng (2): eal: check mp reply result eal: fix service core index validity lib/eal/common/eal_common_options.c | 6 ++++-- lib/eal/common/malloc_mp.c | 4 +--- 2 files changed, 5 insertions(+), 5 deletions(-) -- 2.8.1

3 4

[sched/fair] 5f94d1b650: stress-ng.sock.ops_per_sec -25.2% regression
by kernel test robot 05 May '21

05 May '21

Greeting, FYI, we noticed a -25.2% regression of stress-ng.sock.ops_per_sec due to commit: commit: 5f94d1b650d14e01f383e3d02e40c13a9ccecaf4 ("[PATCH] sched/fair: don't use waker's cpu if the waker of sync wake-up is interrupt") url: https://github.com/0day-ci/linux/commits/Barry-Song/sched-fair-don-t-use-wa… base: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git 2ea46c6fc9452ac100ad907b051d797225847e33 in testcase: stress-ng on test machine: 96 threads 2 sockets Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 192G memory with following parameters: nr_threads: 10% disk: 1HDD testtime: 60s fs: ext4 class: os test: sock cpufreq_governor: performance ucode: 0x5003006 In addition to that, the commit also has significant impact on the following tests: +------------------+-------------------------------------------------------------------------------------+ | testcase: change | apachebench: apachebench.requests_per_second -5.6% regression | | test machine | 96 threads 2 sockets Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 192G memory | | test parameters | cluster=cs-localhost | | | concurrency=8000 | | | cpufreq_governor=performance | | | runtime=300s | | | ucode=0x5003006 | +------------------+-------------------------------------------------------------------------------------+ | testcase: change | netperf: netperf.Throughput_Mbps -52.4% regression | | test machine | 192 threads 4 sockets Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 192G memory | | test parameters | cluster=cs-localhost | | | cpufreq_governor=performance | | | ip=ipv4 | | | nr_threads=1 | | | runtime=300s | | | test=UDP_STREAM | | | ucode=0x5003006 | +------------------+-------------------------------------------------------------------------------------+ If you fix the issue, kindly add following tag Reported-by: kernel test robot <oliver.sang(a)intel.com> Details are as below: --------------------------------------------------------------------------------------------------> To reproduce: git clone https://github.com/intel/lkp-tests.git cd lkp-tests bin/lkp install job.yaml # job file is attached in this email bin/lkp split-job --compatible job.yaml # generate the yaml file for lkp run bin/lkp run generated-yaml-file ========================================================================================= class/compiler/cpufreq_governor/disk/fs/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime/ucode: os/gcc-9/performance/1HDD/ext4/x86_64-rhel-8.3/10%/debian-10.4-x86_64-20200603.cgz/lkp-csl-2sp5/sock/stress-ng/60s/0x5003006 commit: 2ea46c6fc9 ("cpumask/hotplug: Fix cpu_dying() state tracking") 5f94d1b650 ("sched/fair: don't use waker's cpu if the waker of sync wake-up is interrupt") 2ea46c6fc9452ac1 5f94d1b650d14e01f383e3d02e4 ---------------- --------------------------- %stddev %change %stddev \ | \ 668165 -25.2% 499709 ± 7% stress-ng.sock.ops 11135 -25.2% 8328 ± 7% stress-ng.sock.ops_per_sec 2633 ± 5% -18.0% 2159 ± 8% stress-ng.time.involuntary_context_switches 11225 ± 2% -6.1% 10545 stress-ng.time.minor_page_faults 1283 -0.9% 1272 stress-ng.time.percent_of_cpu_this_job_got 32.76 -21.3% 25.78 ± 6% stress-ng.time.user_time 39827551 -9.3% 36139210 ± 4% stress-ng.time.voluntary_context_switches 0.53 -0.1 0.44 ± 4% mpstat.cpu.all.usr% 1218481 -8.8% 1111783 ± 4% vmstat.system.cs 36137621 +30.6% 47196861 ± 12% cpuidle.C1.time 9079420 +19.3% 10827569 ± 8% cpuidle.C1.usage 73682855 -15.0% 62612480 ± 6% cpuidle.POLL.time 30399709 -17.5% 25089524 ± 9% cpuidle.POLL.usage 20602586 ± 4% -23.7% 15709836 ± 12% numa-numastat.node0.local_node 20665440 ± 4% -23.8% 15744289 ± 11% numa-numastat.node0.numa_hit 21017060 ± 3% -25.6% 15638989 ± 12% numa-numastat.node1.local_node 21040859 ± 3% -25.4% 15691162 ± 12% numa-numastat.node1.numa_hit 11110566 -22.4% 8621534 ± 10% numa-vmstat.node0.numa_hit 11047694 -22.3% 8586688 ± 10% numa-vmstat.node0.numa_local 10652347 -23.7% 8131841 ± 8% numa-vmstat.node1.numa_hit 10462586 -24.4% 7914174 ± 9% numa-vmstat.node1.numa_local 6200 ± 2% -11.7% 5472 ± 4% slabinfo.dmaengine-unmap-16.active_objs 6204 ± 2% -11.7% 5478 ± 4% slabinfo.dmaengine-unmap-16.num_objs 8326 ± 2% -24.8% 6257 ± 8% slabinfo.sock_inode_cache.active_objs 8326 ± 2% -24.8% 6257 ± 8% slabinfo.sock_inode_cache.num_objs 9070645 +19.3% 10820329 ± 8% turbostat.C1 0.58 +0.2 0.77 ± 12% turbostat.C1% 54.00 +4.8% 56.57 turbostat.PkgTmp 202.21 +1.4% 205.06 turbostat.PkgWatt 80.33 +17.3% 94.21 ± 3% turbostat.RAMWatt 23149 -2.7% 22523 proc-vmstat.nr_slab_reclaimable 1054 ± 25% -59.0% 432.43 ± 20% proc-vmstat.numa_hint_faults 41537249 -24.9% 31186035 ± 7% proc-vmstat.numa_hit 41450577 -25.0% 31099388 ± 7% proc-vmstat.numa_local 3.312e+08 -24.8% 2.491e+08 ± 7% proc-vmstat.pgalloc_normal 3.311e+08 -24.8% 2.489e+08 ± 7% proc-vmstat.pgfree 273665 ± 3% -38.2% 169120 ± 17% interrupts.CAL:Function_call_interrupts 3560 ± 33% -44.7% 1968 ± 35% interrupts.CPU1.CAL:Function_call_interrupts 2900 ± 37% -50.5% 1436 ± 58% interrupts.CPU13.CAL:Function_call_interrupts 488.67 ± 29% -62.2% 184.71 ± 63% interrupts.CPU24.RES:Rescheduling_interrupts 3783 ± 19% -59.9% 1518 ± 40% interrupts.CPU25.CAL:Function_call_interrupts 282.67 ± 29% -56.6% 122.57 ± 54% interrupts.CPU25.RES:Rescheduling_interrupts 3736 ± 38% -66.6% 1246 ± 34% interrupts.CPU27.CAL:Function_call_interrupts 268.50 ± 39% -71.3% 77.00 ± 49% interrupts.CPU27.RES:Rescheduling_interrupts 3493 ± 41% -52.3% 1667 ± 40% interrupts.CPU36.CAL:Function_call_interrupts 3883 ± 54% -55.7% 1719 ± 46% interrupts.CPU5.CAL:Function_call_interrupts 4026 ± 20% -55.6% 1788 ± 37% interrupts.CPU50.CAL:Function_call_interrupts 4144 ± 23% -51.2% 2022 ± 70% interrupts.CPU50.NMI:Non-maskable_interrupts 4144 ± 23% -51.2% 2022 ± 70% interrupts.CPU50.PMI:Performance_monitoring_interrupts 2631 ± 38% -46.5% 1408 ± 35% interrupts.CPU52.CAL:Function_call_interrupts 4379 ± 54% -59.0% 1796 ± 78% interrupts.CPU55.CAL:Function_call_interrupts 2710 ± 35% -58.4% 1127 ± 63% interrupts.CPU56.CAL:Function_call_interrupts 183.67 ± 21% -65.4% 63.57 ± 58% interrupts.CPU56.RES:Rescheduling_interrupts 2969 ± 37% -52.6% 1407 ± 48% interrupts.CPU57.CAL:Function_call_interrupts 3712 ± 18% -73.9% 968.57 ± 96% interrupts.CPU60.NMI:Non-maskable_interrupts 3712 ± 18% -73.9% 968.57 ± 96% interrupts.CPU60.PMI:Performance_monitoring_interrupts 2946 ± 27% -56.2% 1289 ± 52% interrupts.CPU61.CAL:Function_call_interrupts 2221 ± 35% -59.7% 895.29 ± 89% interrupts.CPU61.NMI:Non-maskable_interrupts 2221 ± 35% -59.7% 895.29 ± 89% interrupts.CPU61.PMI:Performance_monitoring_interrupts 186.50 ± 29% -52.0% 89.43 ± 76% interrupts.CPU65.RES:Rescheduling_interrupts 4913 ± 42% -73.8% 1286 ± 51% interrupts.CPU67.CAL:Function_call_interrupts 3640 ± 42% -63.3% 1336 ± 37% interrupts.CPU75.CAL:Function_call_interrupts 4197 ± 41% -74.5% 1071 ± 51% interrupts.CPU76.CAL:Function_call_interrupts 274.00 ± 46% -66.9% 90.57 ± 70% interrupts.CPU76.RES:Rescheduling_interrupts 4458 ± 33% -48.2% 2307 ± 41% interrupts.CPU78.CAL:Function_call_interrupts 174.00 ± 21% -42.9% 99.43 ± 42% interrupts.CPU91.RES:Rescheduling_interrupts 2615 ± 43% -52.8% 1235 ± 41% interrupts.CPU93.CAL:Function_call_interrupts 17598 ± 4% -23.0% 13556 ± 14% softirqs.CPU0.RCU 13220 ± 6% -20.5% 10514 ± 10% softirqs.CPU1.RCU 12111 ± 13% -19.9% 9699 ± 9% softirqs.CPU16.RCU 12269 ± 4% -18.3% 10030 ± 13% softirqs.CPU2.RCU 15935 ± 10% -15.7% 13430 ± 20% softirqs.CPU24.RCU 14418 ± 14% -26.6% 10583 ± 14% softirqs.CPU25.RCU 788851 ± 32% -55.0% 354883 ± 28% softirqs.CPU27.NET_RX 13652 ± 13% -28.7% 9734 ± 5% softirqs.CPU27.RCU 13432 ± 10% -15.7% 11328 ± 4% softirqs.CPU27.SCHED 11413 ± 12% -17.5% 9415 ± 15% softirqs.CPU4.RCU 13077 ± 13% -13.7% 11288 ± 21% softirqs.CPU49.SCHED 14547 ± 12% -22.2% 11314 ± 8% softirqs.CPU50.RCU 13654 ± 3% -11.6% 12076 ± 11% softirqs.CPU52.RCU 830025 ± 36% -63.2% 305684 ± 58% softirqs.CPU56.NET_RX 13872 ± 16% -38.1% 8591 ± 10% softirqs.CPU56.RCU 13666 ± 10% -29.7% 9607 ± 17% softirqs.CPU57.RCU 13660 ± 13% -26.0% 10105 ± 13% softirqs.CPU60.RCU 13861 ± 11% -12.2% 12172 ± 10% softirqs.CPU60.SCHED 12378 ± 9% -25.7% 9199 ± 13% softirqs.CPU61.RCU 13237 ± 12% -17.8% 10879 ± 10% softirqs.CPU63.RCU 14837 ± 20% -26.4% 10923 ± 12% softirqs.CPU65.RCU 13078 ± 10% -20.0% 10462 ± 9% softirqs.CPU68.RCU 1014501 ± 29% -51.1% 496322 ± 35% softirqs.CPU76.NET_RX 14929 ± 14% -33.3% 9964 ± 8% softirqs.CPU76.RCU 14824 ± 9% -20.2% 11834 ± 9% softirqs.CPU76.SCHED 14956 ± 15% -29.7% 10517 ± 16% softirqs.CPU79.RCU 14781 ± 18% -30.9% 10210 ± 20% softirqs.CPU80.RCU 665014 ± 50% -46.2% 357487 ± 55% softirqs.CPU83.NET_RX 12417 ± 14% -25.5% 9246 ± 9% softirqs.CPU83.RCU 12715 ± 10% -19.8% 10191 ± 10% softirqs.CPU86.RCU 54301315 -10.1% 48817727 ± 3% softirqs.NET_RX 1165787 ± 2% -14.0% 1002845 ± 2% softirqs.RCU 21.24 -3.7% 20.44 ± 2% perf-stat.i.MPKI 7.91e+09 -18.5% 6.447e+09 ± 5% perf-stat.i.branch-instructions 1.218e+08 -17.6% 1.003e+08 ± 5% perf-stat.i.branch-misses 0.96 ± 31% +24.3 25.26 ± 28% perf-stat.i.cache-miss-rate% 4298146 ± 3% +3705.0% 1.635e+08 ± 22% perf-stat.i.cache-misses 8.4e+08 -20.9% 6.648e+08 ± 7% perf-stat.i.cache-references 1262713 -9.0% 1149476 ± 4% perf-stat.i.context-switches 1.30 +20.3% 1.57 ± 5% perf-stat.i.cpi 133.25 ± 2% -5.4% 126.01 ± 2% perf-stat.i.cpu-migrations 11560 ± 3% -96.1% 449.24 ± 21% perf-stat.i.cycles-between-cache-misses 1.12e+10 -18.1% 9.179e+09 ± 5% perf-stat.i.dTLB-loads 41181 ± 15% -31.8% 28074 ± 15% perf-stat.i.dTLB-store-misses 6.345e+09 -18.1% 5.195e+09 ± 5% perf-stat.i.dTLB-stores 94303727 -16.4% 78848232 ± 5% perf-stat.i.iTLB-load-misses 3.898e+10 -18.5% 3.178e+10 ± 5% perf-stat.i.instructions 0.78 -17.1% 0.64 ± 5% perf-stat.i.ipc 0.85 ± 8% -23.3% 0.65 ± 4% perf-stat.i.metric.K/sec 274.05 -18.0% 224.70 ± 5% perf-stat.i.metric.M/sec 81.79 +15.2 96.96 perf-stat.i.node-load-miss-rate% 874824 ± 3% +7178.9% 63677834 ± 23% perf-stat.i.node-load-misses 192930 ± 4% +534.0% 1223150 ± 21% perf-stat.i.node-loads 87.79 ± 2% +9.5 97.27 perf-stat.i.node-store-miss-rate% 657426 ± 3% +1728.3% 12019579 ± 22% perf-stat.i.node-store-misses 83513 ± 17% -51.2% 40778 ± 6% perf-stat.i.node-stores 21.55 -3.0% 20.90 perf-stat.overall.MPKI 1.54 +0.0 1.56 perf-stat.overall.branch-miss-rate% 0.51 ± 3% +24.6 25.11 ± 28% perf-stat.overall.cache-miss-rate% 1.28 +22.6% 1.57 ± 5% perf-stat.overall.cpi 11588 ± 3% -97.2% 322.82 ± 26% perf-stat.overall.cycles-between-cache-misses 0.78 -18.2% 0.64 ± 5% perf-stat.overall.ipc 81.93 +16.2 98.10 perf-stat.overall.node-load-miss-rate% 88.73 ± 2% +10.9 99.64 perf-stat.overall.node-store-miss-rate% 7.782e+09 -18.5% 6.343e+09 ± 5% perf-stat.ps.branch-instructions 1.198e+08 -17.6% 98698837 ± 5% perf-stat.ps.branch-misses 4230041 ± 3% +3703.2% 1.609e+08 ± 22% perf-stat.ps.cache-misses 8.265e+08 -20.9% 6.541e+08 ± 7% perf-stat.ps.cache-references 1242259 -9.0% 1130898 ± 4% perf-stat.ps.context-switches 131.16 ± 2% -5.4% 124.02 ± 2% perf-stat.ps.cpu-migrations 1.102e+10 -18.1% 9.031e+09 ± 5% perf-stat.ps.dTLB-loads 40640 ± 15% -31.9% 27660 ± 15% perf-stat.ps.dTLB-store-misses 6.243e+09 -18.1% 5.111e+09 ± 5% perf-stat.ps.dTLB-stores 92776465 -16.4% 77575353 ± 5% perf-stat.ps.iTLB-load-misses 3.835e+10 -18.5% 3.127e+10 ± 5% perf-stat.ps.instructions 860793 ± 3% +7176.9% 62639147 ± 23% perf-stat.ps.node-load-misses 189892 ± 4% +533.7% 1203290 ± 21% perf-stat.ps.node-loads 646849 ± 3% +1727.9% 11823793 ± 22% perf-stat.ps.node-store-misses 82269 ± 17% -51.1% 40208 ± 6% perf-stat.ps.node-stores 2.442e+12 -18.9% 1.98e+12 ± 5% perf-stat.total.instructions 5.42 ± 7% -1.0 4.38 ± 9% perf-profile.calltrace.cycles-pp.__tcp_push_pending_frames.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg.__sys_sendto 5.29 ± 8% -1.0 4.25 ± 9% perf-profile.calltrace.cycles-pp.tcp_write_xmit.__tcp_push_pending_frames.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg 2.44 ± 8% -0.8 1.64 ± 14% perf-profile.calltrace.cycles-pp.__tcp_transmit_skb.tcp_write_xmit.__tcp_push_pending_frames.tcp_sendmsg_locked.tcp_sendmsg 2.33 ± 8% -0.8 1.56 ± 15% perf-profile.calltrace.cycles-pp.__ip_queue_xmit.__tcp_transmit_skb.tcp_write_xmit.__tcp_push_pending_frames.tcp_sendmsg_locked 0.66 ± 8% -0.3 0.39 ± 63% perf-profile.calltrace.cycles-pp.exit_to_user_mode_prepare.syscall_exit_to_user_mode.entry_SYSCALL_64_after_hwframe 1.28 ± 7% -0.3 1.01 ± 10% perf-profile.calltrace.cycles-pp.sock_do_ioctl.sock_ioctl.do_vfs_ioctl.__x64_sys_ioctl.do_syscall_64 1.37 ± 8% -0.3 1.11 ± 10% perf-profile.calltrace.cycles-pp.lock_sock_nested.tcp_sendmsg.sock_sendmsg.__sys_sendto.__x64_sys_sendto 0.89 ± 7% -0.2 0.68 ± 11% perf-profile.calltrace.cycles-pp.syscall_exit_to_user_mode.entry_SYSCALL_64_after_hwframe 0.81 ± 7% -0.2 0.66 ± 7% perf-profile.calltrace.cycles-pp.tcp_rcv_space_adjust.tcp_recvmsg_locked.tcp_recvmsg.inet_recvmsg.__sys_recvfrom 0.61 ± 8% +0.2 0.82 ± 12% perf-profile.calltrace.cycles-pp.__release_sock.release_sock.tcp_recvmsg.inet_recvmsg.__sys_recvfrom 0.45 ± 44% +0.3 0.71 ± 13% perf-profile.calltrace.cycles-pp.tcp_v4_do_rcv.__release_sock.release_sock.tcp_recvmsg.inet_recvmsg 0.34 ± 70% +0.3 0.65 ± 12% perf-profile.calltrace.cycles-pp.tcp_rcv_established.tcp_v4_do_rcv.__release_sock.release_sock.tcp_recvmsg 1.77 ± 7% -0.4 1.40 ± 9% perf-profile.children.cycles-pp.sock_ioctl 1.74 ± 5% -0.3 1.39 ± 9% perf-profile.children.cycles-pp.__dev_queue_xmit 1.15 ± 7% -0.3 0.85 ± 10% perf-profile.children.cycles-pp.syscall_return_via_sysret 0.94 ± 8% -0.2 0.71 ± 10% perf-profile.children.cycles-pp.syscall_exit_to_user_mode 0.93 ± 4% -0.2 0.76 ± 9% perf-profile.children.cycles-pp.dev_hard_start_xmit 0.61 ± 9% -0.2 0.45 ± 20% perf-profile.children.cycles-pp.update_rq_clock 0.71 ± 8% -0.2 0.55 ± 11% perf-profile.children.cycles-pp.exit_to_user_mode_prepare 0.64 ± 5% -0.1 0.50 ± 8% perf-profile.children.cycles-pp.__entry_text_start 0.66 ± 5% -0.1 0.52 ± 14% perf-profile.children.cycles-pp.aa_sk_perm 0.84 ± 5% -0.1 0.71 ± 9% perf-profile.children.cycles-pp.loopback_xmit 0.57 ± 7% -0.1 0.45 ± 10% perf-profile.children.cycles-pp.tcp_mstamp_refresh 0.45 ± 6% -0.1 0.33 ± 13% perf-profile.children.cycles-pp.security_socket_sendmsg 0.45 ± 8% -0.1 0.34 ± 12% perf-profile.children.cycles-pp.sockfd_lookup_light 0.35 ± 12% -0.1 0.24 ± 11% perf-profile.children.cycles-pp.__virt_addr_valid 0.55 ± 8% -0.1 0.45 ± 11% perf-profile.children.cycles-pp.___might_sleep 0.40 ± 8% -0.1 0.30 ± 11% perf-profile.children.cycles-pp.__fput 0.41 ± 8% -0.1 0.31 ± 11% perf-profile.children.cycles-pp.task_work_run 0.41 ± 7% -0.1 0.34 ± 12% perf-profile.children.cycles-pp.__might_fault 0.26 ± 8% -0.1 0.19 ± 8% perf-profile.children.cycles-pp.sock_close 0.24 ± 9% -0.1 0.18 ± 9% perf-profile.children.cycles-pp.inet_release 0.25 ± 8% -0.1 0.19 ± 8% perf-profile.children.cycles-pp.__sock_release 0.20 ± 7% -0.1 0.14 ± 12% perf-profile.children.cycles-pp.__tcp_close 0.22 ± 8% -0.1 0.16 ± 9% perf-profile.children.cycles-pp.tcp_close 0.19 ± 11% -0.1 0.14 ± 18% perf-profile.children.cycles-pp.ttwu_do_wakeup 0.28 ± 7% -0.1 0.22 ± 13% perf-profile.children.cycles-pp.__cond_resched 0.15 ± 9% -0.1 0.09 ± 21% perf-profile.children.cycles-pp.resched_curr 0.18 ± 9% -0.1 0.13 ± 19% perf-profile.children.cycles-pp.check_preempt_curr 0.18 ± 6% -0.0 0.13 ± 8% perf-profile.children.cycles-pp.__put_user_nocheck_4 0.14 ± 10% -0.0 0.10 ± 16% perf-profile.children.cycles-pp.__sk_mem_schedule 0.19 ± 8% -0.0 0.15 ± 10% perf-profile.children.cycles-pp.__x86_indirect_thunk_rax 0.16 ± 9% -0.0 0.12 ± 19% perf-profile.children.cycles-pp.switch_mm_irqs_off 0.13 ± 9% -0.0 0.09 ± 19% perf-profile.children.cycles-pp.__sk_mem_raise_allocated 0.18 ± 8% -0.0 0.14 ± 11% perf-profile.children.cycles-pp.do_tcp_setsockopt 0.21 ± 7% -0.0 0.17 ± 10% perf-profile.children.cycles-pp.tcp_rcv_synsent_state_process 0.11 ± 4% -0.0 0.08 ± 13% perf-profile.children.cycles-pp.syscall_exit_to_user_mode_prepare 0.14 ± 9% -0.0 0.11 ± 9% perf-profile.children.cycles-pp.open_related_ns 0.13 ± 6% -0.0 0.10 ± 16% perf-profile.children.cycles-pp.__sys_accept4 0.12 ± 5% -0.0 0.09 ± 10% perf-profile.children.cycles-pp.tcp_fin 0.07 ± 7% -0.0 0.04 ± 64% perf-profile.children.cycles-pp.__x64_sys_accept4 0.13 ± 9% -0.0 0.10 ± 14% perf-profile.children.cycles-pp.import_single_range 0.09 ± 9% -0.0 0.07 ± 13% perf-profile.children.cycles-pp.__ip_finish_output 0.08 -0.0 0.06 ± 13% perf-profile.children.cycles-pp.__sock_wfree 0.07 ± 6% -0.0 0.05 ± 42% perf-profile.children.cycles-pp.ksys_read 0.07 ± 6% -0.0 0.05 ± 41% perf-profile.children.cycles-pp.vfs_read 0.09 ± 4% -0.0 0.07 ± 12% perf-profile.children.cycles-pp.tcp_update_recv_tstamps 0.09 ± 14% +0.0 0.13 ± 12% perf-profile.children.cycles-pp.perf_tp_event 0.07 ± 11% +0.0 0.11 ± 13% perf-profile.children.cycles-pp.ip_copy_addrs 0.15 ± 9% +0.1 0.20 ± 10% perf-profile.children.cycles-pp.nr_iowait_cpu 0.08 ± 12% +0.1 0.17 ± 13% perf-profile.children.cycles-pp.available_idle_cpu 0.00 +0.2 0.22 ± 38% perf-profile.children.cycles-pp.ttwu_queue_wakelist 0.00 +0.2 0.23 ± 44% perf-profile.children.cycles-pp.sched_ttwu_pending 0.00 +0.4 0.37 ± 46% perf-profile.children.cycles-pp.flush_smp_call_function_from_idle 1.15 ± 7% -0.3 0.85 ± 10% perf-profile.self.cycles-pp.syscall_return_via_sysret 0.47 ± 9% -0.2 0.32 ± 19% perf-profile.self.cycles-pp.update_rq_clock 0.62 ± 5% -0.2 0.47 ± 12% perf-profile.self.cycles-pp.__dev_queue_xmit 0.64 ± 5% -0.2 0.49 ± 8% perf-profile.self.cycles-pp.__entry_text_start 0.50 ± 8% -0.1 0.39 ± 11% perf-profile.self.cycles-pp.entry_SYSCALL_64_after_hwframe 0.33 ± 12% -0.1 0.22 ± 12% perf-profile.self.cycles-pp.__virt_addr_valid 0.45 ± 4% -0.1 0.35 ± 14% perf-profile.self.cycles-pp.aa_sk_perm 0.33 ± 5% -0.1 0.26 ± 14% perf-profile.self.cycles-pp.set_next_entity 0.09 ± 8% -0.1 0.04 ± 63% perf-profile.self.cycles-pp.dev_hard_start_xmit 0.15 ± 9% -0.1 0.09 ± 21% perf-profile.self.cycles-pp.resched_curr 0.27 ± 7% -0.1 0.22 ± 12% perf-profile.self.cycles-pp.__sys_sendto 0.23 ± 7% -0.1 0.18 ± 9% perf-profile.self.cycles-pp.sock_ioctl 0.21 ± 6% -0.1 0.16 ± 10% perf-profile.self.cycles-pp._copy_to_iter 0.18 ± 5% -0.0 0.13 ± 8% perf-profile.self.cycles-pp.__put_user_nocheck_4 0.15 ± 10% -0.0 0.10 ± 11% perf-profile.self.cycles-pp.syscall_exit_to_user_mode 0.19 ± 11% -0.0 0.14 ± 14% perf-profile.self.cycles-pp.inet_ioctl 0.16 ± 9% -0.0 0.12 ± 20% perf-profile.self.cycles-pp.switch_mm_irqs_off 0.19 ± 9% -0.0 0.15 ± 12% perf-profile.self.cycles-pp.__sys_recvfrom 0.14 ± 7% -0.0 0.09 ± 12% perf-profile.self.cycles-pp.lock_sock_nested 0.13 ± 9% -0.0 0.09 ± 16% perf-profile.self.cycles-pp.__sk_mem_raise_allocated 0.19 ± 5% -0.0 0.16 ± 9% perf-profile.self.cycles-pp.process_backlog 0.07 ± 8% -0.0 0.04 ± 63% perf-profile.self.cycles-pp.tcp_mstamp_refresh 0.12 ± 7% -0.0 0.09 ± 15% perf-profile.self.cycles-pp.sockfd_lookup_light 0.10 ± 4% -0.0 0.07 ± 12% perf-profile.self.cycles-pp.syscall_exit_to_user_mode_prepare 0.08 -0.0 0.05 ± 6% perf-profile.self.cycles-pp.__sock_wfree 0.14 ± 6% -0.0 0.11 ± 10% perf-profile.self.cycles-pp.__cond_resched 0.08 ± 10% -0.0 0.06 ± 10% perf-profile.self.cycles-pp.sock_do_ioctl 0.08 ± 16% +0.0 0.12 ± 13% perf-profile.self.cycles-pp.perf_tp_event 0.07 ± 11% +0.0 0.11 ± 15% perf-profile.self.cycles-pp.ip_copy_addrs 0.15 ± 9% +0.1 0.20 ± 10% perf-profile.self.cycles-pp.nr_iowait_cpu 0.03 ± 99% +0.1 0.09 ± 26% perf-profile.self.cycles-pp.__wake_up_common 0.00 +0.1 0.08 ± 28% perf-profile.self.cycles-pp.ttwu_queue_wakelist 0.08 ± 12% +0.1 0.17 ± 14% perf-profile.self.cycles-pp.available_idle_cpu 0.13 ± 11% +0.1 0.25 ± 18% perf-profile.self.cycles-pp.tcp_sendmsg stress-ng.sock.ops_per_sec 11500 +-------------------------------------------------------------------+ |++.+++ +.+++++. + +.+++++.+++++.++++.++++ +++.++++.+++++.++| 11000 |-+ +.++++ + + +.++ | 10500 |-+ | | | 10000 |-+ | 9500 |-+ O | | O O O O O O O | 9000 |-+ | 8500 |O+ O | | O O O O O O | 8000 |-+ O O O OO OO O OO O | 7500 |-+ O O | | O | 7000 +-------------------------------------------------------------------+ [*] bisect-good sample [O] bisect-bad sample *************************************************************************************************** lkp-csl-2sp8: 96 threads 2 sockets Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 192G memory ========================================================================================= cluster/compiler/concurrency/cpufreq_governor/kconfig/rootfs/runtime/tbox_group/testcase/ucode: cs-localhost/gcc-9/8000/performance/x86_64-rhel-8.3/debian-10.4-x86_64-20200603.cgz/300s/lkp-csl-2sp8/apachebench/0x5003006 commit: 2ea46c6fc9 ("cpumask/hotplug: Fix cpu_dying() state tracking") 5f94d1b650 ("sched/fair: don't use waker's cpu if the waker of sync wake-up is interrupt") 2ea46c6fc9452ac1 5f94d1b650d14e01f383e3d02e4 ---------------- --------------------------- %stddev %change %stddev \ | \ 35891 -5.6% 33871 apachebench.requests_per_second 28.96 +5.8% 30.64 apachebench.time.elapsed_time 28.96 +5.8% 30.64 apachebench.time.elapsed_time.max 23.00 +8.7% 25.00 ± 2% apachebench.time.percent_of_cpu_this_job_got 222.89 +6.0% 236.22 apachebench.time_per_request 385478 -5.6% 363787 apachebench.transfer_rate 1.67 ± 22% -0.5 1.17 mpstat.cpu.all.irq% 1.02 +0.1 1.12 mpstat.cpu.all.sys% 0.07 ± 50% -59.4% 0.03 ± 43% perf-sched.wait_and_delay.avg.ms.pipe_read.new_sync_read.vfs_read.ksys_read 0.06 ± 55% -50.8% 0.03 ± 42% perf-sched.wait_time.avg.ms.pipe_read.new_sync_read.vfs_read.ksys_read 3037 ± 76% +195.7% 8981 ± 51% softirqs.CPU15.NET_RX 822.17 ±127% +1070.4% 9622 ±144% softirqs.CPU37.NET_RX 2388 ±102% +443.8% 12988 ± 58% softirqs.CPU67.NET_RX 11797 ± 4% +15.8% 13658 ± 4% softirqs.TIMER 12572413 ± 6% -16.9% 10443087 ± 5% cpuidle.C1.time 511677 ± 8% -12.7% 446730 ± 7% cpuidle.C1.usage 1.375e+09 ± 74% +110.9% 2.899e+09 cpuidle.C1E.time 4565230 ± 26% +46.7% 6695295 cpuidle.C1E.usage 97938 ± 27% -58.4% 40694 ± 39% cpuidle.POLL.usage 606.17 ±153% -98.5% 9.29 ±148% interrupts.CPU12.TLB:TLB_shootdowns 571.00 ±143% -96.7% 18.57 ±110% interrupts.CPU29.TLB:TLB_shootdowns 530.00 ±146% -91.1% 47.43 ±184% interrupts.CPU30.TLB:TLB_shootdowns 1657 ±190% -99.6% 6.86 ± 74% interrupts.CPU5.TLB:TLB_shootdowns 57.50 ± 67% -62.0% 21.86 ± 32% interrupts.CPU95.TLB:TLB_shootdowns 3736 ± 7% -32.5% 2521 ± 10% interrupts.RES:Rescheduling_interrupts 1792 ± 6% +11.4% 1996 turbostat.Bzy_MHz 501037 ± 8% -12.7% 437439 ± 7% turbostat.C1 0.41 ± 6% -0.1 0.32 ± 5% turbostat.C1% 4561770 ± 26% +46.7% 6690622 turbostat.C1E 1857351 ± 68% -98.2% 32984 ±139% turbostat.C6 105.14 +20.6% 126.78 turbostat.PkgWatt 1.397e+09 -4.4% 1.335e+09 perf-stat.i.branch-instructions 40257529 ± 15% -20.1% 32145859 ± 2% perf-stat.i.branch-misses 9.06 ± 57% +9.2 18.23 ± 5% perf-stat.i.cache-miss-rate% 3159646 ± 13% +223.7% 10228041 ± 11% perf-stat.i.cache-misses 4.25 ± 24% -31.2% 2.93 perf-stat.i.cpi 925.45 ± 40% -80.1% 184.12 ± 3% perf-stat.i.cpu-migrations 4096 ± 10% -68.6% 1284 ± 9% perf-stat.i.cycles-between-cache-misses 0.11 ± 68% -0.1 0.01 ± 3% perf-stat.i.dTLB-store-miss-rate% 9.43e+08 -3.9% 9.059e+08 perf-stat.i.dTLB-stores 6.644e+09 -4.3% 6.357e+09 perf-stat.i.instructions 12.04 ± 5% +22.6% 14.76 ± 9% perf-stat.i.major-faults 44.87 ± 2% -5.1% 42.58 perf-stat.i.metric.M/sec 42764 -4.5% 40848 perf-stat.i.minor-faults 70.15 ± 4% +15.5 85.61 perf-stat.i.node-load-miss-rate% 330592 ± 22% +926.0% 3391986 ± 14% perf-stat.i.node-load-misses 157887 ± 4% +36.3% 215209 ± 3% perf-stat.i.node-loads 56.69 ± 10% +24.5 81.14 perf-stat.i.node-store-miss-rate% 110581 ± 16% +786.3% 980040 ± 15% perf-stat.i.node-store-misses 120278 ± 7% -19.9% 96300 ± 5% perf-stat.i.node-stores 42776 -4.5% 40862 perf-stat.i.page-faults 3.14 ± 16% +8.9 12.04 ± 11% perf-stat.overall.cache-miss-rate% 3656 ± 8% -71.4% 1045 ± 14% perf-stat.overall.cycles-between-cache-misses 67.09 ± 6% +26.8 93.93 perf-stat.overall.node-load-miss-rate% 47.64 ± 10% +43.2 90.83 perf-stat.overall.node-store-miss-rate% 1.355e+09 -4.3% 1.296e+09 perf-stat.ps.branch-instructions 39024819 ± 15% -20.0% 31208731 ± 2% perf-stat.ps.branch-misses 3059351 ± 13% +224.2% 9917945 ± 11% perf-stat.ps.cache-misses 893.60 ± 40% -80.0% 178.29 ± 3% perf-stat.ps.cpu-migrations 9.144e+08 -3.9% 8.791e+08 perf-stat.ps.dTLB-stores 6.446e+09 -4.3% 6.17e+09 perf-stat.ps.instructions 11.65 ± 5% +22.9% 14.31 ± 9% perf-stat.ps.major-faults 41450 -4.4% 39628 perf-stat.ps.minor-faults 320695 ± 22% +925.8% 3289591 ± 14% perf-stat.ps.node-load-misses 152926 ± 4% +36.5% 208688 ± 4% perf-stat.ps.node-loads 107301 ± 16% +786.0% 950672 ± 15% perf-stat.ps.node-store-misses 116716 ± 7% -19.9% 93516 ± 5% perf-stat.ps.node-stores 41461 -4.4% 39642 perf-stat.ps.page-faults 2.80 ± 9% -0.6 2.19 ± 14% perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe 2.69 ± 10% -0.6 2.12 ± 14% perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe 0.68 ± 9% -0.4 0.33 ± 87% perf-profile.calltrace.cycles-pp.ret_from_fork 0.68 ± 9% -0.4 0.33 ± 87% perf-profile.calltrace.cycles-pp.kthread.ret_from_fork 0.83 ± 9% -0.1 0.69 ± 6% perf-profile.calltrace.cycles-pp.schedule_idle.do_idle.cpu_startup_entry.start_secondary.secondary_startup_64_no_verify 0.81 ± 9% -0.1 0.67 ± 6% perf-profile.calltrace.cycles-pp.__schedule.schedule_idle.do_idle.cpu_startup_entry.start_secondary 0.49 ± 45% +0.2 0.68 ± 7% perf-profile.calltrace.cycles-pp.tcp_recvmsg_locked.tcp_recvmsg.inet6_recvmsg.sock_read_iter.new_sync_read 0.73 ± 10% +0.3 1.05 ± 6% perf-profile.calltrace.cycles-pp.__skb_datagram_iter.skb_copy_datagram_iter.tcp_recvmsg_locked.tcp_recvmsg.inet_recvmsg 0.73 ± 10% +0.3 1.06 ± 6% perf-profile.calltrace.cycles-pp.skb_copy_datagram_iter.tcp_recvmsg_locked.tcp_recvmsg.inet_recvmsg.sock_read_iter 1.69 ± 7% +0.3 2.02 ± 6% perf-profile.calltrace.cycles-pp.copy_user_enhanced_fast_string.copyin._copy_from_iter_full.tcp_sendmsg_locked.tcp_sendmsg 2.45 ± 6% +0.4 2.80 ± 4% perf-profile.calltrace.cycles-pp.tcp_rcv_established.tcp_v4_do_rcv.tcp_v4_rcv.ip_protocol_deliver_rcu.ip_local_deliver_finish 1.98 ± 6% +0.4 2.34 ± 6% perf-profile.calltrace.cycles-pp.copyin._copy_from_iter_full.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg 2.46 ± 6% +0.4 2.82 ± 4% perf-profile.calltrace.cycles-pp.tcp_v4_do_rcv.tcp_v4_rcv.ip_protocol_deliver_rcu.ip_local_deliver_finish.ip_local_deliver 2.00 ± 6% +0.4 2.37 ± 6% perf-profile.calltrace.cycles-pp._copy_from_iter_full.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg.sock_write_iter 0.52 ± 45% +0.4 0.88 ± 7% perf-profile.calltrace.cycles-pp._copy_to_iter.__skb_datagram_iter.skb_copy_datagram_iter.tcp_recvmsg_locked.tcp_recvmsg 0.49 ± 45% +0.4 0.86 ± 7% perf-profile.calltrace.cycles-pp.copyout._copy_to_iter.__skb_datagram_iter.skb_copy_datagram_iter.tcp_recvmsg_locked 0.48 ± 45% +0.4 0.85 ± 8% perf-profile.calltrace.cycles-pp.copy_user_enhanced_fast_string.copyout._copy_to_iter.__skb_datagram_iter.skb_copy_datagram_iter 1.51 ± 9% +0.4 1.90 ± 7% perf-profile.calltrace.cycles-pp.read 1.43 ± 9% +0.4 1.82 ± 7% perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.read 1.40 ± 10% +0.4 1.79 ± 7% perf-profile.calltrace.cycles-pp.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe.read 1.41 ± 9% +0.4 1.80 ± 7% perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.read 1.00 ± 10% +0.4 1.40 ± 6% perf-profile.calltrace.cycles-pp.tcp_recvmsg_locked.tcp_recvmsg.inet_recvmsg.sock_read_iter.new_sync_read 1.34 ± 10% +0.4 1.74 ± 8% perf-profile.calltrace.cycles-pp.vfs_read.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe.read 1.11 ± 10% +0.4 1.51 ± 7% perf-profile.calltrace.cycles-pp.tcp_recvmsg.inet_recvmsg.sock_read_iter.new_sync_read.vfs_read 1.14 ± 10% +0.4 1.54 ± 7% perf-profile.calltrace.cycles-pp.inet_recvmsg.sock_read_iter.new_sync_read.vfs_read.ksys_read 3.02 ± 7% +0.4 3.46 ± 4% perf-profile.calltrace.cycles-pp.ip_local_deliver_finish.ip_local_deliver.ip_rcv.__netif_receive_skb_one_core.process_backlog 2.95 ± 7% +0.4 3.40 ± 4% perf-profile.calltrace.cycles-pp.tcp_v4_rcv.ip_protocol_deliver_rcu.ip_local_deliver_finish.ip_local_deliver.ip_rcv 3.00 ± 7% +0.4 3.44 ± 4% perf-profile.calltrace.cycles-pp.ip_protocol_deliver_rcu.ip_local_deliver_finish.ip_local_deliver.ip_rcv.__netif_receive_skb_one_core 0.20 ±141% +0.4 0.65 ± 12% perf-profile.calltrace.cycles-pp.ktime_get.clockevents_program_event.hrtimer_interrupt.__sysvec_apic_timer_interrupt.sysvec_apic_timer_interrupt 3.34 ± 6% +0.4 3.79 ± 4% perf-profile.calltrace.cycles-pp.process_backlog.__napi_poll.net_rx_action.__softirqentry_text_start.do_softirq 3.35 ± 6% +0.4 3.80 ± 4% perf-profile.calltrace.cycles-pp.__napi_poll.net_rx_action.__softirqentry_text_start.do_softirq.__local_bh_enable_ip 3.03 ± 7% +0.4 3.48 ± 4% perf-profile.calltrace.cycles-pp.ip_local_deliver.ip_rcv.__netif_receive_skb_one_core.process_backlog.__napi_poll 3.70 ± 6% +0.5 4.15 ± 4% perf-profile.calltrace.cycles-pp.__local_bh_enable_ip.ip_finish_output2.ip_output.__ip_queue_xmit.__tcp_transmit_skb 3.66 ± 6% +0.5 4.12 ± 4% perf-profile.calltrace.cycles-pp.do_softirq.__local_bh_enable_ip.ip_finish_output2.ip_output.__ip_queue_xmit 3.13 ± 6% +0.5 3.59 ± 4% perf-profile.calltrace.cycles-pp.ip_rcv.__netif_receive_skb_one_core.process_backlog.__napi_poll.net_rx_action 3.23 ± 6% +0.5 3.69 ± 4% perf-profile.calltrace.cycles-pp.__netif_receive_skb_one_core.process_backlog.__napi_poll.net_rx_action.__softirqentry_text_start 2.20 ± 7% +0.5 2.70 ± 6% perf-profile.calltrace.cycles-pp.new_sync_read.vfs_read.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe 2.13 ± 7% +0.5 2.63 ± 5% perf-profile.calltrace.cycles-pp.sock_read_iter.new_sync_read.vfs_read.ksys_read.do_syscall_64 1.79 ± 6% -0.2 1.55 ± 5% perf-profile.children.cycles-pp.__schedule 0.76 ± 10% -0.2 0.53 ± 15% perf-profile.children.cycles-pp.console_unlock 0.76 ± 10% -0.2 0.54 ± 14% perf-profile.children.cycles-pp.vprintk_emit 0.64 ± 9% -0.2 0.44 ± 14% perf-profile.children.cycles-pp.serial8250_console_write 0.61 ± 9% -0.2 0.41 ± 15% perf-profile.children.cycles-pp.uart_console_write 0.59 ± 9% -0.2 0.40 ± 14% perf-profile.children.cycles-pp.wait_for_xmitr 0.57 ± 10% -0.2 0.38 ± 15% perf-profile.children.cycles-pp.serial8250_console_putchar 0.50 ± 11% -0.2 0.34 ± 13% perf-profile.children.cycles-pp.io_serial_in 0.53 ± 16% -0.2 0.36 ± 23% perf-profile.children.cycles-pp.devkmsg_write.cold 0.53 ± 16% -0.2 0.36 ± 23% perf-profile.children.cycles-pp.devkmsg_emit 0.68 ± 9% -0.2 0.52 ± 14% perf-profile.children.cycles-pp.ret_from_fork 0.68 ± 9% -0.2 0.52 ± 14% perf-profile.children.cycles-pp.kthread 0.61 ± 11% -0.2 0.46 ± 17% perf-profile.children.cycles-pp.worker_thread 0.61 ± 11% -0.2 0.46 ± 18% perf-profile.children.cycles-pp.process_one_work 0.60 ± 11% -0.2 0.45 ± 19% perf-profile.children.cycles-pp.drm_fb_helper_damage_work 0.60 ± 11% -0.1 0.45 ± 19% perf-profile.children.cycles-pp.memcpy_toio 0.84 ± 8% -0.1 0.70 ± 6% perf-profile.children.cycles-pp.schedule_idle 1.25 ± 6% -0.1 1.12 ± 5% perf-profile.children.cycles-pp.schedule_hrtimeout_range_clock 0.18 ± 31% -0.1 0.09 ± 9% perf-profile.children.cycles-pp.rcu_idle_exit 0.59 ± 5% -0.1 0.52 ± 5% perf-profile.children.cycles-pp.unmap_page_range 0.35 ± 5% -0.1 0.28 ± 7% perf-profile.children.cycles-pp._raw_spin_lock 0.41 ± 5% -0.1 0.34 ± 7% perf-profile.children.cycles-pp.dequeue_task_fair 0.21 ± 11% -0.1 0.15 ± 13% perf-profile.children.cycles-pp.set_next_entity 0.65 ± 2% -0.1 0.58 ± 5% perf-profile.children.cycles-pp.unmap_vmas 0.13 ± 29% -0.1 0.07 ± 11% perf-profile.children.cycles-pp.rcu_eqs_exit 0.30 ± 7% -0.1 0.25 ± 6% perf-profile.children.cycles-pp.asm_sysvec_call_function 0.21 ± 14% -0.1 0.16 ± 8% perf-profile.children.cycles-pp.__libc_fork 0.20 ± 16% -0.1 0.15 ± 10% perf-profile.children.cycles-pp.__do_sys_clone 0.20 ± 16% -0.1 0.15 ± 10% perf-profile.children.cycles-pp.kernel_clone 0.18 ± 17% -0.1 0.13 ± 13% perf-profile.children.cycles-pp.dup_mmap 0.35 ± 9% -0.1 0.29 ± 8% perf-profile.children.cycles-pp.pick_next_task_fair 0.18 ± 16% -0.1 0.13 ± 14% perf-profile.children.cycles-pp.dup_mm 0.19 ± 15% -0.1 0.14 ± 9% perf-profile.children.cycles-pp.copy_process 0.12 ± 21% -0.0 0.07 ± 12% perf-profile.children.cycles-pp.get_next_timer_interrupt 0.34 ± 7% -0.0 0.29 ± 7% perf-profile.children.cycles-pp.dequeue_entity 0.11 ± 20% -0.0 0.07 ± 13% perf-profile.children.cycles-pp.hrtimer_next_event_without 0.16 ± 5% -0.0 0.12 ± 8% perf-profile.children.cycles-pp.__sysvec_call_function 0.23 ± 4% -0.0 0.19 ± 5% perf-profile.children.cycles-pp.sysvec_call_function 0.10 ± 12% -0.0 0.07 ± 17% perf-profile.children.cycles-pp.sk_filter_trim_cap 0.08 ± 27% -0.0 0.06 ± 13% perf-profile.children.cycles-pp._find_next_bit 0.07 ± 19% +0.0 0.10 ± 13% perf-profile.children.cycles-pp.skb_entail 0.16 ± 5% +0.0 0.19 ± 12% perf-profile.children.cycles-pp.flush_smp_call_function_queue 0.19 ± 9% +0.0 0.23 ± 7% perf-profile.children.cycles-pp.common_file_perm 0.07 ± 18% +0.0 0.11 ± 11% perf-profile.children.cycles-pp.sk_page_frag_refill 0.07 ± 14% +0.0 0.11 ± 11% perf-profile.children.cycles-pp.skb_page_frag_refill 0.10 ± 14% +0.1 0.15 ± 16% perf-profile.children.cycles-pp.__skb_clone 0.21 ± 13% +0.1 0.26 ± 7% perf-profile.children.cycles-pp.__inet_lookup_established 0.02 ±142% +0.1 0.07 ± 26% perf-profile.children.cycles-pp.lockref_get_not_dead 0.02 ±141% +0.1 0.07 ± 9% perf-profile.children.cycles-pp.tcp_ack_update_rtt 0.03 ±102% +0.1 0.09 ± 20% perf-profile.children.cycles-pp.cpuacct_charge 0.12 ± 18% +0.1 0.18 ± 5% perf-profile.children.cycles-pp.kfree 0.13 ± 12% +0.1 0.20 ± 9% perf-profile.children.cycles-pp.__slab_free 0.00 +0.1 0.07 ± 20% perf-profile.children.cycles-pp.llist_reverse_order 0.37 ± 8% +0.1 0.45 ± 10% perf-profile.children.cycles-pp.kmem_cache_free 0.01 ±223% +0.1 0.09 ± 16% perf-profile.children.cycles-pp.llist_add_batch 0.40 ± 8% +0.1 0.48 ± 9% perf-profile.children.cycles-pp.sk_stream_alloc_skb 0.15 ± 8% +0.1 0.23 ± 14% perf-profile.children.cycles-pp.rcu_do_batch 0.38 ± 8% +0.1 0.47 ± 8% perf-profile.children.cycles-pp.__alloc_skb 0.20 ± 6% +0.1 0.30 ± 12% perf-profile.children.cycles-pp.rcu_core 0.00 +0.1 0.12 ± 20% perf-profile.children.cycles-pp.ttwu_queue_wakelist 0.55 ± 5% +0.1 0.68 ± 9% perf-profile.children.cycles-pp.__kfree_skb 0.69 ± 4% +0.1 0.83 ± 6% perf-profile.children.cycles-pp.tcp_clean_rtx_queue 0.98 ± 5% +0.2 1.13 ± 5% perf-profile.children.cycles-pp.tcp_ack 0.77 ± 15% +0.2 0.97 ± 9% perf-profile.children.cycles-pp.clockevents_program_event 0.00 +0.2 0.23 ± 18% perf-profile.children.cycles-pp.sched_ttwu_pending 1.30 ± 14% +0.3 1.59 ± 6% perf-profile.children.cycles-pp.ktime_get 2.39 ± 7% +0.3 2.69 ± 6% perf-profile.children.cycles-pp.copyin 0.69 ± 10% +0.3 1.00 ± 6% perf-profile.children.cycles-pp._copy_to_iter 0.65 ± 9% +0.3 0.96 ± 6% perf-profile.children.cycles-pp.copyout 0.00 +0.3 0.31 ± 20% perf-profile.children.cycles-pp.flush_smp_call_function_from_idle 2.40 ± 7% +0.3 2.71 ± 5% perf-profile.children.cycles-pp._copy_from_iter_full 0.98 ± 9% +0.4 1.34 ± 6% perf-profile.children.cycles-pp.__skb_datagram_iter 0.98 ± 9% +0.4 1.35 ± 6% perf-profile.children.cycles-pp.skb_copy_datagram_iter 1.54 ± 10% +0.4 1.92 ± 8% perf-profile.children.cycles-pp.read 1.14 ± 10% +0.4 1.54 ± 7% perf-profile.children.cycles-pp.inet_recvmsg 3.20 ± 7% +0.4 3.61 ± 3% perf-profile.children.cycles-pp.tcp_v4_rcv 3.25 ± 7% +0.4 3.66 ± 3% perf-profile.children.cycles-pp.ip_protocol_deliver_rcu 3.26 ± 7% +0.4 3.68 ± 3% perf-profile.children.cycles-pp.ip_local_deliver_finish 3.28 ± 7% +0.4 3.70 ± 3% perf-profile.children.cycles-pp.ip_local_deliver 3.51 ± 7% +0.4 3.93 ± 4% perf-profile.children.cycles-pp.__netif_receive_skb_one_core 3.39 ± 7% +0.4 3.82 ± 4% perf-profile.children.cycles-pp.ip_rcv 2.35 ± 7% +0.5 2.83 ± 6% perf-profile.children.cycles-pp.new_sync_read 2.69 ± 6% +0.5 3.17 ± 5% perf-profile.children.cycles-pp.vfs_read 2.79 ± 6% +0.5 3.27 ± 5% perf-profile.children.cycles-pp.ksys_read 2.26 ± 7% +0.5 2.75 ± 6% perf-profile.children.cycles-pp.sock_read_iter 1.98 ± 7% +0.5 2.47 ± 5% perf-profile.children.cycles-pp.tcp_recvmsg 1.67 ± 7% +0.5 2.17 ± 6% perf-profile.children.cycles-pp.tcp_recvmsg_locked 3.10 ± 7% +0.6 3.72 ± 6% perf-profile.children.cycles-pp.copy_user_enhanced_fast_string 9.78 ± 7% +1.0 10.78 ± 4% perf-profile.children.cycles-pp.sock_write_iter 9.71 ± 7% +1.0 10.72 ± 4% perf-profile.children.cycles-pp.sock_sendmsg 9.56 ± 7% +1.0 10.58 ± 4% perf-profile.children.cycles-pp.tcp_sendmsg 9.41 ± 7% +1.0 10.43 ± 4% perf-profile.children.cycles-pp.tcp_sendmsg_locked 0.50 ± 11% -0.2 0.34 ± 13% perf-profile.self.cycles-pp.io_serial_in 0.59 ± 11% -0.1 0.45 ± 19% perf-profile.self.cycles-pp.memcpy_toio 0.16 ± 15% -0.1 0.11 ± 16% perf-profile.self.cycles-pp.update_rq_clock 0.11 ± 14% -0.0 0.07 ± 15% perf-profile.self.cycles-pp.set_next_entity 0.32 ± 8% -0.0 0.28 ± 10% perf-profile.self.cycles-pp.__schedule 0.14 ± 11% -0.0 0.09 ± 12% perf-profile.self.cycles-pp.update_load_avg 0.29 ± 14% -0.0 0.25 ± 4% perf-profile.self.cycles-pp.native_sched_clock 0.17 ± 4% -0.0 0.15 ± 5% perf-profile.self.cycles-pp.apr_brigade_cleanup 0.10 ± 11% -0.0 0.08 ± 17% perf-profile.self.cycles-pp.arch_scale_freq_tick 0.17 ± 8% -0.0 0.15 ± 7% perf-profile.self.cycles-pp.ap_process_request_internal 0.07 ± 9% -0.0 0.05 ± 9% perf-profile.self.cycles-pp._find_next_bit 0.16 ± 6% +0.0 0.19 ± 8% perf-profile.self.cycles-pp.common_file_perm 0.07 ± 19% +0.0 0.10 ± 10% perf-profile.self.cycles-pp.sock_def_readable 0.04 ± 71% +0.0 0.07 ± 10% perf-profile.self.cycles-pp.tcp_rcv_space_adjust 0.07 ± 11% +0.0 0.11 ± 13% perf-profile.self.cycles-pp.poll_schedule_timeout 0.16 ± 8% +0.0 0.20 ± 8% perf-profile.self.cycles-pp.__check_object_size 0.05 ± 46% +0.0 0.09 ± 13% perf-profile.self.cycles-pp.skb_entail 0.07 ± 14% +0.0 0.11 ± 13% perf-profile.self.cycles-pp.skb_page_frag_refill 0.02 ±141% +0.0 0.06 ± 11% perf-profile.self.cycles-pp.__alloc_skb 0.07 ± 46% +0.1 0.12 ± 13% perf-profile.self.cycles-pp.__skb_clone 0.11 ± 14% +0.1 0.17 ± 14% perf-profile.self.cycles-pp.__ksize 0.12 ± 18% +0.1 0.17 ± 8% perf-profile.self.cycles-pp.kfree 0.02 ±142% +0.1 0.07 ± 26% perf-profile.self.cycles-pp.lockref_get_not_dead 0.18 ± 17% +0.1 0.24 ± 8% perf-profile.self.cycles-pp.__inet_lookup_established 0.00 +0.1 0.06 ± 14% perf-profile.self.cycles-pp.try_to_wake_up 0.03 ±102% +0.1 0.09 ± 20% perf-profile.self.cycles-pp.cpuacct_charge 0.01 ±223% +0.1 0.07 ± 15% perf-profile.self.cycles-pp.tcp_ack_update_rtt 0.20 ± 7% +0.1 0.26 ± 12% perf-profile.self.cycles-pp.kmem_cache_free 0.13 ± 12% +0.1 0.20 ± 9% perf-profile.self.cycles-pp.__slab_free 0.00 +0.1 0.07 ± 20% perf-profile.self.cycles-pp.llist_reverse_order 0.12 ± 11% +0.1 0.20 ± 14% perf-profile.self.cycles-pp.tcp_rcv_established 0.01 ±223% +0.1 0.09 ± 16% perf-profile.self.cycles-pp.llist_add_batch 0.26 ± 14% +0.1 0.34 ± 3% perf-profile.self.cycles-pp.tcp_recvmsg_locked 0.30 ± 10% +0.1 0.41 ± 8% perf-profile.self.cycles-pp.tcp_sendmsg_locked 0.98 ± 18% +0.3 1.31 ± 8% perf-profile.self.cycles-pp.ktime_get 1.08 ± 18% +0.4 1.48 ± 9% perf-profile.self.cycles-pp.cpuidle_enter_state 1.23 ± 22% +0.5 1.77 ± 12% perf-profile.self.cycles-pp.menu_select 1.86 ± 7% +0.6 2.46 ± 7% perf-profile.self.cycles-pp.copy_user_enhanced_fast_string *************************************************************************************************** lkp-csl-2ap3: 192 threads 4 sockets Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 192G memory ========================================================================================= cluster/compiler/cpufreq_governor/ip/kconfig/nr_threads/rootfs/runtime/tbox_group/test/testcase/ucode: cs-localhost/gcc-9/performance/ipv4/x86_64-rhel-8.3/1/debian-10.4-x86_64-20200603.cgz/300s/lkp-csl-2ap3/UDP_STREAM/netperf/0x5003006 commit: 2ea46c6fc9 ("cpumask/hotplug: Fix cpu_dying() state tracking") 5f94d1b650 ("sched/fair: don't use waker's cpu if the waker of sync wake-up is interrupt") 2ea46c6fc9452ac1 5f94d1b650d14e01f383e3d02e4 ---------------- --------------------------- %stddev %change %stddev \ | \ 62544 -52.4% 29784 ± 15% netperf.Throughput_Mbps 62544 -52.4% 29784 ± 15% netperf.Throughput_total_Mbps 998.17 ± 5% -16.2% 836.00 ± 10% netperf.time.minor_page_faults 81.17 +9.1% 88.57 netperf.time.percent_of_cpu_this_job_got 242.61 +9.5% 265.75 netperf.time.system_time 35803969 -52.4% 17050380 ± 15% netperf.workload 0.19 ± 6% -0.0 0.14 ± 5% mpstat.cpu.all.soft% 0.04 -0.0 0.04 ± 2% mpstat.cpu.all.usr% 1568380 ±162% -88.6% 178452 ± 11% numa-numastat.node3.local_node 1640558 ±153% -84.3% 257114 numa-numastat.node3.numa_hit 1572364 ± 2% -14.6% 1342693 vmstat.memory.cache 237206 -51.8% 114337 ± 15% vmstat.system.cs 8917350 ± 19% +840.2% 83837786 ± 13% cpuidle.C1.time 1687718 ± 18% +734.3% 14080429 ± 11% cpuidle.C1.usage 72623238 -89.0% 8015009 ±119% cpuidle.POLL.time 33405975 -90.8% 3070283 ±139% cpuidle.POLL.usage 427986 ± 7% -49.9% 214579 ± 2% numa-meminfo.node3.Active 427986 ± 7% -49.9% 214579 ± 2% numa-meminfo.node3.Active(anon) 702896 ± 5% -32.6% 473640 ± 3% numa-meminfo.node3.FilePages 463902 ± 7% -49.1% 235917 ± 2% numa-meminfo.node3.Shmem 106952 ± 7% -49.8% 53679 ± 2% numa-vmstat.node3.nr_active_anon 175755 ± 5% -32.6% 118442 ± 3% numa-vmstat.node3.nr_file_pages 116007 ± 7% -49.1% 59011 ± 2% numa-vmstat.node3.nr_shmem 106952 ± 7% -49.8% 53679 ± 2% numa-vmstat.node3.nr_zone_active_anon 433337 ± 7% -49.0% 220837 ± 2% meminfo.Active 433337 ± 7% -49.0% 220837 ± 2% meminfo.Active(anon) 1452704 ± 2% -15.7% 1223905 meminfo.Cached 841896 ± 3% -26.8% 616582 meminfo.Committed_AS 45250 -9.6% 40886 ± 2% meminfo.Mapped 483539 ± 7% -47.3% 254634 ± 2% meminfo.Shmem 8213 ± 16% -27.5% 5953 ± 10% softirqs.CPU12.RCU 6993 ± 23% -30.1% 4890 ± 7% softirqs.CPU124.RCU 8490 ± 15% -33.8% 5623 ± 15% softirqs.CPU190.RCU 8545 ± 14% -29.9% 5987 ± 12% softirqs.CPU191.RCU 8207 ± 14% -31.6% 5614 ± 11% softirqs.CPU45.RCU 8880 ± 16% -32.9% 5962 ± 12% softirqs.CPU51.RCU 8895 ± 11% -34.1% 5859 ± 14% softirqs.CPU83.RCU 8708 ± 20% -35.2% 5639 ± 12% softirqs.CPU95.RCU 17915040 -52.4% 8533057 ± 15% softirqs.NET_RX 1447713 ± 7% -26.6% 1062814 ± 5% softirqs.RCU 107830 ± 7% -48.8% 55213 ± 2% proc-vmstat.nr_active_anon 362869 ± 2% -15.7% 305817 proc-vmstat.nr_file_pages 79042 -5.3% 74879 proc-vmstat.nr_inactive_anon 11592 -11.7% 10240 ± 2% proc-vmstat.nr_mapped 120578 ± 7% -47.3% 63500 ± 2% proc-vmstat.nr_shmem 107830 ± 7% -48.8% 55213 ± 2% proc-vmstat.nr_zone_active_anon 79042 -5.3% 74879 proc-vmstat.nr_zone_inactive_anon 37297024 -50.6% 18413448 ± 14% proc-vmstat.numa_hit 37037152 -51.0% 18153607 ± 14% proc-vmstat.numa_local 291363 ± 7% -50.3% 144772 ± 2% proc-vmstat.pgactivate 1.147e+09 -52.3% 5.468e+08 ± 15% proc-vmstat.pgalloc_normal 1.147e+09 -52.3% 5.468e+08 ± 15% proc-vmstat.pgfree 0.02 ± 27% -71.7% 0.01 ± 6% perf-sched.sch_delay.avg.ms.__x64_sys_pause.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown] 0.02 ± 21% -72.3% 0.00 ± 14% perf-sched.sch_delay.avg.ms.do_nanosleep.hrtimer_nanosleep.__x64_sys_nanosleep.do_syscall_64 0.01 ± 24% -54.2% 0.00 ± 13% perf-sched.sch_delay.avg.ms.do_task_dead.do_exit.do_group_exit.__x64_sys_exit_group.do_syscall_64 0.02 ± 26% -53.5% 0.01 ± 37% perf-sched.sch_delay.avg.ms.schedule_hrtimeout_range_clock.ep_poll.do_epoll_wait.__x64_sys_epoll_wait 0.02 ± 47% -63.7% 0.01 ± 23% perf-sched.sch_delay.avg.ms.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0.do_select 0.00 ±223% +2300.0% 0.00 perf-sched.sch_delay.avg.ms.schedule_timeout.__skb_wait_for_more_packets.__skb_recv_udp.udp_recvmsg 0.01 ± 11% -31.2% 0.01 ± 11% perf-sched.sch_delay.avg.ms.worker_thread.kthread.ret_from_fork 0.03 ± 44% -70.5% 0.01 ± 13% perf-sched.sch_delay.max.ms.__x64_sys_pause.do_syscall_64.entry_SYSCALL_64_after_hwframe.[unknown] 0.03 ± 27% -67.1% 0.01 ± 53% perf-sched.sch_delay.max.ms.do_nanosleep.hrtimer_nanosleep.__x64_sys_nanosleep.do_syscall_64 0.04 ± 89% -75.9% 0.01 ± 10% perf-sched.sch_delay.max.ms.exit_to_user_mode_prepare.syscall_exit_to_user_mode.entry_SYSCALL_64_after_hwframe.[unknown] 0.10 ± 57% -59.0% 0.04 ±104% perf-sched.sch_delay.max.ms.pipe_read.new_sync_read.vfs_read.ksys_read 0.04 ± 62% -74.1% 0.01 ± 35% perf-sched.sch_delay.max.ms.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0.do_select 0.03 ± 52% -55.0% 0.02 ± 33% perf-sched.sch_delay.max.ms.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0.do_sys_poll 0.04 ± 65% +9892.1% 4.00 ± 93% perf-sched.sch_delay.max.ms.schedule_timeout.__skb_wait_for_more_packets.__skb_recv_udp.udp_recvmsg 0.00 ±223% +2300.0% 0.00 perf-sched.total_sch_delay.average.ms 2.53 ± 8% +97.1% 5.00 ± 2% perf-sched.total_wait_and_delay.average.ms 950222 ± 6% -50.3% 472509 perf-sched.total_wait_and_delay.count.ms 2.53 ± 8% +97.0% 4.99 ± 2% perf-sched.total_wait_time.average.ms 4.28 -100.0% 0.00 perf-sched.wait_and_delay.avg.ms.preempt_schedule_common.__cond_resched.wait_for_completion.affine_move_task.__set_cpus_allowed_ptr 32.30 ± 8% +96.7% 63.54 ± 3% perf-sched.wait_and_delay.avg.ms.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0.do_sys_poll 0.00 ± 17% +394.5% 0.01 ± 4% perf-sched.wait_and_delay.avg.ms.schedule_timeout.__skb_wait_for_more_packets.__skb_recv_udp.udp_recvmsg 2112 -100.0% 0.00 perf-sched.wait_and_delay.count.preempt_schedule_common.__cond_resched.wait_for_completion.affine_move_task.__set_cpus_allowed_ptr 556.83 ± 6% -47.8% 290.43 ± 2% perf-sched.wait_and_delay.count.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0.do_sys_poll 938377 ± 6% -50.9% 460959 perf-sched.wait_and_delay.count.schedule_timeout.__skb_wait_for_more_packets.__skb_recv_udp.udp_recvmsg 1000 -100.0% 0.00 perf-sched.wait_and_delay.max.ms.preempt_schedule_common.__cond_resched.wait_for_completion.affine_move_task.__set_cpus_allowed_ptr 0.07 ± 16% +5743.6% 4.10 ± 90% perf-sched.wait_and_delay.max.ms.schedule_timeout.__skb_wait_for_more_packets.__skb_recv_udp.udp_recvmsg 129.86 ± 73% -63.7% 47.15 ±135% perf-sched.wait_and_delay.max.ms.schedule_timeout.rcu_gp_kthread.kthread.ret_from_fork 0.75 ± 2% -9.7% 0.68 perf-sched.wait_time.avg.ms.do_wait.kernel_wait4.__do_sys_wait4.do_syscall_64 32.30 ± 8% +96.7% 63.54 ± 3% perf-sched.wait_time.avg.ms.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0.do_sys_poll 0.00 ± 17% +209.9% 0.01 ± 6% perf-sched.wait_time.avg.ms.schedule_timeout.__skb_wait_for_more_packets.__skb_recv_udp.udp_recvmsg 8.343e+08 -32.4% 5.641e+08 ± 7% perf-stat.i.branch-instructions 1.84 ± 24% +58.5 60.31 ± 27% perf-stat.i.cache-miss-rate% 4879389 ± 5% +1618.4% 83848142 ± 13% perf-stat.i.cache-misses 2.849e+08 ± 15% -44.8% 1.573e+08 ± 25% perf-stat.i.cache-references 238858 -51.8% 115114 ± 15% perf-stat.i.context-switches 3.79 ± 3% +67.9% 6.37 ± 5% perf-stat.i.cpi 1.499e+10 ± 3% +10.2% 1.652e+10 ± 2% perf-stat.i.cpu-cycles 3190 ± 8% -86.5% 430.75 ± 96% perf-stat.i.cycles-between-cache-misses 1.106e+09 -31.9% 7.533e+08 ± 7% perf-stat.i.dTLB-loads 6.313e+08 -33.1% 4.222e+08 ± 8% perf-stat.i.dTLB-stores 67.75 ± 6% -13.5 54.27 ± 7% perf-stat.i.iTLB-load-miss-rate% 6844433 -34.7% 4466144 ± 7% perf-stat.i.iTLB-load-misses 4.07e+09 -32.3% 2.757e+09 ± 7% perf-stat.i.instructions 0.27 ± 3% -38.6% 0.17 ± 8% perf-stat.i.ipc 0.08 ± 3% +10.2% 0.09 ± 2% perf-stat.i.metric.GHz 14.90 -31.8% 10.16 ± 7% perf-stat.i.metric.M/sec 88.72 ± 3% +9.7 98.42 ± 2% perf-stat.i.node-load-miss-rate% 390842 ± 54% +7043.8% 27921170 ± 13% perf-stat.i.node-load-misses 53149 ± 20% +140.2% 127659 ± 20% perf-stat.i.node-loads 84.06 ± 10% +13.9 97.91 ± 3% perf-stat.i.node-store-miss-rate% 108685 ± 5% +20162.1% 22022000 ± 13% perf-stat.i.node-store-misses 1.78 ± 23% +55.8 57.59 ± 30% perf-stat.overall.cache-miss-rate% 3.68 ± 3% +63.4% 6.02 ± 6% perf-stat.overall.cpi 3086 ± 8% -93.5% 201.38 ± 16% perf-stat.overall.cycles-between-cache-misses 67.82 ± 6% -13.3 54.47 ± 8% perf-stat.overall.iTLB-load-miss-rate% 0.27 ± 3% -38.6% 0.17 ± 7% perf-stat.overall.ipc 86.32 ± 4% +13.2 99.55 perf-stat.overall.node-load-miss-rate% 79.67 ± 11% +20.2 99.91 perf-stat.overall.node-store-miss-rate% 34248 +43.8% 49254 ± 8% perf-stat.overall.path-length 8.317e+08 -32.4% 5.625e+08 ± 7% perf-stat.ps.branch-instructions 4863939 ± 5% +1617.8% 83552434 ± 13% perf-stat.ps.cache-misses 2.839e+08 ± 15% -44.8% 1.568e+08 ± 25% perf-stat.ps.cache-references 238042 -51.8% 114736 ± 15% perf-stat.ps.context-switches 1.494e+10 ± 3% +10.2% 1.646e+10 ± 2% perf-stat.ps.cpu-cycles 1.102e+09 -31.9% 7.51e+08 ± 7% perf-stat.ps.dTLB-loads 6.293e+08 -33.1% 4.209e+08 ± 8% perf-stat.ps.dTLB-stores 6821496 -34.7% 4451472 ± 7% perf-stat.ps.iTLB-load-misses 4.057e+09 -32.3% 2.749e+09 ± 7% perf-stat.ps.instructions 389775 ± 54% +7038.0% 27822357 ± 13% perf-stat.ps.node-load-misses 53006 ± 20% +140.1% 127264 ± 20% perf-stat.ps.node-loads 108429 ± 5% +20137.9% 21943845 ± 13% perf-stat.ps.node-store-misses 1.226e+12 -32.3% 8.298e+11 ± 7% perf-stat.total.instructions 838643 ± 8% -67.5% 272512 ± 11% interrupts.CAL:Function_call_interrupts 67.33 ± 32% -60.3% 26.71 ± 36% interrupts.CPU0.RES:Rescheduling_interrupts 108.33 ± 36% +93.3% 209.43 ± 15% interrupts.CPU1.NMI:Non-maskable_interrupts 108.33 ± 36% +93.3% 209.43 ± 15% interrupts.CPU1.PMI:Performance_monitoring_interrupts 114.33 ± 46% +84.8% 211.29 ± 15% interrupts.CPU10.NMI:Non-maskable_interrupts 114.33 ± 46% +84.8% 211.29 ± 15% interrupts.CPU10.PMI:Performance_monitoring_interrupts 102.00 ± 18% +200.4% 306.43 ± 83% interrupts.CPU100.NMI:Non-maskable_interrupts 102.00 ± 18% +200.4% 306.43 ± 83% interrupts.CPU100.PMI:Performance_monitoring_interrupts 117.50 ± 22% +648.2% 879.14 ±122% interrupts.CPU101.NMI:Non-maskable_interrupts 117.50 ± 22% +648.2% 879.14 ±122% interrupts.CPU101.PMI:Performance_monitoring_interrupts 117.00 ± 24% +67.2% 195.57 ± 20% interrupts.CPU103.NMI:Non-maskable_interrupts 117.00 ± 24% +67.2% 195.57 ± 20% interrupts.CPU103.PMI:Performance_monitoring_interrupts 98.83 ± 32% +799.3% 888.86 ±184% interrupts.CPU104.NMI:Non-maskable_interrupts 98.83 ± 32% +799.3% 888.86 ±184% interrupts.CPU104.PMI:Performance_monitoring_interrupts 111.50 ± 23% +87.7% 209.29 ± 16% interrupts.CPU105.NMI:Non-maskable_interrupts 111.50 ± 23% +87.7% 209.29 ± 16% interrupts.CPU105.PMI:Performance_monitoring_interrupts 104.83 ± 34% +565.5% 697.71 ±133% interrupts.CPU112.NMI:Non-maskable_interrupts 104.83 ± 34% +565.5% 697.71 ±133% interrupts.CPU112.PMI:Performance_monitoring_interrupts 104.50 ± 36% +64.6% 172.00 ± 24% interrupts.CPU129.NMI:Non-maskable_interrupts 104.50 ± 36% +64.6% 172.00 ± 24% interrupts.CPU129.PMI:Performance_monitoring_interrupts 113.17 ± 25% +142.8% 274.71 ± 91% interrupts.CPU142.NMI:Non-maskable_interrupts 113.17 ± 25% +142.8% 274.71 ± 91% interrupts.CPU142.PMI:Performance_monitoring_interrupts 222.33 ±214% -98.2% 4.00 ± 61% interrupts.CPU145.RES:Rescheduling_interrupts 119.33 ± 32% +1189.9% 1539 ±187% interrupts.CPU16.NMI:Non-maskable_interrupts 119.33 ± 32% +1189.9% 1539 ±187% interrupts.CPU16.PMI:Performance_monitoring_interrupts 624.33 ±171% -82.9% 106.71 ± 24% interrupts.CPU163.NMI:Non-maskable_interrupts 624.33 ±171% -82.9% 106.71 ± 24% interrupts.CPU163.PMI:Performance_monitoring_interrupts 128.50 ± 18% +40.0% 179.86 ± 24% interrupts.CPU2.NMI:Non-maskable_interrupts 128.50 ± 18% +40.0% 179.86 ± 24% interrupts.CPU2.PMI:Performance_monitoring_interrupts 388.33 ±210% -97.8% 8.71 ± 62% interrupts.CPU3.RES:Rescheduling_interrupts 94.50 ± 37% +102.0% 190.86 ± 24% interrupts.CPU4.NMI:Non-maskable_interrupts 94.50 ± 37% +102.0% 190.86 ± 24% interrupts.CPU4.PMI:Performance_monitoring_interrupts 105.00 ± 32% +1495.6% 1675 ±173% interrupts.CPU5.NMI:Non-maskable_interrupts 105.00 ± 32% +1495.6% 1675 ±173% interrupts.CPU5.PMI:Performance_monitoring_interrupts 119.83 ± 35% +60.6% 192.43 ± 21% interrupts.CPU6.NMI:Non-maskable_interrupts 119.83 ± 35% +60.6% 192.43 ± 21% interrupts.CPU6.PMI:Performance_monitoring_interrupts 95.00 ± 41% +968.4% 1015 ±200% interrupts.CPU8.NMI:Non-maskable_interrupts 95.00 ± 41% +968.4% 1015 ±200% interrupts.CPU8.PMI:Performance_monitoring_interrupts 97.50 ± 48% +96.9% 192.00 ± 22% interrupts.CPU9.NMI:Non-maskable_interrupts 97.50 ± 48% +96.9% 192.00 ± 22% interrupts.CPU9.PMI:Performance_monitoring_interrupts 123.17 ± 29% +71.1% 210.71 ± 12% interrupts.CPU96.NMI:Non-maskable_interrupts 123.17 ± 29% +71.1% 210.71 ± 12% interrupts.CPU96.PMI:Performance_monitoring_interrupts 102.17 ± 17% +111.0% 215.57 ± 16% interrupts.CPU98.NMI:Non-maskable_interrupts 102.17 ± 17% +111.0% 215.57 ± 16% interrupts.CPU98.PMI:Performance_monitoring_interrupts 105.67 ± 24% +285.6% 407.43 ±118% interrupts.CPU99.NMI:Non-maskable_interrupts 105.67 ± 24% +285.6% 407.43 ±118% interrupts.CPU99.PMI:Performance_monitoring_interrupts 576.33 ± 7% -50.7% 284.14 ± 2% interrupts.IWI:IRQ_work_interrupts 30.77 -5.4 25.32 ± 8% perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe 30.57 -5.3 25.23 ± 8% perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe 11.27 ± 3% -2.8 8.43 ± 21% perf-profile.calltrace.cycles-pp.__x64_sys_recvfrom.do_syscall_64.entry_SYSCALL_64_after_hwframe 11.24 ± 3% -2.8 8.42 ± 21% perf-profile.calltrace.cycles-pp.__sys_recvfrom.__x64_sys_recvfrom.do_syscall_64.entry_SYSCALL_64_after_hwframe 19.14 -2.4 16.71 ± 7% perf-profile.calltrace.cycles-pp.__x64_sys_sendto.do_syscall_64.entry_SYSCALL_64_after_hwframe 19.10 -2.4 16.70 ± 7% perf-profile.calltrace.cycles-pp.__sys_sendto.__x64_sys_sendto.do_syscall_64.entry_SYSCALL_64_after_hwframe 4.14 ± 11% -2.3 1.81 ± 36% perf-profile.calltrace.cycles-pp.udp_send_skb.udp_sendmsg.sock_sendmsg.__sys_sendto.__x64_sys_sendto 4.06 ± 11% -2.3 1.79 ± 36% perf-profile.calltrace.cycles-pp.ip_send_skb.udp_send_skb.udp_sendmsg.sock_sendmsg.__sys_sendto 3.99 ± 11% -2.2 1.76 ± 36% perf-profile.calltrace.cycles-pp.ip_output.ip_send_skb.udp_send_skb.udp_sendmsg.sock_sendmsg 3.85 ± 12% -2.1 1.70 ± 36% perf-profile.calltrace.cycles-pp.ip_finish_output2.ip_output.ip_send_skb.udp_send_skb.udp_sendmsg 3.46 ± 13% -1.9 1.55 ± 36% perf-profile.calltrace.cycles-pp.__local_bh_enable_ip.ip_finish_output2.ip_output.ip_send_skb.udp_send_skb 3.42 ± 13% -1.9 1.54 ± 36% perf-profile.calltrace.cycles-pp.do_softirq.__local_bh_enable_ip.ip_finish_output2.ip_output.ip_send_skb 3.38 ± 13% -1.9 1.52 ± 36% perf-profile.calltrace.cycles-pp.__softirqentry_text_start.do_softirq.__local_bh_enable_ip.ip_finish_output2.ip_output 3.23 ± 13% -1.8 1.48 ± 36% perf-profile.calltrace.cycles-pp.net_rx_action.__softirqentry_text_start.do_softirq.__local_bh_enable_ip.ip_finish_output2 3.14 ± 13% -1.7 1.44 ± 36% perf-profile.calltrace.cycles-pp.__napi_poll.net_rx_action.__softirqentry_text_start.do_softirq.__local_bh_enable_ip 3.11 ± 13% -1.7 1.44 ± 36% perf-profile.calltrace.cycles-pp.process_backlog.__napi_poll.net_rx_action.__softirqentry_text_start.do_softirq 3.01 ± 14% -1.6 1.39 ± 36% perf-profile.calltrace.cycles-pp.__netif_receive_skb_one_core.process_backlog.__napi_poll.net_rx_action.__softirqentry_text_start 2.93 ± 14% -1.6 1.37 ± 36% perf-profile.calltrace.cycles-pp.ip_rcv.__netif_receive_skb_one_core.process_backlog.__napi_poll.net_rx_action 2.87 ± 14% -1.5 1.35 ± 36% perf-profile.calltrace.cycles-pp.ip_local_deliver.ip_rcv.__netif_receive_skb_one_core.process_backlog.__napi_poll 2.86 ± 14% -1.5 1.34 ± 36% perf-profile.calltrace.cycles-pp.ip_local_deliver_finish.ip_local_deliver.ip_rcv.__netif_receive_skb_one_core.process_backlog 2.85 ± 14% -1.5 1.34 ± 36% perf-profile.calltrace.cycles-pp.ip_protocol_deliver_rcu.ip_local_deliver_finish.ip_local_deliver.ip_rcv.__netif_receive_skb_one_core 2.82 ± 14% -1.5 1.33 ± 36% perf-profile.calltrace.cycles-pp.__udp4_lib_rcv.ip_protocol_deliver_rcu.ip_local_deliver_finish.ip_local_deliver.ip_rcv 2.00 ± 18% -1.4 0.58 ± 87% perf-profile.calltrace.cycles-pp.try_to_wake_up.autoremove_wake_function.__wake_up_common.__wake_up_common_lock.sock_def_readable 2.68 ± 15% -1.4 1.29 ± 36% perf-profile.calltrace.cycles-pp.udp_unicast_rcv_skb.__udp4_lib_rcv.ip_protocol_deliver_rcu.ip_local_deliver_finish.ip_local_deliver 2.65 ± 15% -1.4 1.27 ± 36% perf-profile.calltrace.cycles-pp.udp_queue_rcv_one_skb.udp_unicast_rcv_skb.__udp4_lib_rcv.ip_protocol_deliver_rcu.ip_local_deliver_finish 2.01 ± 18% -1.4 0.65 ± 69% perf-profile.calltrace.cycles-pp.autoremove_wake_function.__wake_up_common.__wake_up_common_lock.sock_def_readable.__udp_enqueue_schedule_skb 2.26 ± 17% -1.3 0.93 ± 36% perf-profile.calltrace.cycles-pp.sock_def_readable.__udp_enqueue_schedule_skb.udp_queue_rcv_one_skb.udp_unicast_rcv_skb.__udp4_lib_rcv 2.06 ± 18% -1.3 0.76 ± 69% perf-profile.calltrace.cycles-pp.__wake_up_common.__wake_up_common_lock.sock_def_readable.__udp_enqueue_schedule_skb.udp_queue_rcv_one_skb 2.21 ± 17% -1.3 0.92 ± 36% perf-profile.calltrace.cycles-pp.__wake_up_common_lock.sock_def_readable.__udp_enqueue_schedule_skb.udp_queue_rcv_one_skb.udp_unicast_rcv_skb 2.40 ± 16% -1.3 1.13 ± 38% perf-profile.calltrace.cycles-pp.__udp_enqueue_schedule_skb.udp_queue_rcv_one_skb.udp_unicast_rcv_skb.__udp4_lib_rcv.ip_protocol_deliver_rcu 1.31 ± 5% -1.0 0.33 ± 87% perf-profile.calltrace.cycles-pp.schedule.schedule_timeout.__skb_wait_for_more_packets.__skb_recv_udp.udp_recvmsg 1.29 ± 5% -1.0 0.33 ± 87% perf-profile.calltrace.cycles-pp.__schedule.schedule.schedule_timeout.__skb_wait_for_more_packets.__skb_recv_udp 2.14 ± 4% -1.0 1.18 ± 19% perf-profile.calltrace.cycles-pp.__skb_recv_udp.udp_recvmsg.inet_recvmsg.__sys_recvfrom.__x64_sys_recvfrom 1.35 ± 5% -0.9 0.48 ± 64% perf-profile.calltrace.cycles-pp.schedule_timeout.__skb_wait_for_more_packets.__skb_recv_udp.udp_recvmsg.inet_recvmsg 1.71 ± 4% -0.8 0.89 ± 19% perf-profile.calltrace.cycles-pp.__skb_wait_for_more_packets.__skb_recv_udp.udp_recvmsg.inet_recvmsg.__sys_recvfrom 0.84 ± 7% -0.4 0.40 ± 88% perf-profile.calltrace.cycles-pp.__consume_stateless_skb.udp_recvmsg.inet_recvmsg.__sys_recvfrom.__x64_sys_recvfrom 0.51 ± 44% +0.7 1.19 ± 36% perf-profile.calltrace.cycles-pp.ktime_get.tick_irq_enter.irq_enter_rcu.sysvec_apic_timer_interrupt.asm_sysvec_apic_timer_interrupt 16.97 ± 10% +3.7 20.65 ± 13% perf-profile.calltrace.cycles-pp.asm_sysvec_apic_timer_interrupt.cpuidle_enter_state.cpuidle_enter.do_idle.cpu_startup_entry 67.79 +5.8 73.59 ± 2% perf-profile.calltrace.cycles-pp.cpu_startup_entry.start_secondary.secondary_startup_64_no_verify 67.79 +5.8 73.60 ± 2% perf-profile.calltrace.cycles-pp.start_secondary.secondary_startup_64_no_verify 67.73 +5.8 73.55 ± 2% perf-profile.calltrace.cycles-pp.do_idle.cpu_startup_entry.start_secondary.secondary_startup_64_no_verify 68.07 +5.9 74.00 ± 2% perf-profile.calltrace.cycles-pp.secondary_startup_64_no_verify 7.05 ± 46% +6.8 13.84 ± 14% perf-profile.calltrace.cycles-pp.menu_select.do_idle.cpu_startup_entry.start_secondary.secondary_startup_64_no_verify 31.00 -5.5 25.53 ± 7% perf-profile.children.cycles-pp.entry_SYSCALL_64_after_hwframe 30.80 -5.4 25.44 ± 7% perf-profile.children.cycles-pp.do_syscall_64 4.59 ± 4% -4.5 0.07 ± 21% perf-profile.children.cycles-pp.poll_idle 11.28 ± 3% -2.8 8.43 ± 21% perf-profile.children.cycles-pp.__x64_sys_recvfrom 11.24 ± 3% -2.8 8.42 ± 21% perf-profile.children.cycles-pp.__sys_recvfrom 19.14 -2.4 16.71 ± 7% perf-profile.children.cycles-pp.__x64_sys_sendto 19.11 -2.4 16.70 ± 7% perf-profile.children.cycles-pp.__sys_sendto 4.14 ± 11% -2.3 1.81 ± 36% perf-profile.children.cycles-pp.udp_send_skb 4.06 ± 11% -2.3 1.79 ± 36% perf-profile.children.cycles-pp.ip_send_skb 4.00 ± 11% -2.2 1.76 ± 36% perf-profile.children.cycles-pp.ip_output 3.85 ± 12% -2.2 1.70 ± 36% perf-profile.children.cycles-pp.ip_finish_output2 3.48 ± 13% -1.9 1.55 ± 36% perf-profile.children.cycles-pp.__local_bh_enable_ip 3.42 ± 13% -1.9 1.54 ± 36% perf-profile.children.cycles-pp.do_softirq 3.24 ± 13% -1.8 1.48 ± 36% perf-profile.children.cycles-pp.net_rx_action 2.46 ± 2% -1.7 0.73 ± 22% perf-profile.children.cycles-pp.__schedule 4.89 ± 9% -1.7 3.18 ± 19% perf-profile.children.cycles-pp.__softirqentry_text_start 3.14 ± 13% -1.7 1.45 ± 36% perf-profile.children.cycles-pp.__napi_poll 3.11 ± 13% -1.7 1.44 ± 36% perf-profile.children.cycles-pp.process_backlog 3.01 ± 14% -1.6 1.39 ± 36% perf-profile.children.cycles-pp.__netif_receive_skb_one_core 2.93 ± 14% -1.6 1.37 ± 36% perf-profile.children.cycles-pp.ip_rcv 2.87 ± 14% -1.5 1.35 ± 36% perf-profile.children.cycles-pp.ip_local_deliver 2.86 ± 14% -1.5 1.34 ± 36% perf-profile.children.cycles-pp.ip_local_deliver_finish 2.85 ± 14% -1.5 1.34 ± 36% perf-profile.children.cycles-pp.ip_protocol_deliver_rcu 2.82 ± 14% -1.5 1.33 ± 36% perf-profile.children.cycles-pp.__udp4_lib_rcv 2.68 ± 15% -1.4 1.29 ± 36% perf-profile.children.cycles-pp.udp_unicast_rcv_skb 2.65 ± 15% -1.4 1.27 ± 36% perf-profile.children.cycles-pp.udp_queue_rcv_one_skb 2.26 ± 17% -1.3 0.93 ± 36% perf-profile.children.cycles-pp.sock_def_readable 2.22 ± 17% -1.3 0.93 ± 36% perf-profile.children.cycles-pp.__wake_up_common_lock 2.40 ± 15% -1.3 1.13 ± 38% perf-profile.children.cycles-pp.__udp_enqueue_schedule_skb 2.02 ± 17% -1.2 0.78 ± 38% perf-profile.children.cycles-pp.autoremove_wake_function 2.02 ± 18% -1.2 0.78 ± 38% perf-profile.children.cycles-pp.try_to_wake_up 2.07 ± 18% -1.2 0.91 ± 37% perf-profile.children.cycles-pp.__wake_up_common 2.14 ± 4% -1.0 1.18 ± 19% perf-profile.children.cycles-pp.__skb_recv_udp 1.12 ± 3% -0.9 0.20 ± 36% perf-profile.children.cycles-pp.schedule_idle 1.37 ± 5% -0.8 0.54 ± 20% perf-profile.children.cycles-pp.schedule 1.71 ± 4% -0.8 0.89 ± 19% perf-profile.children.cycles-pp.__skb_wait_for_more_packets 1.36 ± 4% -0.7 0.61 ± 19% perf-profile.children.cycles-pp.schedule_timeout 0.83 ± 18% -0.6 0.19 ± 34% perf-profile.children.cycles-pp.ttwu_do_activate 0.82 ± 19% -0.6 0.18 ± 36% perf-profile.children.cycles-pp.enqueue_task_fair 0.60 ± 3% -0.5 0.07 ± 9% perf-profile.children.cycles-pp.pick_next_task_fair 0.66 ± 19% -0.5 0.17 ± 39% perf-profile.children.cycles-pp.enqueue_entity 0.80 ± 17% -0.5 0.32 ± 20% perf-profile.children.cycles-pp.update_rq_clock 0.72 ± 6% -0.4 0.32 ± 21% perf-profile.children.cycles-pp.dequeue_task_fair 0.39 ± 5% -0.3 0.09 ± 20% perf-profile.children.cycles-pp.update_load_avg 0.82 ± 17% -0.3 0.52 ± 18% perf-profile.children.cycles-pp.sched_clock_cpu 0.59 ± 5% -0.3 0.29 ± 22% perf-profile.children.cycles-pp.dequeue_entity 0.72 ± 15% -0.3 0.45 ± 16% perf-profile.children.cycles-pp.sched_clock 0.69 ± 15% -0.3 0.42 ± 17% perf-profile.children.cycles-pp.native_sched_clock 0.84 ± 7% -0.3 0.57 ± 27% perf-profile.children.cycles-pp.__consume_stateless_skb 0.29 ± 6% -0.3 0.03 ± 88% perf-profile.children.cycles-pp.kmem_cache_free 0.61 ± 7% -0.2 0.40 ± 29% perf-profile.children.cycles-pp.__free_pages_ok 0.30 ± 24% -0.2 0.10 ± 37% perf-profile.children.cycles-pp.ip_route_output_flow 0.73 ± 7% -0.2 0.53 ± 9% perf-profile.children.cycles-pp._raw_spin_lock 0.29 ± 23% -0.2 0.10 ± 37% perf-profile.children.cycles-pp.ip_route_output_key_hash 0.30 ± 16% -0.2 0.12 ± 36% perf-profile.children.cycles-pp.__dev_queue_xmit 0.27 ± 23% -0.2 0.09 ± 37% perf-profile.children.cycles-pp.ip_route_output_key_hash_rcu 0.21 ± 21% -0.1 0.07 ± 51% perf-profile.children.cycles-pp.fib_table_lookup 0.64 ± 7% -0.1 0.50 ± 10% perf-profile.children.cycles-pp.read_tsc 0.21 ± 13% -0.1 0.07 ± 48% perf-profile.children.cycles-pp.dev_hard_start_xmit 0.19 ± 11% -0.1 0.06 ± 49% perf-profile.children.cycles-pp.__switch_to 0.19 ± 11% -0.1 0.07 ± 49% perf-profile.children.cycles-pp.loopback_xmit 0.40 ± 18% -0.1 0.28 ± 17% perf-profile.children.cycles-pp.get_next_timer_interrupt 0.17 ± 10% -0.1 0.05 ± 42% perf-profile.children.cycles-pp.__switch_to_asm 0.19 ± 6% -0.1 0.08 ± 29% perf-profile.children.cycles-pp.move_addr_to_user 0.16 ± 7% -0.1 0.07 ± 12% perf-profile.children.cycles-pp.__update_load_avg_cfs_rq 0.13 ± 24% -0.1 0.06 ± 72% perf-profile.children.cycles-pp.__free_one_page 0.13 ± 20% -0.1 0.06 ± 46% perf-profile.children.cycles-pp.sockfd_lookup_light 0.12 ± 19% -0.1 0.05 ± 69% perf-profile.children.cycles-pp.__fget_light 0.18 ± 9% -0.1 0.11 ± 18% perf-profile.children.cycles-pp.call_cpuidle 0.18 ± 9% -0.1 0.13 ± 12% perf-profile.children.cycles-pp.hrtimer_get_next_event 0.09 ± 11% -0.0 0.04 ± 67% perf-profile.children.cycles-pp.udp_rmem_release 0.09 ± 10% -0.0 0.05 ± 46% perf-profile.children.cycles-pp.trigger_load_balance 0.05 ± 47% +0.1 0.16 ± 21% perf-profile.children.cycles-pp.cpuacct_charge 0.00 +0.1 0.11 ± 26% perf-profile.children.cycles-pp.llist_reverse_order 0.00 +0.2 0.16 ± 13% perf-profile.children.cycles-pp.flush_smp_call_function_queue 0.00 +0.3 0.27 ± 59% perf-profile.children.cycles-pp.__smp_call_single_queue 0.00 +0.3 0.27 ± 59% perf-profile.children.cycles-pp.llist_add_batch 0.00 +0.4 0.36 ± 20% perf-profile.children.cycles-pp.sched_ttwu_pending 0.00 +0.4 0.38 ± 42% perf-profile.children.cycles-pp.ttwu_queue_wakelist 0.00 +0.5 0.55 ± 14% perf-profile.children.cycles-pp.flush_smp_call_function_from_idle 2.35 ± 25% +1.1 3.48 ± 19% perf-profile.children.cycles-pp.ktime_get 14.90 ± 4% +2.3 17.23 ± 10% perf-profile.children.cycles-pp.asm_sysvec_apic_timer_interrupt 67.79 +5.8 73.60 ± 2% perf-profile.children.cycles-pp.start_secondary 68.07 +5.9 74.00 ± 2% perf-profile.children.cycles-pp.secondary_startup_64_no_verify 68.07 +5.9 74.00 ± 2% perf-profile.children.cycles-pp.cpu_startup_entry 68.06 +5.9 73.99 ± 2% perf-profile.children.cycles-pp.do_idle 7.12 ± 45% +6.8 13.97 ± 14% perf-profile.children.cycles-pp.menu_select 4.54 ± 4% -4.5 0.05 ± 65% perf-profile.self.cycles-pp.poll_idle 0.46 ± 20% -0.4 0.05 ± 66% perf-profile.self.cycles-pp.update_rq_clock 0.47 ± 9% -0.4 0.09 ± 18% perf-profile.self.cycles-pp.__schedule 0.65 ± 15% -0.3 0.39 ± 15% perf-profile.self.cycles-pp.native_sched_clock 0.55 ± 18% -0.2 0.32 ± 20% perf-profile.self.cycles-pp.do_idle 0.32 ± 25% -0.2 0.08 ± 30% perf-profile.self.cycles-pp.enqueue_entity 0.71 ± 7% -0.2 0.52 ± 9% perf-profile.self.cycles-pp._raw_spin_lock 0.35 ± 7% -0.2 0.18 ± 32% perf-profile.self.cycles-pp.__free_pages_ok 0.62 ± 7% -0.1 0.49 ± 10% perf-profile.self.cycles-pp.read_tsc 0.17 ± 9% -0.1 0.05 ± 70% perf-profile.self.cycles-pp.__switch_to 0.16 ± 22% -0.1 0.04 ± 89% perf-profile.self.cycles-pp.fib_table_lookup 0.16 ± 9% -0.1 0.05 ± 43% perf-profile.self.cycles-pp.__switch_to_asm 0.15 ± 8% -0.1 0.06 ± 18% perf-profile.self.cycles-pp.__update_load_avg_cfs_rq 0.12 ± 19% -0.1 0.05 ± 69% perf-profile.self.cycles-pp.__fget_light 0.16 ± 10% -0.1 0.11 ± 15% perf-profile.self.cycles-pp.call_cpuidle 0.12 ± 9% -0.1 0.06 ± 23% perf-profile.self.cycles-pp.__softirqentry_text_start 0.06 ± 52% +0.0 0.11 ± 30% perf-profile.self.cycles-pp.udp_queue_rcv_one_skb 0.00 +0.1 0.08 ± 24% perf-profile.self.cycles-pp.ttwu_queue_wakelist 0.02 ±142% +0.1 0.12 ± 30% perf-profile.self.cycles-pp.__wake_up_common 0.00 +0.1 0.11 ± 28% perf-profile.self.cycles-pp.sched_ttwu_pending 0.05 ± 47% +0.1 0.16 ± 21% perf-profile.self.cycles-pp.cpuacct_charge 0.00 +0.1 0.11 ± 26% perf-profile.self.cycles-pp.llist_reverse_order 0.00 +0.3 0.27 ± 59% perf-profile.self.cycles-pp.llist_add_batch 1.78 ± 35% +1.3 3.05 ± 23% perf-profile.self.cycles-pp.ktime_get 5.18 ± 60% +6.1 11.25 ± 19% perf-profile.self.cycles-pp.cpuidle_enter_state 4.81 ± 62% +6.7 11.54 ± 19% perf-profile.self.cycles-pp.menu_select Disclaimer: Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance. --- 0DAY/LKP+ Test Infrastructure Open Source Technology Center https://lists.01.org/hyperkitty/list/lkp@lists.01.org Intel Corporation Thanks, Oliver Sang

1 0

Re: [PATCH net v4 1/2] net: sched: fix packet stuck problem for lockless qdisc
by Yunsheng Lin 30 Apr '21

30 Apr '21

On 2021/4/21 17:25, Yunsheng Lin wrote: > On 2021/4/21 16:44, Michal Kubecek wrote: > >> >> I'll try running some tests also on other architectures, including arm64 >> and s390x (to catch potential endinanity issues). I tried debugging nperf in arm64, with the below patch: diff --git a/client/main.c b/client/main.c index 429634d..de1a3ef 100644 --- a/client/main.c +++ b/client/main.c @@ -63,7 +63,10 @@ static int client_init(void) ret = client_set_usr1_handler(); if (ret < 0) return ret; - return ignore_signal(SIGPIPE); + //return ignore_signal(SIGPIPE); + signal(SIGPIPE, SIG_IGN); + + return 0; } static int ctrl_send_start(struct client_config *config) diff --git a/client/worker.c b/client/worker.c index ac026893..d269311 100644 --- a/client/worker.c +++ b/client/worker.c @@ -7,7 +7,7 @@ #include "worker.h" #include "main.h" -#define WORKER_STACK_SIZE 16384 +#define WORKER_STACK_SIZE 131072 struct client_worker_data *workers_data; union sockaddr_any test_addr; It has below error output: ../nperf/nperf -H 127.0.0.1 -l 3 -i 1 --exact -t TCP_STREAM -M 1 server: 127.0.0.1, port 12543 iterations: 1, threads: 1, test length: 3 test: TCP_STREAM, message size: 1048576 run test begin send begin send done: -32 failed to receive server stats *** Iteration 1 failed, quitting. *** Tcpdump has below output: 09:55:12.253341 IP localhost.53080 > localhost.12543: Flags [S], seq 3954442980, win 65495, options [mss 65495,sackOK,TS val 3268837738 ecr 0,nop,wscale 7], length 0 09:55:12.253363 IP localhost.12543 > localhost.53080: Flags [S.], seq 4240541653, ack 3954442981, win 65483, options [mss 65495,sackOK,TS val 3268837738 ecr 3268837738,nop,wscale 7], length 0 09:55:12.253379 IP localhost.53080 > localhost.12543: Flags [.], ack 1, win 512, options [nop,nop,TS val 3268837738 ecr 3268837738], length 0 09:55:12.253412 IP localhost.53080 > localhost.12543: Flags [P.], seq 1:29, ack 1, win 512, options [nop,nop,TS val 3268837738 ecr 3268837738], length 28 09:55:12.253863 IP localhost.12543 > localhost.53080: Flags [P.], seq 1:17, ack 29, win 512, options [nop,nop,TS val 3268837739 ecr 3268837738], length 16 09:55:12.253891 IP localhost.53080 > localhost.12543: Flags [.], ack 17, win 512, options [nop,nop,TS val 3268837739 ecr 3268837739], length 0 09:55:12.254265 IP localhost.12543 > localhost.53080: Flags [F.], seq 17, ack 29, win 512, options [nop,nop,TS val 3268837739 ecr 3268837739], length 0 09:55:12.301992 IP localhost.53080 > localhost.12543: Flags [.], ack 18, win 512, options [nop,nop,TS val 3268837787 ecr 3268837739], length 0 09:55:15.254389 IP localhost.53080 > localhost.12543: Flags [F.], seq 29, ack 18, win 512, options [nop,nop,TS val 3268840739 ecr 3268837739], length 0 09:55:15.254426 IP localhost.12543 > localhost.53080: Flags [.], ack 30, win 512, options [nop,nop,TS val 3268840739 ecr 3268840739], length 0 Any idea what went wrong here? Also, Would you mind running netperf to see if there is similar issue in your system? >> >> Michal >> >> . >> > > > . >

2 3

[RFC PATCH v6 1/4] topology: Represent clusters of CPUs within a die
by Barry Song 30 Apr '21

30 Apr '21

From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Both ACPI and DT provide the ability to describe additional layers of topology between that of individual cores and higher level constructs such as the level at which the last level cache is shared. In ACPI this can be represented in PPTT as a Processor Hierarchy Node Structure [1] that is the parent of the CPU cores and in turn has a parent Processor Hierarchy Nodes Structure representing a higher level of topology. For example Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each cluster has 4 cpus. All clusters share L3 cache data, but each cluster has local L3 tag. On the other hand, each clusters will share some internal system bus. +-----------------------------------+ +---------+ | +------+ +------+ +---------------------------+ | | | CPU0 | | cpu1 | | +-----------+ | | | +------+ +------+ | | | | | | +----+ L3 | | | | +------+ +------+ cluster | | tag | | | | | CPU2 | | CPU3 | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | | | L3 | | | | +------+ +------+ +----+ tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | L3 | | data | +-----------------------------------+ | | | +------+ +------+ | +-----------+ | | | | | | | | | | | | | +------+ +------+ +----+ L3 | | | | | | tag | | | | +------+ +------+ | | | | | | | | | | ++ +-----------+ | | | +------+ +------+ |---------------------------+ | +-----------------------------------| | | +-----------------------------------| | | | +------+ +------+ +---------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | +----+ L3 | | | | +------+ +------+ | | tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | | | L3 | | | | +------+ +------+ +---+ tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ ++ | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | | | L3 | | | | +------+ +------+ +--+ tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | +---------+ +-----------------------------------+ That means the cost to transfer ownership of a cacheline between CPUs within a cluster is lower than between CPUs in different clusters on the same die. Hence, it can make sense to tell the scheduler to use the cache affinity of the cluster to make better decision on thread migration. This patch simply exposes this information to userspace libraries like hwloc by providing cluster_cpus and related sysfs attributes. PoC of HWLOC support at [2]. Note this patch only handle the ACPI case. Special consideration is needed for SMT processors, where it is necessary to move 2 levels up the hierarchy from the leaf nodes (thus skipping the processor core level). Currently the ID provided is the offset of the Processor Hierarchy Nodes Structure within PPTT. Whilst this is unique it is not terribly elegant so alternative suggestions welcome. Note that arm64 / ACPI does not provide any means of identifying a die level in the topology but that may be unrelate to the cluster level. [1] ACPI Specification 6.3 - section 5.2.29.1 processor hierarchy node structure (Type 0) [2] https://github.com/hisilicon/hwloc/tree/linux-cluster Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Barry Song <song.bao.hua(a)hisilicon.com> --- -v6: * the topology ABI documents required by Greg is not completed yet. will have a separate patch for that. Documentation/admin-guide/cputopology.rst | 26 +++++++++++-- arch/arm64/kernel/topology.c | 2 + drivers/acpi/pptt.c | 63 +++++++++++++++++++++++++++++++ drivers/base/arch_topology.c | 15 ++++++++ drivers/base/topology.c | 10 +++++ include/linux/acpi.h | 5 +++ include/linux/arch_topology.h | 5 +++ include/linux/topology.h | 6 +++ 8 files changed, 128 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/cputopology.rst b/Documentation/admin-guide/cputopology.rst index b90dafc..f9d3745 100644 --- a/Documentation/admin-guide/cputopology.rst +++ b/Documentation/admin-guide/cputopology.rst @@ -24,6 +24,12 @@ core_id: identifier (rather than the kernel's). The actual value is architecture and platform dependent. +cluster_id: + + the Cluster ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. + book_id: the book ID of cpuX. Typically it is the hardware platform's @@ -56,6 +62,14 @@ package_cpus_list: human-readable list of CPUs sharing the same physical_package_id. (deprecated name: "core_siblings_list") +cluster_cpus: + + internal kernel map of CPUs within the same cluster. + +cluster_cpus_list: + + human-readable list of CPUs within the same cluster. + die_cpus: internal kernel map of CPUs within the same die. @@ -96,11 +110,13 @@ these macros in include/asm-XXX/topology.h:: #define topology_physical_package_id(cpu) #define topology_die_id(cpu) + #define topology_cluster_id(cpu) #define topology_core_id(cpu) #define topology_book_id(cpu) #define topology_drawer_id(cpu) #define topology_sibling_cpumask(cpu) #define topology_core_cpumask(cpu) + #define topology_cluster_cpumask(cpu) #define topology_die_cpumask(cpu) #define topology_book_cpumask(cpu) #define topology_drawer_cpumask(cpu) @@ -116,10 +132,12 @@ not defined by include/asm-XXX/topology.h: 1) topology_physical_package_id: -1 2) topology_die_id: -1 -3) topology_core_id: 0 -4) topology_sibling_cpumask: just the given CPU -5) topology_core_cpumask: just the given CPU -6) topology_die_cpumask: just the given CPU +3) topology_cluster_id: -1 +4) topology_core_id: 0 +5) topology_sibling_cpumask: just the given CPU +6) topology_core_cpumask: just the given CPU +7) topology_cluster_cpumask: just the given CPU +8) topology_die_cpumask: just the given CPU For architectures that don't support books (CONFIG_SCHED_BOOK) there are no default definitions for topology_book_id() and topology_book_cpumask(). diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c index e08a412..d72eb8d 100644 --- a/arch/arm64/kernel/topology.c +++ b/arch/arm64/kernel/topology.c @@ -103,6 +103,8 @@ int __init parse_acpi_topology(void) cpu_topology[cpu].thread_id = -1; cpu_topology[cpu].core_id = topology_id; } + topology_id = find_acpi_cpu_topology_cluster(cpu); + cpu_topology[cpu].cluster_id = topology_id; topology_id = find_acpi_cpu_topology_package(cpu); cpu_topology[cpu].package_id = topology_id; diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c index 4ae9335..11f8b02 100644 --- a/drivers/acpi/pptt.c +++ b/drivers/acpi/pptt.c @@ -737,6 +737,69 @@ int find_acpi_cpu_topology_package(unsigned int cpu) } /** + * find_acpi_cpu_topology_cluster() - Determine a unique CPU cluster value + * @cpu: Kernel logical CPU number + * + * Determine a topology unique cluster ID for the given CPU/thread. + * This ID can then be used to group peers, which will have matching ids. + * + * The cluster, if present is the level of topology above CPUs. In a + * multi-thread CPU, it will be the level above the CPU, not the thread. + * It may not exist in single CPU systems. In simple multi-CPU systems, + * it may be equal to the package topology level. + * + * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be found + * or there is no toplogy level above the CPU.. + * Otherwise returns a value which represents the package for this CPU. + */ + +int find_acpi_cpu_topology_cluster(unsigned int cpu) +{ + struct acpi_table_header *table; + acpi_status status; + struct acpi_pptt_processor *cpu_node, *cluster_node; + u32 acpi_cpu_id; + int retval; + int is_thread; + + status = acpi_get_table(ACPI_SIG_PPTT, 0, &table); + if (ACPI_FAILURE(status)) { + acpi_pptt_warn_missing(); + return -ENOENT; + } + + acpi_cpu_id = get_acpi_id_for_cpu(cpu); + cpu_node = acpi_find_processor_node(table, acpi_cpu_id); + if (cpu_node == NULL || !cpu_node->parent) { + retval = -ENOENT; + goto put_table; + } + + is_thread = cpu_node->flags & ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD; + cluster_node = fetch_pptt_node(table, cpu_node->parent); + if (cluster_node == NULL) { + retval = -ENOENT; + goto put_table; + } + if (is_thread) { + if (!cluster_node->parent) { + retval = -ENOENT; + goto put_table; + } + cluster_node = fetch_pptt_node(table, cluster_node->parent); + if (cluster_node == NULL) { + retval = -ENOENT; + goto put_table; + } + } + retval = ACPI_PTR_DIFF(cluster_node, table); +put_table: + acpi_put_table(table); + + return retval; +} + +/** * find_acpi_cpu_topology_hetero_id() - Get a core architecture tag * @cpu: Kernel logical CPU number * diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index de8587c..ca3b8c1 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -506,6 +506,11 @@ const struct cpumask *cpu_coregroup_mask(int cpu) return core_mask; } +const struct cpumask *cpu_clustergroup_mask(int cpu) +{ + return &cpu_topology[cpu].cluster_sibling; +} + void update_siblings_masks(unsigned int cpuid) { struct cpu_topology *cpu_topo, *cpuid_topo = &cpu_topology[cpuid]; @@ -523,6 +528,11 @@ void update_siblings_masks(unsigned int cpuid) if (cpuid_topo->package_id != cpu_topo->package_id) continue; + if (cpuid_topo->cluster_id == cpu_topo->cluster_id) { + cpumask_set_cpu(cpu, &cpuid_topo->cluster_sibling); + cpumask_set_cpu(cpuid, &cpu_topo->cluster_sibling); + } + cpumask_set_cpu(cpuid, &cpu_topo->core_sibling); cpumask_set_cpu(cpu, &cpuid_topo->core_sibling); @@ -541,6 +551,9 @@ static void clear_cpu_topology(int cpu) cpumask_clear(&cpu_topo->llc_sibling); cpumask_set_cpu(cpu, &cpu_topo->llc_sibling); + cpumask_clear(&cpu_topo->cluster_sibling); + cpumask_set_cpu(cpu, &cpu_topo->cluster_sibling); + cpumask_clear(&cpu_topo->core_sibling); cpumask_set_cpu(cpu, &cpu_topo->core_sibling); cpumask_clear(&cpu_topo->thread_sibling); @@ -556,6 +569,7 @@ void __init reset_cpu_topology(void) cpu_topo->thread_id = -1; cpu_topo->core_id = -1; + cpu_topo->cluster_id = -1; cpu_topo->package_id = -1; cpu_topo->llc_id = -1; @@ -571,6 +585,7 @@ void remove_cpu_topology(unsigned int cpu) cpumask_clear_cpu(cpu, topology_core_cpumask(sibling)); for_each_cpu(sibling, topology_sibling_cpumask(cpu)) cpumask_clear_cpu(cpu, topology_sibling_cpumask(sibling)); + for_each_cpu(sibling, topology_llc_cpumask(cpu)) cpumask_clear_cpu(cpu, topology_llc_cpumask(sibling)); diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..7157ac0 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -46,6 +46,9 @@ define_id_show_func(die_id); static DEVICE_ATTR_RO(die_id); +define_id_show_func(cluster_id); +static DEVICE_ATTR_RO(cluster_id); + define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); @@ -61,6 +64,10 @@ static DEVICE_ATTR_RO(core_siblings); static DEVICE_ATTR_RO(core_siblings_list); +define_siblings_show_func(cluster_cpus, cluster_cpumask); +static DEVICE_ATTR_RO(cluster_cpus); +static DEVICE_ATTR_RO(cluster_cpus_list); + define_siblings_show_func(die_cpus, die_cpumask); static DEVICE_ATTR_RO(die_cpus); static DEVICE_ATTR_RO(die_cpus_list); @@ -88,6 +95,7 @@ static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, + &dev_attr_cluster_id.attr, &dev_attr_core_id.attr, &dev_attr_thread_siblings.attr, &dev_attr_thread_siblings_list.attr, @@ -95,6 +103,8 @@ &dev_attr_core_cpus_list.attr, &dev_attr_core_siblings.attr, &dev_attr_core_siblings_list.attr, + &dev_attr_cluster_cpus.attr, + &dev_attr_cluster_cpus_list.attr, &dev_attr_die_cpus.attr, &dev_attr_die_cpus_list.attr, &dev_attr_package_cpus.attr, diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 9f43241..138b779 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -1307,6 +1307,7 @@ static inline int lpit_read_residency_count_address(u64 *address) #ifdef CONFIG_ACPI_PPTT int acpi_pptt_cpu_is_thread(unsigned int cpu); int find_acpi_cpu_topology(unsigned int cpu, int level); +int find_acpi_cpu_topology_cluster(unsigned int cpu); int find_acpi_cpu_topology_package(unsigned int cpu); int find_acpi_cpu_topology_hetero_id(unsigned int cpu); int find_acpi_cpu_cache_topology(unsigned int cpu, int level); @@ -1319,6 +1320,10 @@ static inline int find_acpi_cpu_topology(unsigned int cpu, int level) { return -EINVAL; } +static inline int find_acpi_cpu_topology_cluster(unsigned int cpu) +{ + return -EINVAL; +} static inline int find_acpi_cpu_topology_package(unsigned int cpu) { return -EINVAL; diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h index 0f6cd6b..987c7ea 100644 --- a/include/linux/arch_topology.h +++ b/include/linux/arch_topology.h @@ -49,10 +49,12 @@ void topology_set_thermal_pressure(const struct cpumask *cpus, struct cpu_topology { int thread_id; int core_id; + int cluster_id; int package_id; int llc_id; cpumask_t thread_sibling; cpumask_t core_sibling; + cpumask_t cluster_sibling; cpumask_t llc_sibling; }; @@ -60,13 +62,16 @@ struct cpu_topology { extern struct cpu_topology cpu_topology[NR_CPUS]; #define topology_physical_package_id(cpu) (cpu_topology[cpu].package_id) +#define topology_cluster_id(cpu) (cpu_topology[cpu].cluster_id) #define topology_core_id(cpu) (cpu_topology[cpu].core_id) #define topology_core_cpumask(cpu) (&cpu_topology[cpu].core_sibling) #define topology_sibling_cpumask(cpu) (&cpu_topology[cpu].thread_sibling) +#define topology_cluster_cpumask(cpu) (&cpu_topology[cpu].cluster_sibling) #define topology_llc_cpumask(cpu) (&cpu_topology[cpu].llc_sibling) void init_cpu_topology(void); void store_cpu_topology(unsigned int cpuid); const struct cpumask *cpu_coregroup_mask(int cpu); +const struct cpumask *cpu_clustergroup_mask(int cpu); void update_siblings_masks(unsigned int cpu); void remove_cpu_topology(unsigned int cpuid); void reset_cpu_topology(void); diff --git a/include/linux/topology.h b/include/linux/topology.h index 7634cd7..80d27d7 100644 --- a/include/linux/topology.h +++ b/include/linux/topology.h @@ -186,6 +186,9 @@ static inline int cpu_to_mem(int cpu) #ifndef topology_die_id #define topology_die_id(cpu) ((void)(cpu), -1) #endif +#ifndef topology_cluster_id +#define topology_cluster_id(cpu) ((void)(cpu), -1) +#endif #ifndef topology_core_id #define topology_core_id(cpu) ((void)(cpu), 0) #endif @@ -195,6 +198,9 @@ static inline int cpu_to_mem(int cpu) #ifndef topology_core_cpumask #define topology_core_cpumask(cpu) cpumask_of(cpu) #endif +#ifndef topology_cluster_cpumask +#define topology_cluster_cpumask(cpu) cpumask_of(cpu) +#endif #ifndef topology_die_cpumask #define topology_die_cpumask(cpu) cpumask_of(cpu) #endif -- 1.8.3.1

3 2

Re: [PATCH net 0/3] net: hns3: add some fixes for -net
by patchwork-bot+netdevbpf＠kernel.org 30 Apr '21

30 Apr '21

Hello: This series was applied to netdev/net.git (refs/heads/master): On Thu, 29 Apr 2021 16:34:49 +0800 you wrote: > This series adds some fixes for the HNS3 ethernet driver. > > Jian Shen (1): > net: hns3: add check for HNS3_NIC_STATE_INITED in > hns3_reset_notify_up_enet() > > Yufeng Mo (2): > net: hns3: fix incorrect configuration for igu_egu_hw_err > net: hns3: initialize the message content in hclge_get_link_mode() > > [...] Here is the summary with links: - [net,1/3] net: hns3: fix incorrect configuration for igu_egu_hw_err https://git.kernel.org/netdev/net/c/2867298dd49e - [net,2/3] net: hns3: initialize the message content in hclge_get_link_mode() https://git.kernel.org/netdev/net/c/568a54bdf70b - [net,3/3] net: hns3: add check for HNS3_NIC_STATE_INITED in hns3_reset_notify_up_enet() https://git.kernel.org/netdev/net/c/b4047aac4ec1 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html

1 0

Re: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks within one LLC
by Dietmar Eggemann 29 Apr '21

29 Apr '21

On 20/04/2021 02:18, Barry Song wrote: [...] > @@ -5786,11 +5786,12 @@ static void record_wakee(struct task_struct *p) > * whatever is irrelevant, spread criteria is apparent partner count exceeds > * socket size. > */ > -static int wake_wide(struct task_struct *p) > +static int wake_wide(struct task_struct *p, int cluster) > { > unsigned int master = current->wakee_flips; > unsigned int slave = p->wakee_flips; > - int factor = __this_cpu_read(sd_llc_size); > + int factor = cluster ? __this_cpu_read(sd_cluster_size) : > + __this_cpu_read(sd_llc_size); I don't see that the wake_wide() change has any effect here. None of the sched domains has SD_BALANCE_WAKE set so a wakeup (WF_TTWU) can never end up in the slow path. Have you seen a diff when running your `lmbench stream` workload in what wake_wide() returns when you use `sd cluster size` instead of `sd llc size` as factor? I guess for you, wakeups are now subdivided into faster (cluster = 4 CPUs) and fast (llc = 24 CPUs) via sis(), not into fast (sis()) and slow (find_idlest_cpu()). > > if (master < slave) > swap(master, slave); [...] > @@ -6745,6 +6748,12 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) > int want_affine = 0; > /* SD_flags and WF_flags share the first nibble */ > int sd_flag = wake_flags & 0xF; > + /* > + * if cpu and prev_cpu share LLC, consider cluster sibling rather > + * than llc. this is typically true while tasks are bound within > + * one numa > + */ > + int cluster = sched_cluster_active() && cpus_share_cache(cpu, prev_cpu, 0); So you changed from scanning cluster before LLC to scan either cluster or LLC. And this is based on whether `this_cpu` and `prev_cpu` are sharing LLC or not. So you only see an effect when running the workload with `numactl -N X ...`. > > if (wake_flags & WF_TTWU) { > record_wakee(p); > @@ -6756,7 +6765,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) > new_cpu = prev_cpu; > } > > - want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr); > + want_affine = !wake_wide(p, cluster) && cpumask_test_cpu(cpu, p->cpus_ptr); > } > > rcu_read_lock(); > @@ -6768,7 +6777,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) > if (want_affine && (tmp->flags & SD_WAKE_AFFINE) && > cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) { > if (cpu != prev_cpu) > - new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync); > + new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync, cluster); > > sd = NULL; /* Prefer wake_affine over balance flags */ > break; > @@ -6785,7 +6794,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) > new_cpu = find_idlest_cpu(sd, p, cpu, prev_cpu, sd_flag); > } else if (wake_flags & WF_TTWU) { /* XXX always ? */ > /* Fast path */ > - new_cpu = select_idle_sibling(p, prev_cpu, new_cpu); > + new_cpu = select_idle_sibling(p, prev_cpu, new_cpu, cluster); > > if (want_affine) > current->recent_used_cpu = cpu; [...]

3 4

Re: [PATCH V3 7/7] app/testpmd: remove redundant fwd streams initialization
by Li, Xiaoyun 27 Apr '21

27 Apr '21

> -----Original Message----- > From: Huisong Li <lihuisong(a)huawei.com> > Sent: Tuesday, April 20, 2021 17:01 > To: dev(a)dpdk.org > Cc: Yigit, Ferruh <ferruh.yigit(a)intel.com>; Li, Xiaoyun <xiaoyun.li(a)intel.com>; > linuxarm(a)openeuler.org; lihuisong(a)huawei.com > Subject: [PATCH V3 7/7] app/testpmd: remove redundant fwd streams > initialization > > The fwd_config_setup() is called after init_fwd_streams(). > The fwd_config_setup() will reinitialize forwarding streams. > This patch removes init_fwd_streams() from init_config(). > > Signed-off-by: Huisong Li <lihuisong(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- Agree. Seems redundant. Every fwd setup will call init_fwd_streams() again. Acked-by: Xiaoyun Li <xiaoyun.li(a)intel.com>

1 0

Re: [PATCH V3 6/7] app/testpmd: add forwarding config in start port
by Li, Xiaoyun 27 Apr '21

27 Apr '21

> -----Original Message----- > From: Huisong Li <lihuisong(a)huawei.com> > Sent: Tuesday, April 20, 2021 17:01 > To: dev(a)dpdk.org > Cc: Yigit, Ferruh <ferruh.yigit(a)intel.com>; Li, Xiaoyun <xiaoyun.li(a)intel.com>; > linuxarm(a)openeuler.org; lihuisong(a)huawei.com > Subject: [PATCH V3 6/7] app/testpmd: add forwarding config in start port > > Most operations in testpmd that need to update the forwarding streams in > testpmd call fwd_config_setup(). In some scenarios, eg, dev_configure is called > again, the forwarding streams may not be updated. As a result, the actual > forwarding streams cannot be queried by "show config fwd" cmd. I don't agree on this. Fwd config should be only changed after the user change something like nb-cores, queue number, eth-peer in non-dcb mode. These are already done in those commands. You should do fwd_config_setup at the end of cmd_config_dcb_parsed(), I agree on this. But doing it in start port seems to do redundant times of fwd_setup. It's not really needed. > > The procedure is as follows: > set nbcore 4 > port stop all > port config 0 dcb vt off 4 pfc on > port start all > show config fwd > > Signed-off-by: Huisong Li <lihuisong(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- > app/test-pmd/testpmd.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index > abcbdaa..f8052b6 100644 > --- a/app/test-pmd/testpmd.c > +++ b/app/test-pmd/testpmd.c > @@ -2678,6 +2678,12 @@ start_port(portid_t pid) > } > } > } > + /* > + * In some scenarios, eg, dev_configure is called again, the forwarding > + * streams may not be updated. As a result, the actual forwarding > + * streams cannot be queried by "show config fwd" command. > + */ > + fwd_config_setup(); > > printf("Done\n"); > return 0; > -- > 2.7.4

1 0

Re: [PATCH V3 5/7] app/testpmd: move position of verifying DCB test
by Li, Xiaoyun 27 Apr '21

27 Apr '21

> -----Original Message----- > From: Huisong Li <lihuisong(a)huawei.com> > Sent: Tuesday, April 20, 2021 17:01 > To: dev(a)dpdk.org > Cc: Yigit, Ferruh <ferruh.yigit(a)intel.com>; Li, Xiaoyun <xiaoyun.li(a)intel.com>; > linuxarm(a)openeuler.org; lihuisong(a)huawei.com > Subject: [PATCH V3 5/7] app/testpmd: move position of verifying DCB test > > Currently, the check for doing DCB test is assigned to start_packet_forwarding(), > which will be called when run "start" cmd. But fwd_config_setup() is used in > many scenarios, such as, "port config all rxq". > > This patch moves the check from start_packet_forwarding() to > fwd_config_setup(). > > Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates") > > Signed-off-by: Huisong Li <lihuisong(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- > app/test-pmd/config.c | 23 +++++++++++++++++++++-- app/test- > pmd/testpmd.c | 19 ------------------- > 2 files changed, 21 insertions(+), 21 deletions(-) Acked-by: Xiaoyun Li <xiaoyun.li(a)intel.com>

1 0

Re: [PATCH V3 4/7] app/testpmd: add check for support of reporting DCB info
by Li, Xiaoyun 27 Apr '21

27 Apr '21

> -----Original Message----- > From: Huisong Li <lihuisong(a)huawei.com> > Sent: Tuesday, April 20, 2021 17:01 > To: dev(a)dpdk.org > Cc: Yigit, Ferruh <ferruh.yigit(a)intel.com>; Li, Xiaoyun <xiaoyun.li(a)intel.com>; > linuxarm(a)openeuler.org; lihuisong(a)huawei.com > Subject: [PATCH V3 4/7] app/testpmd: add check for support of reporting DCB > info > > Currently, '.get_dcb_info' must be supported for the port doing DCB test, or all > information in 'rte_eth_dcb_info' are zero. It should be prevented when user run > cmd "port config 0 dcb vt off 4 pfc off". > > This patch adds the check for support of reporting dcb info. > > Signed-off-by: Huisong Li <lihuisong(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- > V2->V3 > - fix the abnormal print information > > --- > app/test-pmd/cmdline.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > 2.7.4 Acked-by: Xiaoyun Li <xiaoyun.li(a)intel.com>

1 0

Re: [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test
by Li, Xiaoyun 27 Apr '21

27 Apr '21

> -----Original Message----- > From: Huisong Li <lihuisong(a)huawei.com> > Sent: Tuesday, April 20, 2021 17:01 > To: dev(a)dpdk.org > Cc: Yigit, Ferruh <ferruh.yigit(a)intel.com>; Li, Xiaoyun <xiaoyun.li(a)intel.com>; > linuxarm(a)openeuler.org; lihuisong(a)huawei.com > Subject: [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test > > After DCB mode is configured, if we decrease the number of RX and TX queues, > fwd_config_setup() will be called to setup the DCB forwarding configuration. > And forwarding streams are updated based on new queue numbers in > fwd_config_setup(), but the mapping between the TC and queues obtained by > rte_eth_dev_get_dcb_info() is still old queue numbers (old queue numbers are > greater than new queue numbers). > In this case, the segment fault happens. So rte_eth_dev_configure() should be > called again to update the mapping between the TC and queues before > rte_eth_dev_get_dcb_info(). > > Like: > set nbcore 4 > port stop all > port config 0 dcb vt off 4 pfc on > port start all > port stop all > port config all rxq 8 > port config all txq 8 > > Fixes: 900550de04a7 ("app/testpmd: add dcb support") > Cc: stable(a)dpdk.org > > Signed-off-by: Huisong Li <lihuisong(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- > app/test-pmd/config.c | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index > 03ee40c..18b197b 100644 > --- a/app/test-pmd/config.c > +++ b/app/test-pmd/config.c > @@ -2996,7 +2996,33 @@ dcb_fwd_config_setup(void) > uint16_t nb_rx_queue, nb_tx_queue; > uint16_t i, j, k, sm_id = 0; > uint16_t total_tc_num; > + struct rte_port *port; > uint8_t tc = 0; > + portid_t pid; > + int ret; > + > + /* > + * The fwd_config_setup() is called when the port is > RTE_PORT_STARTED When the port is RTE_PORT_STARTED or RTE_PORT_STARTED? Missing an 'or' here. Maybe something like the following will be better? (just a reference, you can put it in a better way) /* * Re-configure ports to get updated mapping between tc and queue in case the queue number of the port is changed. * Skip for started ports since configuring queue number needs to stop ports first. */ > + * RTE_PORT_STOPPED. When a port is RTE_PORT_STARTED, > dev_configure > + * cannot be called. > + * > + * re-configure the device after changing queue numbers of stopped > + * ports, so that the updated mapping between tc and queue can be > + * obtained. > + */ > + for (pid = 0; pid < nb_fwd_ports; pid++) { > + if (port_is_started(pid) == 1) > + continue; > + > + port = &ports[pid]; > + ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq, > + &port->dev_conf); > + if (ret < 0) { > + printf("Failed to re-configure port %d, ret = %d.\n", > + pid, ret); > + return; > + } > + } > > cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores; > cur_fwd_config.nb_fwd_ports = nb_fwd_ports; > -- > 2.7.4

1 0

Re: [PATCH V3 2/7] app/testpmd: fix DCB forwarding configuration
by Li, Xiaoyun 27 Apr '21

27 Apr '21

> -----Original Message----- > From: Huisong Li <lihuisong(a)huawei.com> > Sent: Tuesday, April 20, 2021 17:01 > To: dev(a)dpdk.org > Cc: Yigit, Ferruh <ferruh.yigit(a)intel.com>; Li, Xiaoyun <xiaoyun.li(a)intel.com>; > linuxarm(a)openeuler.org; lihuisong(a)huawei.com > Subject: [PATCH V3 2/7] app/testpmd: fix DCB forwarding configuration > > After DCB mode is configured, the operations of port stop and port start change > the value of the global variable "dcb_test", As a result, the forwarding > configuration from DCB to RSS mode, namely, “dcb_fwd_config_setup()” to > "rss_fwd_config_setup()". > > Currently, the 'dcb_flag' field in struct 'rte_port' indicates whether the port is > configured with DCB. And it is sufficient to have 'dcb_config' > as a global variable to control the DCB test status. So this patch deletes the > "dcb_test". > > In addition, the 'dcb_config' is first set to 1 first in init_port_dcb_config(), but > the function may fail. > So it should be moved to the end. Change this to the following will be better: In addition, setting 'dcb_config' at the end of init_port_dcb_config() in case that ports fail to enter DCB mode. > > Fixes: 900550de04a7 ("app/testpmd: add dcb support") > Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings") > Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates") > Cc: stable(a)dpdk.org > > Signed-off-by: Huisong Li <lihuisong(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- > app/test-pmd/testpmd.c | 18 ++++-------------- app/test-pmd/testpmd.h | 1 - > 2 files changed, 4 insertions(+), 15 deletions(-) > > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index > d4be23f..a076b1d 100644 > --- a/app/test-pmd/testpmd.c > +++ b/app/test-pmd/testpmd.c > @@ -246,9 +246,6 @@ uint16_t mb_mempool_cache = DEF_MBUF_CACHE; > /**< Size of mbuf mempool cache. */ > /* current configuration is in DCB or not,0 means it is not in DCB mode */ > uint8_t dcb_config = 0; > > -/* Whether the dcb is in testing status */ -uint8_t dcb_test = 0; > - > /* > * Configurable number of RX/TX queues. > */ > @@ -2167,8 +2164,7 @@ start_packet_forwarding(int with_tx_first) > return; > } > > - > - if(dcb_test) { > + if (dcb_config) { > for (i = 0; i < nb_fwd_ports; i++) { > pt_id = fwd_ports_ids[i]; > port = &ports[pt_id]; > @@ -2476,8 +2472,6 @@ start_port(portid_t pid) > if (port_id_is_invalid(pid, ENABLED_WARN)) > return 0; > > - if(dcb_config) > - dcb_test = 1; > RTE_ETH_FOREACH_DEV(pi) { > if (pid != pi && pid != (portid_t)RTE_PORT_ALL) > continue; > @@ -2717,11 +2711,6 @@ stop_port(portid_t pid) > portid_t peer_pl[RTE_MAX_ETHPORTS]; > int peer_pi; > > - if (dcb_test) { > - dcb_test = 0; > - dcb_config = 0; > - } > - > if (port_id_is_invalid(pid, ENABLED_WARN)) > return; > > @@ -3625,8 +3614,6 @@ init_port_dcb_config(portid_t pid, > rte_port = &ports[pid]; > > memset(&port_conf, 0, sizeof(struct rte_eth_conf)); > - /* Enter DCB configuration status */ > - dcb_config = 1; > > port_conf.rxmode = rte_port->dev_conf.rxmode; > port_conf.txmode = rte_port->dev_conf.txmode; @@ -3694,6 +3681,9 > @@ init_port_dcb_config(portid_t pid, > > rte_port->dcb_flag = 1; > > + /* Enter DCB configuration status */ > + dcb_config = 1; > + > return 0; > } > > diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index > 9530ec5..432c66d 100644 > --- a/app/test-pmd/testpmd.h > +++ b/app/test-pmd/testpmd.h > @@ -425,7 +425,6 @@ extern uint64_t noisy_lkup_num_reads; extern uint64_t > noisy_lkup_num_reads_writes; > > extern uint8_t dcb_config; > -extern uint8_t dcb_test; > > extern uint32_t mbuf_data_size_n; > extern uint16_t mbuf_data_size[MAX_SEGS_BUFFER_SPLIT]; > -- > 2.7.4

1 0

Re: [PATCH V3 1/7] app/testpmd: fix forward lcores number when DCB test
by Li, Xiaoyun 27 Apr '21

27 Apr '21

> -----Original Message----- > From: Huisong Li <lihuisong(a)huawei.com> > Sent: Tuesday, April 20, 2021 17:01 > To: dev(a)dpdk.org > Cc: Yigit, Ferruh <ferruh.yigit(a)intel.com>; Li, Xiaoyun <xiaoyun.li(a)intel.com>; > linuxarm(a)openeuler.org; lihuisong(a)huawei.com > Subject: [PATCH V3 1/7] app/testpmd: fix forward lcores number when DCB test > > Currently, 'nb_fwd_lcores' value are both adjusted based on 'nb_fwd_streams' in > rss/simple/icmp_echo_fwd_config_setup. > But the operation is missing in dcb_fwd_config_setup, which may lead to a bad > behavior in which multiple polling threads operate on the same queue. In this > case, the device sends and receives packets, causing unexpected results. The > procedure is as follows: > 1/ run testpmd with "--rxq=8 --txq=8" > 2/ port stop all > 3/ set nbcore 8 > 4/ port config 0 dcb vt off 4 pfc on > 5/ port config all rxq 16 > 6/ port config all txq 16 > 7/ port start all > 8/ set fwd mac > 9/ start > Same as v2 comment. Please check that. > For the DCB forwarding test, each core is assigned to each traffic class and each > core is assigned a multi-stream. > Therefore, 'nb_fwd_lcores' value needs to be adjusted based on 'total_tc_num' > in all forwarding ports. > > Fixes: 900550de04a7 ("app/testpmd: add dcb support") > Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings") > Cc: stable(a)dpdk.org > > Signed-off-by: Huisong Li <lihuisong(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- > app/test-pmd/config.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index > ccb9bd3..03ee40c 100644 > --- a/app/test-pmd/config.c > +++ b/app/test-pmd/config.c > @@ -2961,6 +2961,21 @@ rss_fwd_config_setup(void) > } > } > > +static uint16_t > +get_fwd_port_total_tc_num(void) > +{ > + struct rte_eth_dcb_info dcb_info; > + uint16_t total_tc_num = 0; > + unsigned int i; > + > + for (i = 0; i < nb_fwd_ports; i++) { > + (void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info); > + total_tc_num += dcb_info.nb_tcs; > + } > + > + return total_tc_num; > +} > + > /** > * For the DCB forwarding test, each core is assigned on each traffic class. > * > @@ -2980,12 +2995,16 @@ dcb_fwd_config_setup(void) > lcoreid_t lc_id; > uint16_t nb_rx_queue, nb_tx_queue; > uint16_t i, j, k, sm_id = 0; > + uint16_t total_tc_num; > uint8_t tc = 0; > > cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores; > cur_fwd_config.nb_fwd_ports = nb_fwd_ports; > cur_fwd_config.nb_fwd_streams = > (streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports); > + total_tc_num = get_fwd_port_total_tc_num(); > + if (cur_fwd_config.nb_fwd_lcores > total_tc_num) > + cur_fwd_config.nb_fwd_lcores = total_tc_num; > > /* reinitialize forwarding streams */ > init_fwd_streams(); > -- > 2.7.4

1 0

Re: [PATCH V2 1/7] app/testpmd: fix forward lcores number when DCB test
by Li, Xiaoyun 27 Apr '21

27 Apr '21

> -----Original Message----- > From: Huisong Li <lihuisong(a)huawei.com> > Sent: Tuesday, April 20, 2021 15:32 > To: dev(a)dpdk.org > Cc: Yigit, Ferruh <ferruh.yigit(a)intel.com>; Li, Xiaoyun <xiaoyun.li(a)intel.com>; > linuxarm(a)openeuler.org; lihuisong(a)huawei.com > Subject: [PATCH V2 1/7] app/testpmd: fix forward lcores number when DCB test > > Currently, 'nb_fwd_lcores' value are both adjusted based on 'nb_fwd_streams' in > rss/simple/icmp_echo_fwd_config_setup. > But the operation is missing in dcb_fwd_config_setup, which may lead to a bad > behavior in which multiple polling threads operate on the same queue. This patch is OK. But commit log is redundant and confusing. The above is enough to explain what your patch is doing and can even be more simple. >In this > case, the device sends and receives packets, causing unexpected results. The > procedure is as follows: I don't understand what you're saying here. The commands you're showing is 8 nbcores dealing with 16 queues. So it's one thread dealing with multiple queues which doesn't have issues at all. Please remove the useless and confusing commands. > 1/ run testpmd with "--rxq=8 --txq=8" > 2/ port stop all > 3/ set nbcore 8 > 4/ port config 0 dcb vt off 4 pfc on > 5/ port config all rxq 16 > 6/ port config all txq 16 > 7/ port start all > 8/ set fwd mac > 9/ start > > For the DCB forwarding test, each core is assigned to each traffic class and each > core is assigned a multi-stream. > Therefore, 'nb_fwd_lcores' value needs to be adjusted based on 'total_tc_num' > in all forwarding ports. Please refer to the RSS fwd config fix patch to write your own commit log. Use simple and easy-understanding words to explain yourself. Below is the reference of RSS. commit 017d680a91fcf30da14a6d3a2f96d41f6dda3a0f Author: Pablo de Lara <pablo.de.lara.guarch(a)intel.com> Date: Mon Jun 27 23:35:19 2016 +0100 app/testpmd: limit number of forwarding cores Number of forwarding cores must be equal or less than number of forwarding streams, otherwise two cores would try to use a same queue on a port, which is not allowed. > > Fixes: 900550de04a7 ("app/testpmd: add dcb support") > Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings") > Cc: stable(a)dpdk.org > > Signed-off-by: Huisong Li <lihuisong(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- > app/test-pmd/config.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index > ccb9bd3..03ee40c 100644 > --- a/app/test-pmd/config.c > +++ b/app/test-pmd/config.c > @@ -2961,6 +2961,21 @@ rss_fwd_config_setup(void) > } > } > > +static uint16_t > +get_fwd_port_total_tc_num(void) > +{ > + struct rte_eth_dcb_info dcb_info; > + uint16_t total_tc_num = 0; > + unsigned int i; > + > + for (i = 0; i < nb_fwd_ports; i++) { > + (void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info); > + total_tc_num += dcb_info.nb_tcs; > + } > + > + return total_tc_num; > +} > + > /** > * For the DCB forwarding test, each core is assigned on each traffic class. > * > @@ -2980,12 +2995,16 @@ dcb_fwd_config_setup(void) > lcoreid_t lc_id; > uint16_t nb_rx_queue, nb_tx_queue; > uint16_t i, j, k, sm_id = 0; > + uint16_t total_tc_num; > uint8_t tc = 0; > > cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores; > cur_fwd_config.nb_fwd_ports = nb_fwd_ports; > cur_fwd_config.nb_fwd_streams = > (streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports); > + total_tc_num = get_fwd_port_total_tc_num(); > + if (cur_fwd_config.nb_fwd_lcores > total_tc_num) > + cur_fwd_config.nb_fwd_lcores = total_tc_num; > > /* reinitialize forwarding streams */ > init_fwd_streams(); > -- > 2.7.4

1 0

Re: [PATCH] sched/fair: don't use waker's cpu if the waker of sync wake-up is interrupt
by Mike Galbraith 27 Apr '21

27 Apr '21

On Tue, 2021-04-27 at 14:37 +1200, Barry Song wrote: > > To fix this issue, this patch checks the waker of sync wake-up is a task > but not an interrupt. In this case, the waker will schedule out and give > CPU to wakee. That rash "the waker will schedule out" assumption, ie this really really is a synchronous wakeup, may be true in your particular case, but the sync hint is so overused as to be fairly meaningless. We've squabbled with it repeatedly over the years because of that. It really should either become more of a communication of intent than it currently is, or just go away. I'd argue for go away, simply because there is no way for the kernel to know that there isn't more work directly behind any particular wakeup. Take a pipe, does shoving some bits through a pipe mean you have no further use of your CPU? IFF you're doing nothing but playing ping- pong, sure it does, but how many real proggies have zero overlap among its threads of execution? The mere notion of threaded apps having no overlap *to be converted to throughput* is dainbramaged, which should be the death knell of the sync wakeup hint. Threaded apps can't do stuff like, oh, networking, which uses the sync hint heavily, without at least to some extent defeating the purpose of threading if we were to take the hint seriously. Heck, just look at the beauty (gak) of wake_wide(). It was born specifically to combat the pure-evil side of the sync wakeup hint. Bah, 'nuff "Danger Will Robinson, that thing will *eat you*!!" ;-) -Mike

2 4

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Alex Williamson 26 Apr '21

26 Apr '21

On Wed, 21 Apr 2021 17:59:02 +0800 liulongfang <liulongfang(a)huawei.com> wrote: > On 2021/4/21 6:04, Alex Williamson wrote: > > On Tue, 20 Apr 2021 09:59:57 -0300 > > Jason Gunthorpe <jgg(a)nvidia.com> wrote: > > > >> On Tue, Apr 20, 2021 at 08:50:12PM +0800, liulongfang wrote: > >>> On 2021/4/19 20:33, Jason Gunthorpe wrote: > >>>> On Mon, Apr 19, 2021 at 08:24:40PM +0800, liulongfang wrote: > >>>> > >>>>>> I'm also confused how this works securely at all, as a general rule a > >>>>>> VFIO PCI driver cannot access the MMIO memory of the function it is > >>>>>> planning to assign to the guest. There is a lot of danger that the > >>>>>> guest could access that MMIO space one way or another. > >>>>> > >>>>> VF's MMIO memory is divided into two parts, one is the guest part, > >>>>> and the other is the live migration part. They do not affect each other, > >>>>> so there is no security problem. > >>>> > >>>> AFAIK there are several scenarios where a guest can access this MMIO > >>>> memory using DMA even if it is not mapped into the guest for CPU > >>>> access. > >>>> > >>> The hardware divides VF's MMIO memory into two parts. The live migration > >>> driver in the host uses the live migration part, and the device driver in > >>> the guest uses the guest part. They obtain the address of VF's MMIO memory > >>> in their respective drivers, although these two parts The memory is > >>> continuous on the hardware device, but due to the needs of the drive function, > >>> they will not perform operations on another part of the memory, and the > >>> device hardware also independently responds to the operation commands of > >>> the two parts. > >> > >> It doesn't matter, the memory is still under the same PCI BDF and VFIO > >> supports scenarios where devices in the same IOMMU group are not > >> isolated from each other. > >> > >> This is why the granual of isolation is a PCI BDF - VFIO directly > >> blocks kernel drivers from attaching to PCI BDFs that are not > >> completely isolated from VFIO BDF. > >> > >> Bypassing this prevention and attaching a kernel driver directly to > >> the same BDF being exposed to the guest breaks that isolation model. > >> > >>> So, I still don't understand what the security risk you are talking about is, > >>> and what do you think the security design should look like? > >>> Can you elaborate on it? > >> > >> Each security domain must have its own PCI BDF. > >> > >> The migration control registers must be on a different VF from the VF > >> being plugged into a guest and the two VFs have to be in different > >> IOMMU groups to ensure they are isolated from each other. > > > > I think that's a solution, I don't know if it's the only solution. > > AIUI, the issue here is that we have a device specific kernel driver > > extending vfio-pci with migration support for this device by using an > > If the two parts of the MMIO region are split into different BAR spaces on > the device, the MMIO region of the business function is still placed in BAR2, > and the MMIO region of the live migration function is moved to BAR4. > Only BAR2 is mapped in the guest. only BAR4 is mapped in the host. > This can solve this security issue. The concern is really the "on the device" part rather than whether the resources are within the same BAR or not. We need to assume that a user driver can generate a DMA targeting any address in the system, including in this case the user driver could generate a DMA targeting this migration BAR. Ideally this would be routed upstream to the IOMMU where it would be blocked for lack of a translation entry. However, because this range resides on the same PCIe requester ID, it's logically more similar to a two-function device where the functions are considered non-isolated and are therefore exposed within the same IOMMU group. We would not allow a kernel driver for one of those functions and a userspace driver for the other. In this case those drivers are strongly related, but we still need to consider to what extent a malicious user driver can interfere with or exploit the kernel side driver. > > MMIO region of the same device. This is susceptible to DMA> manipulation by the user device. Whether that's a security issue or> not depends on how the user can break the device. If the scope is > > limited to breaking their own device, they can do that any number of > > ways and it's not very interesting. If the user can manipulate device > > state in order to trigger an exploit of the host-side kernel driver, > > that's obviously more of a problem. > > > > The other side of this is that if migration support can be implemented > > entirely within the VF using this portion of the device MMIO space, why > > do we need the host kernel to support this rather than implementing it > > in userspace? For example, QEMU could know about this device, > > manipulate the BAR size to expose only the operational portion of MMIO > > to the VM and use the remainder to support migration itself. I'm > > afraid that just like mdev, the vfio migration uAPI is going to be used > > as an excuse to create kernel drivers simply to be able to make use of > > that uAPI. I haven't looked at this driver to know if it has some > > When the accelerator device is designed to support the live migration > function, it is based on the uAPI of the migration region to realize the > live migration function, so the live migration function requires a driver > that connects to this uAPI. > Is this set of interfaces not open to us now? In your model, if both BARs are exposed to userspace and a device specific extension in QEMU claims the migration BAR rather than exposing it to the VM, could that driver mimic the migration region uAPI from userspace? For example, you don't need page pinning to interact with the IOMMU, you don't need resources beyond the scope of the endpoint device itself, and the migration info BAR is safe for userspace to manage? If so, then a kernel-based driver to expose a migration uAPI seems like it's only a risk for the kernel, ie. moving what could be a userspace driver into the kernel for the convenience of re-using a kernel uAPI. Thanks, Alex

2 1

Re: [PATCH V4] ethdev: add queue state when retrieve queue information
by Thomas Monjalon 26 Apr '21

26 Apr '21

16/04/2021 10:46, Lijun Ou: > Currently, upper-layer application could get queue state only > through pointers such as dev->data->tx_queue_state[queue_id], > this is not the recommended way to access it. So this patch > add get queue state when call rte_eth_rx_queue_info_get and > rte_eth_tx_queue_info_get API. > > Note: After add queue_state field, the 'struct rte_eth_rxq_info' size > remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so > it could be ABI compatible. [...] > --- a/doc/guides/rel_notes/release_21_05.rst > +++ b/doc/guides/rel_notes/release_21_05.rst > @@ -251,6 +251,12 @@ ABI Changes > function was already marked as internal in the API documentation for it, > and was not for use by external applications. > > +* Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure > + to provide indicated rxq queue state. > + > +* Added new field ``queue_state`` to ``rte_eth_txq_info`` structure > + to provide indicated txq queue state. Not sure we should add a note here for additions which do not break ABI compatibility. It may be confusing.

4 6

Re: [PATCH 2/2] Documentation/ABI: Move the topology-related sysfs interface to the right place
by Song Bao Hua (Barry Song) 26 Apr '21

26 Apr '21

> -----Original Message----- > From: tiantao (H) > Sent: Monday, April 26, 2021 2:26 PM > To: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com> > Cc: linuxarm(a)openeuler.org; tiantao (H) <tiantao6(a)hisilicon.com> > Subject: [PATCH 2/2] Documentation/ABI: Move the topology-related sysfs > interface to the right place > > Move the interface that exists under > /sys/devices/system/cpu/cpuX/topology/ to the more logical > Documentation/ABI/ file that can be properly parsed and > displayed to the user space > > Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> > Signed-off-by: Barry Song <song.bao.hua(a)hisilicon.com> > --- > Documentation/ABI/stable/sysfs-devices-system-cpu | 149 > ++++++++++++++++++++++ > Documentation/admin-guide/cputopology.rst | 104 --------------- > 2 files changed, 149 insertions(+), 104 deletions(-) > > diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu > b/Documentation/ABI/stable/sysfs-devices-system-cpu > index 33c133e..7d0b23e 100644 > --- a/Documentation/ABI/stable/sysfs-devices-system-cpu > +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu > @@ -1,3 +1,7 @@ > +Export CPU topology info via sysfs. Items (attributes) are similar > +to /proc/cpuinfo output of some architectures. They reside in > +/sys/devices/system/cpu/cpuX/topology/: > + > What: /sys/devices/system/cpu/dscr_default > Date: 13-May-2014 > KernelVersion: v3.15.0 > @@ -23,3 +27,148 @@ Description: Default value for the Data Stream Control > Register (DSCR) on > here). > If set by a process it will be inherited by child processes. > Values: 64 bit unsigned integer (bit field) > + > +What: /sys/devices/system/cpu/cpuX/topology/physical_package_id > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: physical package id of cpuX. Typically corresponds to a > physical > + socket number, but the actual value is architecture and platform > + dependent. > +Values: 64 bit unsigned integer (bit field) > + > +What: /sys/devices/system/cpu/cpuX/topology/die_id > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: the CPU die ID of cpuX. Typically it is the hardware platform's > + identifier (rather than the kernel's). The actual value is > + architecture and platform dependent. > +Values: 64 bit unsigned integer (bit field) > + > +What: /sys/devices/system/cpu/cpuX/topology/core_id > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: the CPU core ID of cpuX. Typically it is the hardware platform's > + identifier (rather than the kernel's). The actual value is > + architecture and platform dependent. > +Values: 64 bit unsigned integer (bit field) > + > +What: /sys/devices/system/cpu/cpuX/topology/book_id > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: the book ID of cpuX. Typically it is the hardware platform's > + identifier (rather than the kernel's). The actual value is > + architecture and platform dependent. > +Values: 64 bit unsigned integer (bit field) > + > +What: /sys/devices/system/cpu/cpuX/topology/drawer_id > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: the drawer ID of cpuX. Typically it is the hardware platform's > + identifier (rather than the kernel's). The actual value is > + architecture and platform dependent. > +Values: 64 bit unsigned integer (bit field) > + > +What: /sys/devices/system/cpu/cpuX/topology/core_cpus > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: internal kernel map of CPUs within the same core. > + (deprecated name: "thread_siblings") > +Values: hexadecimal bitmask. > + > +What: /sys/devices/system/cpu/cpuX/topology/core_cpus_list > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: human-readable list of CPUs within the same core. > + The format is like 0-3, 8-11, 14,17. The maximum size is PAGE_SIZE, > + so the tail of the string will be trimmed while its size is larger > + than PAGE_SIZE. > + (deprecated name: "thread_siblings_list"). > +Values: hexadecimal bitmask. No. this is a list not a mask. > + > +What: /sys/devices/system/cpu/cpuX/topology/package_cpus > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: internal kernel map of the CPUs sharing the same > physical_package_id. > + (deprecated name: "core_siblings"). > +Values: 64 bit unsigned integer (bit field) Id is unsigned integer. Here it is hexadecimal bitmask. > + > +What: /sys/devices/system/cpu/cpuX/topology/package_cpus_list > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: human-readable list of CPUs sharing the same > physical_package_id. > + The format is like 0-3, 8-11, 14,17. The maximum size is PAGE_SIZE, > + so the tail of the string will be trimmed while its size is larger > + than PAGE_SIZE. > + (deprecated name: "core_siblings_list") > +Values: hexadecimal bitmask. As above. > + > +What: /sys/devices/system/cpu/cpuX/topology/die_cpus > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: internal kernel map of CPUs within the same die. > +Values: 64 bit unsigned integer (bit field) As above. > + > +What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: human-readable list of CPUs within the same die. > + The format is like 0-3, 8-11, 14,17. The maximum size is PAGE_SIZE, > + so the tail of the string will be trimmed while its size is larger > + than PAGE_SIZE. > +Values: hexadecimal bitmask. As above. > + > +What: /sys/devices/system/cpu/cpuX/topology/book_siblings > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: internal kernel map of cpuX's hardware threads within the same > + book_id. > +Values: 64 bit unsigned integer (bit field) As above. > + > +What: /sys/devices/system/cpu/cpuX/topology/book_siblings_list > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: human-readable list of cpuX's hardware threads within the same > + book_id. > + The format is like 0-3, 8-11, 14,17. The maximum size is PAGE_SIZE, > + so the tail of the string will be trimmed while its size is larger > + than PAGE_SIZE. For example here we should mark it "available to s390 only" > +Values: hexadecimal bitmask. > + > +What: /sys/devices/system/cpu/cpuX/topology/drawer_siblings > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: internal kernel map of cpuX's hardware threads within the same > + drawer_id. > +Values: 64 bit unsigned integer (bit field) > + > +What: /sys/devices/system/cpu/cpuX/topology/drawer_siblings_list > +Date: 19-Mar-2021 > +KernelVersion: v5.12 > +Contact: > +Description: human-readable list of cpuX's hardware threads within the same > + drawer_id. > + The format is like 0-3, 8-11, 14,17. The maximum size is PAGE_SIZE, > + so the tail of the string will be trimmed while its size is larger > + than PAGE_SIZE. > +Values: hexadecimal bitmask. > + > +Architecture-neutral, drivers/base/topology.c, exports these attributes. > +However, the book and drawer related sysfs files will only be created if > +CONFIG_SCHED_BOOK and CONFIG_SCHED_DRAWER are selected, respectively. > + > +CONFIG_SCHED_BOOK and CONFIG_SCHED_DRAWER are currently only used on s390, > +where they reflect the cpu and cache hierarchy. These are not ABIs, better to be in original doc. Better to describe drawer ABI, book ABIs are only available for s390 in the ABI description. > diff --git a/Documentation/admin-guide/cputopology.rst > b/Documentation/admin-guide/cputopology.rst > index 4538d78..4672465 100644 > --- a/Documentation/admin-guide/cputopology.rst > +++ b/Documentation/admin-guide/cputopology.rst > @@ -2,110 +2,6 @@ > How CPU topology info is exported via sysfs > =========================================== > > -Export CPU topology info via sysfs. Items (attributes) are similar > -to /proc/cpuinfo output of some architectures. They reside in > -/sys/devices/system/cpu/cpuX/topology/: > - > -physical_package_id: > - > - physical package id of cpuX. Typically corresponds to a physical > - socket number, but the actual value is architecture and platform > - dependent. > - > -die_id: > - > - the CPU die ID of cpuX. Typically it is the hardware platform's > - identifier (rather than the kernel's). The actual value is > - architecture and platform dependent. > - > -core_id: > - > - the CPU core ID of cpuX. Typically it is the hardware platform's > - identifier (rather than the kernel's). The actual value is > - architecture and platform dependent. > - > -book_id: > - > - the book ID of cpuX. Typically it is the hardware platform's > - identifier (rather than the kernel's). The actual value is > - architecture and platform dependent. > - > -drawer_id: > - > - the drawer ID of cpuX. Typically it is the hardware platform's > - identifier (rather than the kernel's). The actual value is > - architecture and platform dependent. > - > -core_cpus: > - > - internal kernel map of CPUs within the same core. > - (deprecated name: "thread_siblings") > - > -core_cpus_list: > - > - human-readable list of CPUs within the same core. > - The format is like 0-3, 8-11, 14,17. The maximum size is PAGE_SIZE, > - so the tail of the string will be trimmed while its size is larger > - than PAGE_SIZE. > - (deprecated name: "thread_siblings_list"); > - > -package_cpus: > - > - internal kernel map of the CPUs sharing the same physical_package_id. > - (deprecated name: "core_siblings") > - > -package_cpus_list: > - > - human-readable list of CPUs sharing the same physical_package_id. > - The format is like 0-3, 8-11, 14,17. The maximum size is PAGE_SIZE, > - so the tail of the string will be trimmed while its size is larger > - than PAGE_SIZE. > - (deprecated name: "core_siblings_list") > - > -die_cpus: > - > - internal kernel map of CPUs within the same die. > - > -die_cpus_list: > - > - human-readable list of CPUs within the same die. > - The format is like 0-3, 8-11, 14,17. The maximum size is PAGE_SIZE, > - so the tail of the string will be trimmed while its size is larger > - than PAGE_SIZE. > - > -book_siblings: > - > - internal kernel map of cpuX's hardware threads within the same > - book_id. > - > -book_siblings_list: > - > - human-readable list of cpuX's hardware threads within the same > - book_id. > - The format is like 0-3, 8-11, 14,17. The maximum size is PAGE_SIZE, > - so the tail of the string will be trimmed while its size is larger > - than PAGE_SIZE. > - > -drawer_siblings: > - > - internal kernel map of cpuX's hardware threads within the same > - drawer_id. > - > -drawer_siblings_list: > - > - human-readable list of cpuX's hardware threads within the same > - drawer_id. > - The format is like 0-3, 8-11, 14,17. The maximum size is PAGE_SIZE, > - so the tail of the string will be trimmed while its size is larger > - than PAGE_SIZE. > - > -Architecture-neutral, drivers/base/topology.c, exports these attributes. > -However, the book and drawer related sysfs files will only be created if > -CONFIG_SCHED_BOOK and CONFIG_SCHED_DRAWER are selected, respectively. > - > -CONFIG_SCHED_BOOK and CONFIG_SCHED_DRAWER are currently only used on s390, > -where they reflect the cpu and cache hierarchy. > - > For an architecture to support this feature, it must define some of > these macros in include/asm-XXX/topology.h:: > > -- > 2.7.4

1 0

[PATCH 0/2] clarify and cleanup CPU and NUMA topology ABIs
by Tian Tao 26 Apr '21

26 Apr '21

patch #1: Move the interface that exists under /sys/devices/system/cpu/cpuX/topology/ to the more logical Documentation/ABI/ file that can be properly parsed and displayed to the user space. patch #2: clarify the overflow issue of sysfs pagebuf, and Move the presence of BUILD_BUG_ON to more sensible place. Tian Tao (2): CPU, NUMA topology ABIs: clarify and cleanup CPU and NUMA topology ABIs cpumask: clarify the overflow issue of sysfs pagebuf Documentation/ABI/stable/sysfs-devices-node | 4 + Documentation/ABI/stable/sysfs-devices-system-cpu | 149 ++++++++++++++++++++++ Documentation/admin-guide/cputopology.rst | 89 ------------- drivers/base/node.c | 3 - include/linux/cpumask.h | 9 +- 5 files changed, 161 insertions(+), 93 deletions(-) -- 2.7.4

1 2

Re: [dpdk-dev] [PATCH V5] ethdev: add queue state when retrieve queue information
by Kinsella, Ray 23 Apr '21

23 Apr '21

On 17/04/2021 04:09, Lijun Ou wrote: > Currently, upper-layer application could get queue state only > through pointers such as dev->data->tx_queue_state[queue_id], > this is not the recommended way to access it. So this patch > add get queue state when call rte_eth_rx_queue_info_get and > rte_eth_tx_queue_info_get API. > > Note: After add queue_state field, the 'struct rte_eth_rxq_info' size > remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so > it could be ABI compatible. > > Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > Acked-by: Konstantin Ananyev <konstantin.ananyev(a)intel.com> > --- > V4->V5: > - Add acked-by > - add a note to the "New features" section to annouce the new feature. > > V3->V4: > - update libabigail.abignore for removing the CI warnings > > V2->V3: > - rewrite the commit log and delete the part Note > - rewrite tht comments for queue state > - move the queue_state definition locations > > V1->V2: > - move queue state defines to public file > --- > doc/guides/rel_notes/release_21_05.rst | 6 ++++++ > lib/librte_ethdev/ethdev_driver.h | 7 ------- > lib/librte_ethdev/rte_ethdev.c | 3 +++ > lib/librte_ethdev/rte_ethdev.h | 9 +++++++++ > 4 files changed, 18 insertions(+), 7 deletions(-) > > diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst > index 58272e1..1ab3681 100644 > --- a/doc/guides/rel_notes/release_21_05.rst > +++ b/doc/guides/rel_notes/release_21_05.rst > @@ -81,6 +81,12 @@ New Features > representor=[[c#]pf#]sf# sf[0,2-1023] /* 1023 SFs. */ > representor=[c#]pf# c2pf[0,1] /* 2 PFs on controller 2. */ > > +* **Enhanced function for getting rxq/txq info ABI.** > + * Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure to > + provide indicated rxq queue state. > + * Added new field ``queue_state`` to ``rte_eth_txq_info`` structure to > + provide indicated txq queue state. > + > * **Added support for meter PPS profile.** > > Currently meter algorithms only supports bytes per second(BPS). > diff --git a/lib/librte_ethdev/ethdev_driver.h b/lib/librte_ethdev/ethdev_driver.h > index 113129d..40e474a 100644 > --- a/lib/librte_ethdev/ethdev_driver.h > +++ b/lib/librte_ethdev/ethdev_driver.h > @@ -952,13 +952,6 @@ struct eth_dev_ops { > }; > > /** > - * RX/TX queue states > - */ > -#define RTE_ETH_QUEUE_STATE_STOPPED 0 > -#define RTE_ETH_QUEUE_STATE_STARTED 1 > -#define RTE_ETH_QUEUE_STATE_HAIRPIN 2 > - > -/** > * @internal > * Check if the selected Rx queue is hairpin queue. > * > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c > index c73d263..d5adf4f 100644 > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > @@ -5038,6 +5038,8 @@ rte_eth_rx_queue_info_get(uint16_t port_id, uint16_t queue_id, > > memset(qinfo, 0, sizeof(*qinfo)); > dev->dev_ops->rxq_info_get(dev, queue_id, qinfo); > + qinfo->queue_state = dev->data->rx_queue_state[queue_id]; > + > return 0; > } > > @@ -5078,6 +5080,7 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id, > > memset(qinfo, 0, sizeof(*qinfo)); > dev->dev_ops->txq_info_get(dev, queue_id, qinfo); > + qinfo->queue_state = dev->data->tx_queue_state[queue_id]; > > return 0; > } > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h > index 3b773b6..a0d01d2 100644 > --- a/lib/librte_ethdev/rte_ethdev.h > +++ b/lib/librte_ethdev/rte_ethdev.h > @@ -1588,6 +1588,13 @@ struct rte_eth_dev_info { > }; > > /** > + * RX/TX queue states > + */ > +#define RTE_ETH_QUEUE_STATE_STOPPED 0 > +#define RTE_ETH_QUEUE_STATE_STARTED 1 > +#define RTE_ETH_QUEUE_STATE_HAIRPIN 2 > + > +/** > * Ethernet device RX queue information structure. > * Used to retrieve information about configured queue. > */ > @@ -1595,6 +1602,7 @@ struct rte_eth_rxq_info { > struct rte_mempool *mp; /**< mempool used by that queue. */ > struct rte_eth_rxconf conf; /**< queue config parameters. */ > uint8_t scattered_rx; /**< scattered packets RX supported. */ > + uint8_t queue_state; /**< one of RTE_ETH_QUEUE_STATE_*. */ Are we sure this is a false positive? - it is being added mid-structure on the rx-side at least. Shouldn't this be appended to the end - unless it is being sneaked into padding between fields. > uint16_t nb_desc; /**< configured number of RXDs. */ > uint16_t rx_buf_size; /**< hardware receive buffer size. */ > } __rte_cache_min_aligned; > @@ -1606,6 +1614,7 @@ struct rte_eth_rxq_info { > struct rte_eth_txq_info { > struct rte_eth_txconf conf; /**< queue config parameters. */ > uint16_t nb_desc; /**< configured number of TXDs. */ > + uint8_t queue_state; /**< one of RTE_ETH_QUEUE_STATE_*. */ > } __rte_cache_min_aligned; > > /* Generic Burst mode flag definition, values can be ORed. */ >

2 2

Re: [PATCH V6] app/test-pmd: support cleanup txq mbufs command
by Ferruh Yigit 21 Apr '21

21 Apr '21

On 4/21/2021 9:45 AM, Lijun Ou wrote: > From: Chengwen Feng <fengchengwen(a)huawei.com> > > This patch supports cleanup txq mbufs command: > port cleanup (port_id) txq (queue_id) (free_cnt) > > Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> Reviewed-by: Ferruh Yigit <ferruh.yigit(a)intel.com> Applied to dpdk-next-net/main, thanks.

1 0

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Jason Gunthorpe 21 Apr '21

21 Apr '21

On Tue, Apr 20, 2021 at 08:50:12PM +0800, liulongfang wrote: > On 2021/4/19 20:33, Jason Gunthorpe wrote: > > On Mon, Apr 19, 2021 at 08:24:40PM +0800, liulongfang wrote: > > > >>> I'm also confused how this works securely at all, as a general rule a > >>> VFIO PCI driver cannot access the MMIO memory of the function it is > >>> planning to assign to the guest. There is a lot of danger that the > >>> guest could access that MMIO space one way or another. > >> > >> VF's MMIO memory is divided into two parts, one is the guest part, > >> and the other is the live migration part. They do not affect each other, > >> so there is no security problem. > > > > AFAIK there are several scenarios where a guest can access this MMIO > > memory using DMA even if it is not mapped into the guest for CPU > > access. > > > The hardware divides VF's MMIO memory into two parts. The live migration > driver in the host uses the live migration part, and the device driver in > the guest uses the guest part. They obtain the address of VF's MMIO memory > in their respective drivers, although these two parts The memory is > continuous on the hardware device, but due to the needs of the drive function, > they will not perform operations on another part of the memory, and the > device hardware also independently responds to the operation commands of > the two parts. It doesn't matter, the memory is still under the same PCI BDF and VFIO supports scenarios where devices in the same IOMMU group are not isolated from each other. This is why the granual of isolation is a PCI BDF - VFIO directly blocks kernel drivers from attaching to PCI BDFs that are not completely isolated from VFIO BDF. Bypassing this prevention and attaching a kernel driver directly to the same BDF being exposed to the guest breaks that isolation model. > So, I still don't understand what the security risk you are talking about is, > and what do you think the security design should look like? > Can you elaborate on it? Each security domain must have its own PCI BDF. The migration control registers must be on a different VF from the VF being plugged into a guest and the two VFs have to be in different IOMMU groups to ensure they are isolated from each other. Jason

3 3

Re: [PATCH net v4 1/2] net: sched: fix packet stuck problem for lockless qdisc
by Michal Kubecek 21 Apr '21

21 Apr '21

On Wed, Apr 21, 2021 at 04:21:54PM +0800, Yunsheng Lin wrote: > > I tried using below shell to simulate your testcase: > > #!/bin/sh > > for((i=0; i<20; i++)) > do > taskset -c 0-31 netperf -t TCP_STREAM -H 192.168.100.2 -l 30 -- -m 1048576 > done > > And I got a quite stable result: 9413~9416 (10^6bits/sec) for 10G netdev. Perhaps try it without the taskset, in my test, there was only one connection. > > > > https://github.com/mkubecek/nperf > > > > It is still raw and a lot of features are missing but it can be already > > used for multithreaded TCP_STREAM and TCP_RR tests. In particular, the > > output above was with > > > > nperf -H 172.17.1.1 -l 30 -i 20 --exact -t TCP_STREAM -M 1 > > I tried your nperf too, unfortunately it does not seem to work on my > system(arm64), which exits very quickly and output the blow result: > > root@(none):/home# nperf -H 192.168.100.2 -l 30 -i 20 --exact -t TCP_STREAM -M 1 > server: 192.168.100.2, port 12543 > iterations: 20, threads: 1, test length: 30 > test: TCP_STREAM, message size: 1048576 > > 1 4.0 B/s, avg 4.0 B/s, mdev 0.0 B/s ( 0.0%) [...] Did you start nperfd on the other side? (It plays a role similar to netserver for netperf.) Few days ago I noticed that there is something wrong with error handling in case of failed connection but didn't get to fixing it yet. I'll try running some tests also on other architectures, including arm64 and s390x (to catch potential endinanity issues). Michal

1 0

Re: [PATCH V5] app/test-pmd: support cleanup txq mbufs command
by Ferruh Yigit 21 Apr '21

21 Apr '21

On 4/21/2021 9:09 AM, Lijun Ou wrote: > From: Chengwen Feng <fengchengwen(a)huawei.com> > > This patch supports cleanup txq mbufs command: > port cleanup (port_id) txq (queue_id) (free_cnt) > > Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- > V4->V5: > - rewrite patch title > - define the new cmd. > - Fix the comments given by Ferruh.yigit > > V3->V4: > - revert the V3 scheme. > > V2->V3: > - The command implementation is changed so that the queuestate does > not depend on the command execution. > > V1->V2: > - use Tx instead of TX > - add note in doc > --- > app/test-pmd/cmdline.c | 85 +++++++++++++++++++++++++++++ > doc/guides/rel_notes/release_21_05.rst | 2 + > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 +++ > 3 files changed, 96 insertions(+) > Can you please update 'cmd_help_long_parsed' for the help string, this was in v4 and seems dropped during change.

1 0

Re: [Intel-wired-lan] [PATCH V2 net] ice: Re-organizes reqstd/avail {R, T}XQ check/code for efficiency+readability
by Paul Menzel 21 Apr '21

21 Apr '21

Dear Salil, Thank you very much for your patch. In the git commit message summary, could you please use imperative mood [1]? > Re-organize reqstd/avail {R, T}XQ check/code for efficiency+readability It’s a bit long though. Maybe: > Avoid unnecessary assignment with user specified {R,T}XQs Am 14.04.21 um 00:44 schrieb Salil Mehta: > If user has explicitly requested the number of {R,T}XQs, then it is > unnecessary to get the count of already available {R,T}XQs from the > PF avail_{r,t}xqs bitmap. This value will get overridden by user specified > value in any case. > > This patch does minor re-organization of the code for improving the flow > and readabiltiy. This scope of improvement was found during the review of readabil*it*y > the ICE driver code. > > FYI, I could not test this change due to unavailability of the hardware. > It would be helpful if somebody can test this patch and provide Tested-by > Tag. Many thanks! This should go outside the commit message (below the --- for example). > Fixes: 87324e747fde ("ice: Implement ethtool ops for channels") Did you check the behavior before is actually a bug? Or is it just for the detection heuristic for commits to be applied to the stable series? > Cc: intel-wired-lan(a)lists.osuosl.org > Cc: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> > Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> > -- > Change V1->V2 > (*) Fixed the comments from Anthony Nguyen(Intel) > Link: https://lkml.org/lkml/2021/4/12/1997 > --- > drivers/net/ethernet/intel/ice/ice_lib.c | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c > index d13c7fc8fb0a..d77133d6baa7 100644 > --- a/drivers/net/ethernet/intel/ice/ice_lib.c > +++ b/drivers/net/ethernet/intel/ice/ice_lib.c > @@ -161,12 +161,13 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16 vf_id) > > switch (vsi->type) { > case ICE_VSI_PF: > - vsi->alloc_txq = min3(pf->num_lan_msix, > - ice_get_avail_txq_count(pf), > - (u16)num_online_cpus()); > if (vsi->req_txq) { > vsi->alloc_txq = vsi->req_txq; > vsi->num_txq = vsi->req_txq; > + } else { > + vsi->alloc_txq = min3(pf->num_lan_msix, > + ice_get_avail_txq_count(pf), > + (u16)num_online_cpus()); > } I am curious, did you check the compiler actually creates different code, or did it notice the inefficiency by itself and optimized it already? > > pf->num_lan_tx = vsi->alloc_txq; > @@ -175,12 +176,13 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16 vf_id) > if (!test_bit(ICE_FLAG_RSS_ENA, pf->flags)) { > vsi->alloc_rxq = 1; > } else { > - vsi->alloc_rxq = min3(pf->num_lan_msix, > - ice_get_avail_rxq_count(pf), > - (u16)num_online_cpus()); > if (vsi->req_rxq) { > vsi->alloc_rxq = vsi->req_rxq; > vsi->num_rxq = vsi->req_rxq; > + } else { > + vsi->alloc_rxq = min3(pf->num_lan_msix, > + ice_get_avail_rxq_count(pf), > + (u16)num_online_cpus()); > } > } > Kind regards, Paul

2 3

Re: [PATCH net v4 1/2] net: sched: fix packet stuck problem for lockless qdisc
by Michal Kubecek 21 Apr '21

21 Apr '21

On Wed, Apr 21, 2021 at 09:52:40AM +0800, Yunsheng Lin wrote: > On 2021/4/21 4:34, Michal Kubecek wrote: > > However, I noticed something disturbing in the results of a simple > > 1-thread TCP_STREAM test (client sends data through a TCP connection to > > server using long writes, we measure the amount of data received by the > > server): > > > > server: 172.17.1.1, port 12543 > > iterations: 20, threads: 1, test length: 30 > > test: TCP_STREAM, message size: 1048576 > > > > 1 927403548.4 B/s, avg 927403548.4 B/s, mdev 0.0 B/s ( 0.0%) > > 2 1176317172.1 B/s, avg 1051860360.2 B/s, mdev 124456811.8 B/s ( 11.8%), confid. +/- 1581348251.3 B/s (150.3%) > > 3 927335837.8 B/s, avg 1010352186.1 B/s, mdev 117354970.3 B/s ( 11.6%), confid. +/- 357073677.2 B/s ( 35.3%) > > 4 1176728045.1 B/s, avg 1051946150.8 B/s, mdev 124576544.7 B/s ( 11.8%), confid. +/- 228863127.8 B/s ( 21.8%) > > 5 1176788216.3 B/s, avg 1076914563.9 B/s, mdev 122102985.3 B/s ( 11.3%), confid. +/- 169478943.5 B/s ( 15.7%) > > 6 1158167055.1 B/s, avg 1090456645.8 B/s, mdev 115504209.5 B/s ( 10.6%), confid. +/- 132805140.8 B/s ( 12.2%) > > 7 1176243474.4 B/s, avg 1102711907.0 B/s, mdev 111069717.1 B/s ( 10.1%), confid. +/- 110956822.2 B/s ( 10.1%) > > 8 1176771142.8 B/s, avg 1111969311.5 B/s, mdev 106744173.5 B/s ( 9.6%), confid. +/- 95417120.0 B/s ( 8.6%) > > 9 1176206364.6 B/s, avg 1119106761.8 B/s, mdev 102644185.2 B/s ( 9.2%), confid. +/- 83685200.5 B/s ( 7.5%) > > 10 1175888409.4 B/s, avg 1124784926.6 B/s, mdev 98855550.5 B/s ( 8.8%), confid. +/- 74537085.1 B/s ( 6.6%) > > 11 1176541407.6 B/s, avg 1129490061.2 B/s, mdev 95422224.8 B/s ( 8.4%), confid. +/- 67230249.7 B/s ( 6.0%) > > 12 934185352.8 B/s, avg 1113214668.9 B/s, mdev 106114984.5 B/s ( 9.5%), confid. +/- 70420712.5 B/s ( 6.3%) > > 13 1176550558.1 B/s, avg 1118086660.3 B/s, mdev 103339448.9 B/s ( 9.2%), confid. +/- 65002902.4 B/s ( 5.8%) > > 14 1176521808.8 B/s, avg 1122260599.5 B/s, mdev 100711151.3 B/s ( 9.0%), confid. +/- 60333655.0 B/s ( 5.4%) > > 15 1176744840.8 B/s, avg 1125892882.3 B/s, mdev 98240838.2 B/s ( 8.7%), confid. +/- 56319052.3 B/s ( 5.0%) > > 16 1176593778.5 B/s, avg 1129061688.3 B/s, mdev 95909740.8 B/s ( 8.5%), confid. +/- 52771633.5 B/s ( 4.7%) > > 17 1176583967.4 B/s, avg 1131857116.5 B/s, mdev 93715582.2 B/s ( 8.3%), confid. +/- 49669258.6 B/s ( 4.4%) > > 18 1176853301.8 B/s, avg 1134356904.5 B/s, mdev 91656530.2 B/s ( 8.1%), confid. +/- 46905244.8 B/s ( 4.1%) > > 19 1176592845.7 B/s, avg 1136579848.8 B/s, mdev 89709043.8 B/s ( 7.9%), confid. +/- 44424855.9 B/s ( 3.9%) > > 20 1176608117.3 B/s, avg 1138581262.2 B/s, mdev 87871692.6 B/s ( 7.7%), confid. +/- 42193098.5 B/s ( 3.7%) > > all avg 1138581262.2 B/s, mdev 87871692.6 B/s ( 7.7%), confid. +/- 42193098.5 B/s ( 3.7%) > > > > Each line shows result of one 30 second long test and average, mean > > deviation and 99% confidence interval half width through the iterations > > so far. While 17 iteration results are essentially the wire speed minus > > TCP overhead, iterations 1, 3 and 12 are more than 20% lower. As results > > of the same test on unpatched 5.12-rc7 are much more consistent (the > > lowest iteration result through the whole test was 1175939718.3 and the > > mean deviation only 276889.1 B/s), it doesn't seeem to be just a random > > fluctuation. > > I think I need to relearn the statistial math to understand the above > "99% confidence interval half width ":) An easy way to understand it is that if the last column shows 42 MB/s, it means that with 99% confidence (probability), the measured average is within 42 MB/s off the actual one. > But the problem do not seems related too much with "99% confidence > interval half width ", but with "mean deviation"? Mean deviation is a symptom here. What worries me is that most results show the same value (corresponding to fully saturated line) with very little variation, in some iterations (1, 3 and 12 here) we can suddenly see much lower value (by ~2.5 GB/s, i.e. 20-25%). And as each iteration runs the connection for 30 seconds, it cannot be just some short glitch. I managed to get tcpdump captures yesterday but they are huge even with "-s 128" (client ~5.6 GB, server ~9.0 GB) so that working with them is rather slow so I did not find anything interesting yet. > I tried using netperf, which seems only show throughput of 9415.06 > (10^6bits/sec) using 10G netdev. which tool did you used to show the > above number? 9415.06 * 10^6 b/s is 1176.9 * 10^6 B/s so it's about the same as the numbers above (the good ones, that is). As this was part of a longer test trying different thread counts from 1 to 128, I was using another utility I started writing recently: https://github.com/mkubecek/nperf It is still raw and a lot of features are missing but it can be already used for multithreaded TCP_STREAM and TCP_RR tests. In particular, the output above was with nperf -H 172.17.1.1 -l 30 -i 20 --exact -t TCP_STREAM -M 1 The results are with 1 thread so that they should be also reproducible with netperf too. But it needs to be repeated enough times, when I wanted to get the packet captures, I did 40 iterations and only two of them showed lower result. Michal

1 0

[RFC PATCH v5 0/4] scheduler: expose the topology of clusters and add cluster scheduler
by Barry Song 21 Apr '21

21 Apr '21

ARM64 server chip Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each cluster has 4 cpus. All clusters share L3 cache data while each cluster has local L3 tag. On the other hand, each cluster will share some internal system bus. This means cache is much more affine inside one cluster than across clusters. +-----------------------------------+ +---------+ | +------+ +------+ +---------------------------+ | | | CPU0 | | cpu1 | | +-----------+ | | | +------+ +------+ | | | | | | +----+ L3 | | | | +------+ +------+ cluster | | tag | | | | | CPU2 | | CPU3 | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | | | L3 | | | | +------+ +------+ +----+ tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | L3 | | data | +-----------------------------------+ | | | +------+ +------+ | +-----------+ | | | | | | | | | | | | | +------+ +------+ +----+ L3 | | | | | | tag | | | | +------+ +------+ | | | | | | | | | | ++ +-----------+ | | | +------+ +------+ |---------------------------+ | +-----------------------------------| | | +-----------------------------------| | | | +------+ +------+ +---------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | +----+ L3 | | | | +------+ +------+ | | tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | There is a similar need for clustering in x86. Some x86 cores could share L2 caches that is similar to the cluster in Kupeng 920 (e.g. on Jacobsville there are 6 clusters of 4 Atom cores, each cluster sharing a separate L2, and 24 cores sharing L3). Having a sched_domain for clusters will bring two aspects of improvement: 1. spreading unrelated tasks among clusters, which decreases the contention of resources and improve the throughput. unrelated tasks might be put randomly without cluster sched_domain: +-------------------+ +-----------------+ | +----+ +----+ | | | | |task| |task| | | | | |1 | |2 | | | | | +----+ +----+ | | | | | | | | cluster1 | | cluster2 | +-------------------+ +-----------------+ but with cluster sched_domain, they are likely to spread due to LB: +-------------------+ +-----------------+ | +----+ | | +----+ | | |task| | | |task| | | |1 | | | |2 | | | +----+ | | +----+ | | | | | | cluster1 | | cluster2 | +-------------------+ +-----------------+ 2. gathering related tasks within a cluster, which improves the cache affinity of tasks talking with each other. Without cluster sched_domain, related tasks might be put randomly. In case task1-8 have relationship as below: Task1 wakes up task4 Task2 wakes up task5 Task3 wakes up task6 Task4 wakes up task7 With the tuning of select_idle_cpu() to scan local cluster first, those tasks might get a chance to be gathered like: +---------------------------+ +----------------------+ | +----+ +-----+ | | +----+ +-----+ | | |task| |task | | | |task| |task | | | |1 | | 4 | | | |2 | |5 | | | +----+ +-----+ | | +----+ +-----+ | | | | | | cluster1 | | cluster2 | | | | | | | | | | +-----+ +------+ | | +-----+ +------+ | | |task | | task | | | |task | |task | | | |3 | | 6 | | | |4 | |8 | | | +-----+ +------+ | | +-----+ +------+ | +---------------------------+ +----------------------+ Otherwise, the result might be: +---------------------------+ +----------------------+ | +----+ +-----+ | | +----+ +-----+ | | |task| |task | | | |task| |task | | | |1 | | 2 | | | |5 | |6 | | | +----+ +-----+ | | +----+ +-----+ | | | | | | cluster1 | | cluster2 | | | | | | | | | | +-----+ +------+ | | +-----+ +------+ | | |task | | task | | | |task | |task | | | |3 | | 4 | | | |7 | |8 | | | +-----+ +------+ | | +-----+ +------+ | +---------------------------+ +----------------------+ -v5: * split "add scheduler level for clusters" into two patches to evaluate the impact of spreading and gathering separately; * add a tracepoint of select_idle_cpu for debug purpose; add bcc script in commit log; * add cluster_id = -1 in reset_cpu_topology() * rebased to tip/sched/core -v4: * rebased to tip/sched/core with the latest unified code of select_idle_cpu * added Tim's patch for x86 Jacobsville * also added benchmark data of spreading unrelated tasks * avoided the iteration of sched_domain by moving to static_key(addressing Vincent's comment * used acpi_cpu_id for acpi_find_processor_node(addressing Masa's comment) Barry Song (2): scheduler: add scheduler level for clusters scheduler: scan idle cpu in cluster before scanning the whole llc Jonathan Cameron (1): topology: Represent clusters of CPUs within a die Tim Chen (1): scheduler: Add cluster scheduler level for x86 Documentation/admin-guide/cputopology.rst | 26 +++++++++++-- arch/arm64/Kconfig | 7 ++++ arch/arm64/kernel/topology.c | 2 + arch/x86/Kconfig | 8 ++++ arch/x86/include/asm/smp.h | 7 ++++ arch/x86/include/asm/topology.h | 1 + arch/x86/kernel/cpu/cacheinfo.c | 1 + arch/x86/kernel/cpu/common.c | 3 ++ arch/x86/kernel/smpboot.c | 43 ++++++++++++++++++++- drivers/acpi/pptt.c | 63 +++++++++++++++++++++++++++++++ drivers/base/arch_topology.c | 15 ++++++++ drivers/base/topology.c | 10 +++++ include/linux/acpi.h | 5 +++ include/linux/arch_topology.h | 5 +++ include/linux/sched/cluster.h | 19 ++++++++++ include/linux/sched/topology.h | 7 ++++ include/linux/topology.h | 13 +++++++ include/trace/events/sched.h | 22 +++++++++++ kernel/sched/core.c | 20 ++++++++++ kernel/sched/fair.c | 36 +++++++++++++++++- kernel/sched/sched.h | 1 + kernel/sched/topology.c | 5 +++ 22 files changed, 313 insertions(+), 6 deletions(-) create mode 100644 include/linux/sched/cluster.h -- 1.8.3.1

5 14

Re: [PATCH] lib: bitmap: check the overflow of pagebuf
by Song Bao Hua (Barry Song) 21 Apr '21

21 Apr '21

> -----Original Message----- > From: tiantao (H) > Sent: Tuesday, April 20, 2021 11:49 PM > To: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; Jonathan Cameron > <jonathan.cameron(a)huawei.com> > Cc: linuxarm(a)openeuler.org; tiantao (H) <tiantao6(a)hisilicon.com> > Subject: [PATCH] lib: bitmap: check the overflow of pagebuf > > Move the detection of pagebuf overflow from node_read_cpumap to the > more appropriate bitmap_print_to_pagebuf function. Other interfaces > call bitmap_print_to_pagebuf to print without pagebuf overflow due > to too many cpus. This is far from a good commit log to describe the background. > > Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> > --- > drivers/base/node.c | 3 --- > lib/bitmap.c | 3 +++ > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/base/node.c b/drivers/base/node.c > index 2c36f61d..e24530c3 100644 > --- a/drivers/base/node.c > +++ b/drivers/base/node.c > @@ -33,9 +33,6 @@ static ssize_t node_read_cpumap(struct device *dev, bool list, > char *buf) > cpumask_var_t mask; > struct node *node_dev = to_node(dev); > > - /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */ > - BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1)); > - > if (!alloc_cpumask_var(&mask, GFP_KERNEL)) > return 0; > > diff --git a/lib/bitmap.c b/lib/bitmap.c > index 74ceb02..170fc48 100644 > --- a/lib/bitmap.c > +++ b/lib/bitmap.c > @@ -482,6 +482,9 @@ int bitmap_print_to_pagebuf(bool list, char *buf, const > unsigned long *maskp, > { > ptrdiff_t len = PAGE_SIZE - offset_in_page(buf); > > + /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */ > + BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1)); > + I don't think it is the right place. expecting cpumap_print_to_pagebuf. BTW, it is not 2008/04/07 now, so just remove it. > return list ? scnprintf(buf, len, "%*pbl\n", nmaskbits, maskp) : > scnprintf(buf, len, "%*pb\n", nmaskbits, maskp); > } > -- > 2.7.4 I would prefer we send two patches as a series "clarify and cleanup CPU and NUMA topology ABIs" with a cover letter with the below as 1/2. 2/2 would be the patch moving the place of cpu topology ABI doc. From b32c0c00a187d4fe4c49d54d30650b0cacb2c351 Mon Sep 17 00:00:00 2001 From: Tian Tao <tiantao6(a)hisilicon.com> Date: Wed, 21 Apr 2021 14:36:11 +1200 Subject: [PATCH 1/2] CPU, NUMA topology ABIs: clarify the overflow issue of sysfs pagebuf Both numa node and cpu use cpu bitmap like 3,ffffffff to expose hardware topology. When cpu number is large, the page buffer of sysfs will over- flow. This doesn't really happen nowadays as the maximum NR_CPUS is 8196 for X86_64 and 4096 for ARM64 since 8196 * 9 / 32 = 2305 which is still smaller than 4KB page size. So this BUILD_BUG_ON() is pretty much preventing future problems similar with Y2K. On the other hand, it should be more sensible to move the guard to common code which can protect both cpu and numa: /sys/devices/system/cpu/cpu0/topology/die_cpus etc. /sys/devices/system/node/node0/cpumap etc. Topology bitmaps shouldn't be larger than PAGE_SIZE as lstopo and numactl depend on them. But other ABIs exposing cpu lists are not really used by common applications, so this patch also marks those lists could be trimmed. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> Signed-off-by: Barry Song <song.bao.hua(a)hisilicon.com> --- Documentation/ABI/stable/sysfs-devices-node | 5 ++++- Documentation/admin-guide/cputopology.rst | 15 +++++++++++++++ drivers/base/node.c | 3 --- include/linux/cpumask.h | 6 ++++++ 4 files changed, 25 insertions(+), 4 deletions(-) diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node index 484fc04bcc25..9832a17b2b15 100644 --- a/Documentation/ABI/stable/sysfs-devices-node +++ b/Documentation/ABI/stable/sysfs-devices-node @@ -47,7 +47,10 @@ What: /sys/devices/system/node/nodeX/cpulist Date: October 2002 Contact: Linux Memory Management list <linux-mm(a)kvack.org> Description: - The CPUs associated to the node. + The CPUs associated to the node. The format is like 0-3, + 8-11, 12-13. The maximum size is PAGE_SIZE, so the tail + of the string will be trimmed while its size is larger + than PAGE_SIZE. What: /sys/devices/system/node/nodeX/meminfo Date: October 2002 diff --git a/Documentation/admin-guide/cputopology.rst b/Documentation/admin-guide/cputopology.rst index b90dafcc8237..8fac776a5ffa 100644 --- a/Documentation/admin-guide/cputopology.rst +++ b/Documentation/admin-guide/cputopology.rst @@ -44,6 +44,9 @@ core_cpus: core_cpus_list: human-readable list of CPUs within the same core. + The format is like 0-3, 8-11, 12-13. The maximum size is PAGE_SIZE, + so the tail of the string will be trimmed while its size is larger + than PAGE_SIZE. (deprecated name: "thread_siblings_list"); package_cpus: @@ -54,6 +57,9 @@ package_cpus: package_cpus_list: human-readable list of CPUs sharing the same physical_package_id. + The format is like 0-3, 8-11, 12-13. The maximum size is PAGE_SIZE, + so the tail of the string will be trimmed while its size is larger + than PAGE_SIZE. (deprecated name: "core_siblings_list") die_cpus: @@ -63,6 +69,9 @@ die_cpus: die_cpus_list: human-readable list of CPUs within the same die. + The format is like 0-3, 8-11, 12-13. The maximum size is PAGE_SIZE, + so the tail of the string will be trimmed while its size is larger + than PAGE_SIZE. book_siblings: @@ -73,6 +82,9 @@ book_siblings_list: human-readable list of cpuX's hardware threads within the same book_id. + The format is like 0-3, 8-11, 12-13. The maximum size is PAGE_SIZE, + so the tail of the string will be trimmed while its size is larger + than PAGE_SIZE. drawer_siblings: @@ -83,6 +95,9 @@ drawer_siblings_list: human-readable list of cpuX's hardware threads within the same drawer_id. + The format is like 0-3, 8-11, 12-13. The maximum size is PAGE_SIZE, + so the tail of the string will be trimmed while its size is larger + than PAGE_SIZE. Architecture-neutral, drivers/base/topology.c, exports these attributes. However, the book and drawer related sysfs files will only be created if diff --git a/drivers/base/node.c b/drivers/base/node.c index f449dbb2c746..50324d06bcd5 100644 --- a/drivers/base/node.c +++ b/drivers/base/node.c @@ -33,9 +33,6 @@ static ssize_t node_read_cpumap(struct device *dev, bool list, char *buf) cpumask_var_t mask; struct node *node_dev = to_node(dev); - /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */ - BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1)); - if (!alloc_cpumask_var(&mask, GFP_KERNEL)) return 0; diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h index 383684e30f12..81f145e0c742 100644 --- a/include/linux/cpumask.h +++ b/include/linux/cpumask.h @@ -12,6 +12,7 @@ #include <linux/bitmap.h> #include <linux/atomic.h> #include <linux/bug.h> +#include <asm/page.h> /* Don't assign or return these: may not be this big! */ typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t; @@ -924,6 +925,11 @@ static inline const struct cpumask *get_cpu_mask(unsigned int cpu) static inline ssize_t cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask) { + /* + * 32bits requires 9bytes: "ff,ffffffff", thus, too many CPUs will + * cause the overflow of sysfs pagebuf + */ + BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1)); return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask), nr_cpu_ids); } -- 2.25.1 Thanks Barry

1 0

Re: [RFC PATCH v5 4/4] scheduler: Add cluster scheduler level for x86
by Song Bao Hua (Barry Song) 21 Apr '21

21 Apr '21

> -----Original Message----- > From: Tim Chen [mailto:tim.c.chen@linux.intel.com] > Sent: Wednesday, April 21, 2021 6:32 AM > To: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; > catalin.marinas(a)arm.com; will(a)kernel.org; rjw(a)rjwysocki.net; > vincent.guittot(a)linaro.org; bp(a)alien8.de; tglx(a)linutronix.de; > mingo(a)redhat.com; lenb(a)kernel.org; peterz(a)infradead.org; > dietmar.eggemann(a)arm.com; rostedt(a)goodmis.org; bsegall(a)google.com; > mgorman(a)suse.de > Cc: msys.mizuma(a)gmail.com; valentin.schneider(a)arm.com; > gregkh(a)linuxfoundation.org; Jonathan Cameron <jonathan.cameron(a)huawei.com>; > juri.lelli(a)redhat.com; mark.rutland(a)arm.com; sudeep.holla(a)arm.com; > aubrey.li(a)linux.intel.com; linux-arm-kernel(a)lists.infradead.org; > linux-kernel(a)vger.kernel.org; linux-acpi(a)vger.kernel.org; x86(a)kernel.org; > xuwei (O) <xuwei5(a)huawei.com>; Zengtao (B) <prime.zeng(a)hisilicon.com>; > guodong.xu(a)linaro.org; yangyicong <yangyicong(a)huawei.com>; Liguozhu (Kenneth) > <liguozhu(a)hisilicon.com>; linuxarm(a)openeuler.org; hpa(a)zytor.com > Subject: Re: [RFC PATCH v5 4/4] scheduler: Add cluster scheduler level for x86 > > > > On 3/23/21 4:21 PM, Song Bao Hua (Barry Song) wrote: > > >> > >> On 3/18/21 9:16 PM, Barry Song wrote: > >>> From: Tim Chen <tim.c.chen(a)linux.intel.com> > >>> > >>> There are x86 CPU architectures (e.g. Jacobsville) where L2 cahce > >>> is shared among a cluster of cores instead of being exclusive > >>> to one single core. > >>> > >>> To prevent oversubscription of L2 cache, load should be > >>> balanced between such L2 clusters, especially for tasks with > >>> no shared data. > >>> > >>> Also with cluster scheduling policy where tasks are woken up > >>> in the same L2 cluster, we will benefit from keeping tasks > >>> related to each other and likely sharing data in the same L2 > >>> cluster. > >>> > >>> Add CPU masks of CPUs sharing the L2 cache so we can build such > >>> L2 cluster scheduler domain. > >>> > >>> Signed-off-by: Tim Chen <tim.c.chen(a)linux.intel.com> > >>> Signed-off-by: Barry Song <song.bao.hua(a)hisilicon.com> > >> > >> > >> Barry, > >> > >> Can you also add this chunk to the patch. > >> Thanks. > > > > Sure, Tim, Thanks. I'll put that into patch 4/4 in v6. > > > > Barry, > > This chunk will also need to be added to return cluster id for x86. > Please add it in your next rev. Yes. Thanks. I'll put this in either RFC v7 or Patch v1. For spreading path, things are much easier, though packing path is quite tricky. But It seems RFC v6 has been quite close to what we want to achieve to pack related tasks by scanning cluster for tasks within same NUMA: https://lore.kernel.org/lkml/20210420001844.9116-1-song.bao.hua@hisilicon.c… If couples have been already in same LLC(numa), scanning clusters will gather them further. If they are running in different NUMA nodes, the original scanning LLC will move them to the same node, after that, scanning cluster might put them closer to each other. it seems it is kind of the two-level packing Dietmar has suggested. So perhaps we won't have RFC v7, I will probably send patch v1 afterwards. > > Thanks. > > Tim > > --- > > diff --git a/arch/x86/include/asm/topology.h > b/arch/x86/include/asm/topology.h > index 800fa48c9fcd..2548d824f103 100644 > --- a/arch/x86/include/asm/topology.h > +++ b/arch/x86/include/asm/topology.h > @@ -109,6 +109,7 @@ extern const struct cpumask *cpu_clustergroup_mask(int cpu); > #define topology_physical_package_id(cpu) (cpu_data(cpu).phys_proc_id) > #define topology_logical_die_id(cpu) (cpu_data(cpu).logical_die_id) > #define topology_die_id(cpu) (cpu_data(cpu).cpu_die_id) > +#define topology_cluster_id(cpu) (per_cpu(cpu_l2c_id, cpu)) > #define topology_core_id(cpu) (cpu_data(cpu).cpu_core_id) > > extern unsigned int __max_die_per_package; Thanks Barry

1 0

[PATCH net v4 0/2] fix packet stuck problem for lockless qdisc
by Yunsheng Lin 21 Apr '21

21 Apr '21

This patchset fixes the packet stuck problem mentioned in [1]. Patch 1: Add STATE_MISSED flag to fix packet stuck problem. Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED flag is added in patch 1. V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED and add patch 2. [1]. https://lkml.org/lkml/2019/10/9/42 Yunsheng Lin (2): net: sched: fix packet stuck problem for lockless qdisc net: sched: fix endless tx action reschedule during deactivation include/net/pkt_sched.h | 7 +------ include/net/sch_generic.h | 37 ++++++++++++++++++++++++++++++++++++- net/core/dev.c | 26 ++++++++++++++++++++++---- net/sched/sch_generic.c | 16 +++++++++++++++- 4 files changed, 74 insertions(+), 12 deletions(-) -- 2.7.4

2 6

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Jason Gunthorpe 20 Apr '21

20 Apr '21

On Tue, Apr 20, 2021 at 09:28:46PM +0800, liulongfang wrote: > >> So, I still don't understand what the security risk you are talking about is, > >> and what do you think the security design should look like? > >> Can you elaborate on it? > > > > Each security domain must have its own PCI BDF. > > > The basic unit to perform the live migration function is the VF, and the basic > function of the VF is the business function of the device. If the live migration > function and the business function are completely separated, and they are bound > to their respective VFs, it will result in the ability to execute the business > in the guest A functional VF cannot perform live migration, and a VF with a live > migration function cannot perform business functions in the guest. > > In fact, the scenario that requires live migration is to migrate its business > functions to the VFs of other hosts when the VF's business functions are heavily > loaded. > This usage scenario itself requires that the VF needs to have these two functions > at the same time. Other vendors are managing, it is not an unsolvable problem. I think these patches can't advance in any form without somehow addressing the isolation issue. Jason

1 0

[PATCH net v3] net: sched: fix packet stuck problem for lockless qdisc
by Yunsheng Lin 20 Apr '21

20 Apr '21

Lockless qdisc has below concurrent problem: cpu0 cpu1 . . q->enqueue . . . qdisc_run_begin() . . . dequeue_skb() . . . sch_direct_xmit() . . . . q->enqueue . qdisc_run_begin() . return and do nothing . . qdisc_run_end() . cpu1 enqueue a skb without calling __qdisc_run() because cpu0 has not released the lock yet and spin_trylock() return false for cpu1 in qdisc_run_begin(), and cpu0 do not see the skb enqueued by cpu1 when calling dequeue_skb() because cpu1 may enqueue the skb after cpu0 calling dequeue_skb() and before cpu0 calling qdisc_run_end(). Lockless qdisc has below another concurrent problem when tx_action is involved: cpu0(serving tx_action) cpu1 cpu2 . . . . q->enqueue . . qdisc_run_begin() . . dequeue_skb() . . . q->enqueue . . . . sch_direct_xmit() . . . qdisc_run_begin() . . return and do nothing . . . clear __QDISC_STATE_SCHED . . qdisc_run_begin() . . return and do nothing . . . . . . qdisc_run_end() . This patch fixes the above data race by: 1. Get the flag before doing spin_trylock(). 2. If the first spin_trylock() return false and the flag is not set before the first spin_trylock(), Set the flag and retry another spin_trylock() in case other CPU may not see the new flag after it releases the lock. 3. reschedule if the flags is set after the lock is released at the end of qdisc_run_end(). For tx_action case, the flags is also set when cpu1 is at the end if qdisc_run_end(), so tx_action will be rescheduled again to dequeue the skb enqueued by cpu2. Only clear the flag before retrying a dequeuing when dequeuing returns NULL in order to reduce the overhead of the above double spin_trylock() and __netif_schedule() calling. The performance impact of this patch, tested using pktgen and dummy netdev with pfifo_fast qdisc attached: threads without+this_patch with+this_patch delta 1 2.61Mpps 2.60Mpps -0.3% 2 3.97Mpps 3.82Mpps -3.7% 4 5.62Mpps 5.59Mpps -0.5% 8 2.78Mpps 2.77Mpps -0.3% 16 2.22Mpps 2.22Mpps -0.0% Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking") Signed-off-by: Yunsheng Lin <linyunsheng(a)huawei.com> --- V3: fix a compile error and a few comment typo, remove the __QDISC_STATE_DEACTIVATED checking, and update the performance data. V2: Avoid the overhead of fixing the data race as much as possible. --- include/net/sch_generic.h | 38 +++++++++++++++++++++++++++++++++++++- net/sched/sch_generic.c | 12 ++++++++++++ 2 files changed, 49 insertions(+), 1 deletion(-) diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h index f7a6e14..e3f46eb 100644 --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h @@ -36,6 +36,7 @@ struct qdisc_rate_table { enum qdisc_state_t { __QDISC_STATE_SCHED, __QDISC_STATE_DEACTIVATED, + __QDISC_STATE_NEED_RESCHEDULE, }; struct qdisc_size_table { @@ -159,8 +160,38 @@ static inline bool qdisc_is_empty(const struct Qdisc *qdisc) static inline bool qdisc_run_begin(struct Qdisc *qdisc) { if (qdisc->flags & TCQ_F_NOLOCK) { + bool dont_retry = test_bit(__QDISC_STATE_NEED_RESCHEDULE, + &qdisc->state); + + if (spin_trylock(&qdisc->seqlock)) + goto nolock_empty; + + /* If the flag is set before doing the spin_trylock() and + * the above spin_trylock() return false, it means other cpu + * holding the lock will do dequeuing for us, or it wil see + * the flag set after releasing lock and reschedule the + * net_tx_action() to do the dequeuing. + */ + if (dont_retry) + return false; + + /* We could do set_bit() before the first spin_trylock(), + * and avoid doing second spin_trylock() completely, then + * we could have multi cpus doing the set_bit(). Here use + * dont_retry to avoid doing the set_bit() and the second + * spin_trylock(), which has 5% performance improvement than + * doing the set_bit() before the first spin_trylock(). + */ + set_bit(__QDISC_STATE_NEED_RESCHEDULE, + &qdisc->state); + + /* Retry again in case other CPU may not see the new flag + * after it releases the lock at the end of qdisc_run_end(). + */ if (!spin_trylock(&qdisc->seqlock)) return false; + +nolock_empty: WRITE_ONCE(qdisc->empty, false); } else if (qdisc_is_running(qdisc)) { return false; @@ -176,8 +207,13 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) static inline void qdisc_run_end(struct Qdisc *qdisc) { write_seqcount_end(&qdisc->running); - if (qdisc->flags & TCQ_F_NOLOCK) + if (qdisc->flags & TCQ_F_NOLOCK) { spin_unlock(&qdisc->seqlock); + + if (unlikely(test_bit(__QDISC_STATE_NEED_RESCHEDULE, + &qdisc->state))) + __netif_schedule(qdisc); + } } static inline bool qdisc_may_bulk(const struct Qdisc *qdisc) diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c index 44991ea..4953430 100644 --- a/net/sched/sch_generic.c +++ b/net/sched/sch_generic.c @@ -640,8 +640,10 @@ static struct sk_buff *pfifo_fast_dequeue(struct Qdisc *qdisc) { struct pfifo_fast_priv *priv = qdisc_priv(qdisc); struct sk_buff *skb = NULL; + bool need_retry = true; int band; +retry: for (band = 0; band < PFIFO_FAST_BANDS && !skb; band++) { struct skb_array *q = band2list(priv, band); @@ -652,6 +654,16 @@ static struct sk_buff *pfifo_fast_dequeue(struct Qdisc *qdisc) } if (likely(skb)) { qdisc_update_stats_at_dequeue(qdisc, skb); + } else if (need_retry && + test_and_clear_bit(__QDISC_STATE_NEED_RESCHEDULE, + &qdisc->state)) { + /* do another enqueuing after clearing the flag to + * avoid calling __netif_schedule(). + */ + smp_mb__after_atomic(); + need_retry = false; + + goto retry; } else { WRITE_ONCE(qdisc->empty, true); } -- 2.7.4

2 6

[RFC PATCH v6 4/4] scheduler: Add cluster scheduler level for x86
by Barry Song 20 Apr '21

20 Apr '21

From: Tim Chen <tim.c.chen(a)linux.intel.com> There are x86 CPU architectures (e.g. Jacobsville) where L2 cahce is shared among a cluster of cores instead of being exclusive to one single core. To prevent oversubscription of L2 cache, load should be balanced between such L2 clusters, especially for tasks with no shared data. Also with cluster scheduling policy where tasks are woken up in the same L2 cluster, we will benefit from keeping tasks related to each other and likely sharing data in the same L2 cluster. Add CPU masks of CPUs sharing the L2 cache so we can build such L2 cluster scheduler domain. Signed-off-by: Tim Chen <tim.c.chen(a)linux.intel.com> Signed-off-by: Barry Song <song.bao.hua(a)hisilicon.com> --- -v6: * added topology_cluster_cpumask() for x86, code provided by Tim. arch/x86/Kconfig | 8 ++++++++ arch/x86/include/asm/smp.h | 7 +++++++ arch/x86/include/asm/topology.h | 2 ++ arch/x86/kernel/cpu/cacheinfo.c | 1 + arch/x86/kernel/cpu/common.c | 3 +++ arch/x86/kernel/smpboot.c | 43 ++++++++++++++++++++++++++++++++++++++++- 6 files changed, 63 insertions(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 2792879..d597de2 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1002,6 +1002,14 @@ config NR_CPUS This is purely to save memory: each supported CPU adds about 8KB to the kernel image. +config SCHED_CLUSTER + bool "Cluster scheduler support" + default n + help + Cluster scheduler support improves the CPU scheduler's decision + making when dealing with machines that have clusters of CPUs + sharing L2 cache. If unsure say N here. + config SCHED_SMT def_bool y if SMP diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index c0538f8..9cbc4ae 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -16,7 +16,9 @@ DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_die_map); /* cpus sharing the last level cache: */ DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_llc_shared_map); +DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_l2c_shared_map); DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id); +DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_l2c_id); DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number); static inline struct cpumask *cpu_llc_shared_mask(int cpu) @@ -24,6 +26,11 @@ static inline struct cpumask *cpu_llc_shared_mask(int cpu) return per_cpu(cpu_llc_shared_map, cpu); } +static inline struct cpumask *cpu_l2c_shared_mask(int cpu) +{ + return per_cpu(cpu_l2c_shared_map, cpu); +} + DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid); DECLARE_EARLY_PER_CPU_READ_MOSTLY(u32, x86_cpu_to_acpiid); DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_bios_cpu_apicid); diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h index 9239399..800fa48 100644 --- a/arch/x86/include/asm/topology.h +++ b/arch/x86/include/asm/topology.h @@ -103,6 +103,7 @@ static inline void setup_node_to_cpumask_map(void) { } #include <asm-generic/topology.h> extern const struct cpumask *cpu_coregroup_mask(int cpu); +extern const struct cpumask *cpu_clustergroup_mask(int cpu); #define topology_logical_package_id(cpu) (cpu_data(cpu).logical_proc_id) #define topology_physical_package_id(cpu) (cpu_data(cpu).phys_proc_id) @@ -114,6 +115,7 @@ static inline void setup_node_to_cpumask_map(void) { } #ifdef CONFIG_SMP #define topology_die_cpumask(cpu) (per_cpu(cpu_die_map, cpu)) +#define topology_cluster_cpumask(cpu) (cpu_clustergroup_mask(cpu)) #define topology_core_cpumask(cpu) (per_cpu(cpu_core_map, cpu)) #define topology_sibling_cpumask(cpu) (per_cpu(cpu_sibling_map, cpu)) diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c index 3ca9be4..0d03a71 100644 --- a/arch/x86/kernel/cpu/cacheinfo.c +++ b/arch/x86/kernel/cpu/cacheinfo.c @@ -846,6 +846,7 @@ void init_intel_cacheinfo(struct cpuinfo_x86 *c) l2 = new_l2; #ifdef CONFIG_SMP per_cpu(cpu_llc_id, cpu) = l2_id; + per_cpu(cpu_l2c_id, cpu) = l2_id; #endif } diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index ab640ab..0ba282d 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -78,6 +78,9 @@ /* Last level cache ID of each logical CPU */ DEFINE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id) = BAD_APICID; +/* L2 cache ID of each logical CPU */ +DEFINE_PER_CPU_READ_MOSTLY(u16, cpu_l2c_id) = BAD_APICID; + /* correctly size the local cpu masks */ void __init setup_cpu_local_masks(void) { diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 02813a7..c85ffa8 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -101,6 +101,8 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_llc_shared_map); +DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_l2c_shared_map); + /* Per CPU bogomips and other parameters */ DEFINE_PER_CPU_READ_MOSTLY(struct cpuinfo_x86, cpu_info); EXPORT_PER_CPU_SYMBOL(cpu_info); @@ -501,6 +503,21 @@ static bool match_llc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) return topology_sane(c, o, "llc"); } +static bool match_l2c(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) +{ + int cpu1 = c->cpu_index, cpu2 = o->cpu_index; + + /* Do not match if we do not have a valid APICID for cpu: */ + if (per_cpu(cpu_l2c_id, cpu1) == BAD_APICID) + return false; + + /* Do not match if L2 cache id does not match: */ + if (per_cpu(cpu_l2c_id, cpu1) != per_cpu(cpu_l2c_id, cpu2)) + return false; + + return topology_sane(c, o, "l2c"); +} + /* * Unlike the other levels, we do not enforce keeping a * multicore group inside a NUMA node. If this happens, we will @@ -522,7 +539,7 @@ static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) } -#if defined(CONFIG_SCHED_SMT) || defined(CONFIG_SCHED_MC) +#if defined(CONFIG_SCHED_SMT) || defined(CONFIG_SCHED_CLUSTER) || defined(CONFIG_SCHED_MC) static inline int x86_sched_itmt_flags(void) { return sysctl_sched_itmt_enabled ? SD_ASYM_PACKING : 0; @@ -540,12 +557,21 @@ static int x86_smt_flags(void) return cpu_smt_flags() | x86_sched_itmt_flags(); } #endif +#ifdef CONFIG_SCHED_CLUSTER +static int x86_cluster_flags(void) +{ + return cpu_cluster_flags() | x86_sched_itmt_flags(); +} +#endif #endif static struct sched_domain_topology_level x86_numa_in_package_topology[] = { #ifdef CONFIG_SCHED_SMT { cpu_smt_mask, x86_smt_flags, SD_INIT_NAME(SMT) }, #endif +#ifdef CONFIG_SCHED_CLUSTER + { cpu_clustergroup_mask, x86_cluster_flags, SD_INIT_NAME(CLS) }, +#endif #ifdef CONFIG_SCHED_MC { cpu_coregroup_mask, x86_core_flags, SD_INIT_NAME(MC) }, #endif @@ -556,6 +582,9 @@ static int x86_smt_flags(void) #ifdef CONFIG_SCHED_SMT { cpu_smt_mask, x86_smt_flags, SD_INIT_NAME(SMT) }, #endif +#ifdef CONFIG_SCHED_CLUSTER + { cpu_clustergroup_mask, x86_cluster_flags, SD_INIT_NAME(CLS) }, +#endif #ifdef CONFIG_SCHED_MC { cpu_coregroup_mask, x86_core_flags, SD_INIT_NAME(MC) }, #endif @@ -583,6 +612,7 @@ void set_cpu_sibling_map(int cpu) if (!has_mp) { cpumask_set_cpu(cpu, topology_sibling_cpumask(cpu)); cpumask_set_cpu(cpu, cpu_llc_shared_mask(cpu)); + cpumask_set_cpu(cpu, cpu_l2c_shared_mask(cpu)); cpumask_set_cpu(cpu, topology_core_cpumask(cpu)); cpumask_set_cpu(cpu, topology_die_cpumask(cpu)); c->booted_cores = 1; @@ -598,6 +628,8 @@ void set_cpu_sibling_map(int cpu) if ((i == cpu) || (has_mp && match_llc(c, o))) link_mask(cpu_llc_shared_mask, cpu, i); + if ((i == cpu) || (has_mp && match_l2c(c, o))) + link_mask(cpu_l2c_shared_mask, cpu, i); } /* @@ -649,6 +681,11 @@ const struct cpumask *cpu_coregroup_mask(int cpu) return cpu_llc_shared_mask(cpu); } +const struct cpumask *cpu_clustergroup_mask(int cpu) +{ + return cpu_l2c_shared_mask(cpu); +} + static void impress_friends(void) { int cpu; @@ -1332,6 +1369,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus) zalloc_cpumask_var(&per_cpu(cpu_core_map, i), GFP_KERNEL); zalloc_cpumask_var(&per_cpu(cpu_die_map, i), GFP_KERNEL); zalloc_cpumask_var(&per_cpu(cpu_llc_shared_map, i), GFP_KERNEL); + zalloc_cpumask_var(&per_cpu(cpu_l2c_shared_map, i), GFP_KERNEL); } /* @@ -1556,7 +1594,10 @@ static void remove_siblinginfo(int cpu) cpumask_clear_cpu(cpu, topology_sibling_cpumask(sibling)); for_each_cpu(sibling, cpu_llc_shared_mask(cpu)) cpumask_clear_cpu(cpu, cpu_llc_shared_mask(sibling)); + for_each_cpu(sibling, cpu_l2c_shared_mask(cpu)) + cpumask_clear_cpu(cpu, cpu_l2c_shared_mask(sibling)); cpumask_clear(cpu_llc_shared_mask(cpu)); + cpumask_clear(cpu_l2c_shared_mask(cpu)); cpumask_clear(topology_sibling_cpumask(cpu)); cpumask_clear(topology_core_cpumask(cpu)); cpumask_clear(topology_die_cpumask(cpu)); -- 1.8.3.1

1 0

[PATCH net-next 0/3] net: hns3: misc updates for -next
by Huazhong Tan 20 Apr '21

20 Apr '21

This series includes some misc updates for the HNS3 ethernet driver. Huazhong Tan (3): net: hns3: remove a duplicate pf reset counting net: hns3: cleanup inappropriate spaces in struct hlcgevf_tqp_stats net: hns3: change the value of the SEPARATOR_VALUE macro in hclgevf_main.c drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 -- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 2 +- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 4 ++-- 3 files changed, 3 insertions(+), 5 deletions(-) -- 2.7.4

2 4

Re: [PATCH V4] app/testpmd: support Tx mbuf free on demand cmd
by Ferruh Yigit 19 Apr '21

19 Apr '21

On 4/19/2021 1:36 PM, Lijun Ou wrote: > From: Chengwen Feng <fengchengwen(a)huawei.com> > > This patch support tx_done_cleanup command: > tx_done_cleanup port (port_id) (queue_id) (free_cnt) > Instead of creating a new root level, 'tx_done_cleanup' command, what do you think to use existing port command, something like: "port cleanup <port_id> txq <queue_id> <free_cnt>" > Users must make sure there are no concurrent access to the same Tx > queue (like rte_eth_tx_burst, rte_eth_dev_tx_queue_stop and so on) > this command executed. > > Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- > V3->V4: > - revert the V3 scheme. > > V2->V3: > - The command implementation is changed so that the queuestate does > not depend on the command execution. > > V1->V2: > - use Tx instead of TX > - add note in doc > --- > app/test-pmd/cmdline.c | 84 +++++++++++++++++++++++++++++ > doc/guides/rel_notes/release_21_05.rst | 2 + > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 ++++ > 3 files changed, 97 insertions(+) > > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c > index 5bf1497..b43964d 100644 > --- a/app/test-pmd/cmdline.c > +++ b/app/test-pmd/cmdline.c > @@ -675,6 +675,9 @@ static void cmd_help_long_parsed(void *parsed_result, > "set port (port_id) ptype_mask (ptype_mask)\n" > " set packet types classification for a specific port\n\n" > > + "tx_done_cleanup (port_id) (queue_id) (free_cnt)\n" > + " Cleanup a Tx queue's mbuf on a port\n\n" > + If 'free_cnt' is '0', driver should free all possible mbufs, can you add this detail to help? > "set port (port_id) queue-region region_id (value) " > "queue_start_index (value) queue_num (value)\n" > " Set a queue region on a port\n\n" > @@ -16915,6 +16918,86 @@ cmdline_parse_inst_t cmd_showport_macs = { > }, > }; > > +/* *** tx_done_cleanup *** */ > +struct cmd_tx_done_cleanup_result { > + cmdline_fixed_string_t clean; > + cmdline_fixed_string_t port; > + uint16_t port_id; > + uint16_t queue_id; > + uint32_t free_cnt; > +}; > + > +static void > +cmd_tx_done_cleanup_parsed(void *parsed_result, > + __rte_unused struct cmdline *cl, > + __rte_unused void *data) > +{ > + struct cmd_tx_done_cleanup_result *res = parsed_result; > + uint16_t port_id = res->port_id; > + uint16_t queue_id = res->queue_id; > + uint32_t free_cnt = res->free_cnt; > + struct rte_eth_txq_info qinfo; > + int ret; > + > + if (rte_eth_tx_queue_info_get(port_id, queue_id, &qinfo)) { > + printf("Failed to get port %u Tx queue %u info!\n", > + port_id, queue_id); > + return; > + } > + > + if (qinfo.queue_state != RTE_ETH_QUEUE_STATE_STARTED) { > + printf("TX queue %u not started!\n", queue_id); > + return; > + } > + > + /* > + * rte_eth_tx_done_cleanup is a dataplane API, user must make sure > + * there are no concurrent access to the same Tx queue (like > + * rte_eth_tx_burst, rte_eth_dev_tx_queue_stop and so on) when this API > + * called. > + */ Should there be a check to see if testpmd forwarding is stared or not? This API shouldn't be allowed when forwarding is started. > + ret = rte_eth_tx_done_cleanup(port_id, queue_id, free_cnt); > + if (ret < 0) { > + printf("Failed to cleanup mbuf for port %u Tx queue %u " > + "error desc: %s(%d)\n", > + port_id, queue_id, strerror(-ret), ret); > + return; > + } > + > + printf("Cleanup port %u Tx queue %u mbuf nums: %u\n", > + port_id, queue_id, ret); > +} > + > +cmdline_parse_token_string_t cmd_tx_done_cleanup_clean = > + TOKEN_STRING_INITIALIZER(struct cmd_tx_done_cleanup_result, clean, > + "tx_done_cleanup"); > +cmdline_parse_token_string_t cmd_tx_done_cleanup_port = > + TOKEN_STRING_INITIALIZER(struct cmd_tx_done_cleanup_result, port, > + "port"); > +cmdline_parse_token_num_t cmd_tx_done_cleanup_port_id = > + TOKEN_NUM_INITIALIZER(struct cmd_tx_done_cleanup_result, port_id, > + UINT16); > +cmdline_parse_token_num_t cmd_tx_done_cleanup_queue_id = > + TOKEN_NUM_INITIALIZER(struct cmd_tx_done_cleanup_result, queue_id, > + UINT16); > +cmdline_parse_token_num_t cmd_tx_done_cleanup_free_cnt = > + TOKEN_NUM_INITIALIZER(struct cmd_tx_done_cleanup_result, free_cnt, > + UINT32); > + > +cmdline_parse_inst_t cmd_tx_done_cleanup = { > + .f = cmd_tx_done_cleanup_parsed, > + .data = NULL, > + .help_str = "tx_done_cleanup port <port_id> <queue_id> <free_cnt>", > + .tokens = { > + (void *)&cmd_tx_done_cleanup_clean, > + (void *)&cmd_tx_done_cleanup_port, > + (void *)&cmd_tx_done_cleanup_port_id, > + (void *)&cmd_tx_done_cleanup_queue_id, > + (void *)&cmd_tx_done_cleanup_free_cnt, > + NULL, > + }, > +}; > + > /* ******************************************************************************** */ > > /* list of instructions */ > @@ -17040,6 +17123,7 @@ cmdline_parse_ctx_t main_ctx[] = { > (cmdline_parse_inst_t *)&cmd_config_rss_reta, > (cmdline_parse_inst_t *)&cmd_showport_reta, > (cmdline_parse_inst_t *)&cmd_showport_macs, > + (cmdline_parse_inst_t *)&cmd_tx_done_cleanup, > (cmdline_parse_inst_t *)&cmd_config_burst, > (cmdline_parse_inst_t *)&cmd_config_thresh, > (cmdline_parse_inst_t *)&cmd_config_threshold, > diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst > index 4538bb9..554499f 100644 > --- a/doc/guides/rel_notes/release_21_05.rst > +++ b/doc/guides/rel_notes/release_21_05.rst > @@ -217,6 +217,8 @@ New Features > ``show port (port_id) rxq (queue_id) desc used count`` > * Added command to dump internal representation information of single flow. > ``flow dump (port_id) rule (rule_id)`` > + * Added command to cleanup a Tx queue's mbuf on a port. > + ``tx_done_cleanup port <port_id> <queue_id> <free_cnt>`` > > * **Updated ipsec-secgw sample application.** > > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > index a736e7d..6472647 100644 > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > @@ -270,6 +270,17 @@ and ready to be processed by the driver on a given RX queue:: > > testpmd> show port (port_id) rxq (queue_id) desc used count > > +cleanup txq mbufs > +~~~~~~~~~~~~~~~~~~~~~~~~ > + > +Request the driver to free mbufs currently cached by the driver for a given port's > +Tx queue:: > + testpmd> tx_done_cleanup port (port_id) (queue_id) (free_cnt) > + > +.. note:: > + This command is dangerous, users must make sure there are no cucurrent access to > + the same Tx queue (link rte_eth_tx_burst, rte_eth_dev_tx_queue_stop and so on). > + > show config > ~~~~~~~~~~~ > >

1 0

[PATCH] app/testpmd: support Tx mbuf free on demand cmd
by Lijun Ou 19 Apr '21

19 Apr '21

From: Chengwen Feng <fengchengwen(a)huawei.com> This patch support tx_done_cleanup command: tx_done_cleanup port (port_id) (queue_id) (free_cnt) User must make sure there are no concurrent access to the same Tx queue (like rte_eth_tx_burst, rte_eth_dev_tx_queue_stop and so on) when this command executed. Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> Signed-off-by: Lijun Ou <oulijun(a)huawei.com> --- app/test-pmd/cmdline.c | 91 +++++++++++++++++++++++++++++ doc/guides/rel_notes/release_21_05.rst | 2 + doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +++ 3 files changed, 100 insertions(+) diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index 14110eb..832ae70 100644 --- a/app/test-pmd/cmdline.c +++ b/app/test-pmd/cmdline.c @@ -36,6 +36,7 @@ #include <rte_pci.h> #include <rte_ether.h> #include <rte_ethdev.h> +#include <rte_ethdev_driver.h> #include <rte_string_fns.h> #include <rte_devargs.h> #include <rte_flow.h> @@ -675,6 +676,9 @@ static void cmd_help_long_parsed(void *parsed_result, "set port (port_id) ptype_mask (ptype_mask)\n" " set packet types classification for a specific port\n\n" + "tx_done_cleanup (port_id) (queue_id) (free_cnt)\n" + " Cleanup a tx queue's mbuf on a port\n\n" + "set port (port_id) queue-region region_id (value) " "queue_start_index (value) queue_num (value)\n" " Set a queue region on a port\n\n" @@ -16910,6 +16914,92 @@ cmdline_parse_inst_t cmd_showport_macs = { }, }; +/* *** tx_done_cleanup *** */ +struct cmd_tx_done_cleanup_result { + cmdline_fixed_string_t clean; + cmdline_fixed_string_t port; + uint16_t port_id; + uint16_t queue_id; + uint32_t free_cnt; +}; + +static void +cmd_tx_done_cleanup_parsed(void *parsed_result, + __rte_unused struct cmdline *cl, + __rte_unused void *data) +{ + struct cmd_tx_done_cleanup_result *res = parsed_result; + struct rte_eth_dev *dev; + uint16_t port_id = res->port_id; + uint16_t queue_id = res->queue_id; + uint32_t free_cnt = res->free_cnt; + int ret; + + if (!rte_eth_dev_is_valid_port(port_id)) { + printf("Invalid port_id %u\n", port_id); + return; + } + + dev = &rte_eth_devices[port_id]; + if (queue_id >= dev->data->nb_tx_queues) { + printf("Invalid TX queue_id %u\n", queue_id); + return; + } + + if (dev->data->tx_queue_state[queue_id] != + RTE_ETH_QUEUE_STATE_STARTED) { + printf("TX queue_id %u not started!\n", queue_id); + return; + } + + /* + * rte_eth_tx_done_cleanup is a dataplane API, user must make sure + * there are no concurrent access to the same Tx queue (like + * rte_eth_tx_burst, rte_eth_dev_tx_queue_stop and so on) when this API + * called. + */ + ret = rte_eth_tx_done_cleanup(port_id, queue_id, free_cnt); + if (ret < 0) { + printf("Failed to cleanup mbuf for port %u TX queue %u " + "error desc: %s(%d)\n", + port_id, queue_id, strerror(-ret), ret); + return; + } + + printf("Cleanup port %u TX queue %u mbuf nums: %u\n", + port_id, queue_id, ret); +} + +cmdline_parse_token_string_t cmd_tx_done_cleanup_clean = + TOKEN_STRING_INITIALIZER(struct cmd_tx_done_cleanup_result, clean, + "tx_done_cleanup"); +cmdline_parse_token_string_t cmd_tx_done_cleanup_port = + TOKEN_STRING_INITIALIZER(struct cmd_tx_done_cleanup_result, port, + "port"); +cmdline_parse_token_num_t cmd_tx_done_cleanup_port_id = + TOKEN_NUM_INITIALIZER(struct cmd_tx_done_cleanup_result, port_id, + UINT16); +cmdline_parse_token_num_t cmd_tx_done_cleanup_queue_id = + TOKEN_NUM_INITIALIZER(struct cmd_tx_done_cleanup_result, queue_id, + UINT16); +cmdline_parse_token_num_t cmd_tx_done_cleanup_free_cnt = + TOKEN_NUM_INITIALIZER(struct cmd_tx_done_cleanup_result, free_cnt, + UINT32); + +cmdline_parse_inst_t cmd_tx_done_cleanup = { + .f = cmd_tx_done_cleanup_parsed, + .data = NULL, + .help_str = "tx_done_cleanup port <port_id> <queue_id> <free_cnt>", + .tokens = { + (void *)&cmd_tx_done_cleanup_clean, + (void *)&cmd_tx_done_cleanup_port, + (void *)&cmd_tx_done_cleanup_port_id, + (void *)&cmd_tx_done_cleanup_queue_id, + (void *)&cmd_tx_done_cleanup_free_cnt, + NULL, + }, +}; + /* ******************************************************************************** */ /* list of instructions */ @@ -17035,6 +17125,7 @@ cmdline_parse_ctx_t main_ctx[] = { (cmdline_parse_inst_t *)&cmd_config_rss_reta, (cmdline_parse_inst_t *)&cmd_showport_reta, (cmdline_parse_inst_t *)&cmd_showport_macs, + (cmdline_parse_inst_t *)&cmd_tx_done_cleanup, (cmdline_parse_inst_t *)&cmd_config_burst, (cmdline_parse_inst_t *)&cmd_config_thresh, (cmdline_parse_inst_t *)&cmd_config_threshold, diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index 23f7f0b..8077573 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -69,6 +69,8 @@ New Features * Added command to display Rx queue used descriptor count. ``show port (port_id) rxq (queue_id) desc used count`` + * Added command to cleanup a Tx queue's mbuf on a port. + ``tx_done_cleanup port <port_id> <queue_id> <free_cnt>`` Removed Items diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index f59eb8a..39281f5 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -272,6 +272,13 @@ and ready to be processed by the driver on a given RX queue:: testpmd> show port (port_id) rxq (queue_id) desc used count +cleanup txq mbufs +~~~~~~~~~~~~~~~~~~~~~~~~ + +Request the driver to free mbufs currently cached by the driver for a given port's +Tx queue:: + testpmd> tx_done_cleanup port (port_id) (queue_id) (free_cnt) + show config ~~~~~~~~~~~ -- 2.7.4

7 22

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Jason Gunthorpe 19 Apr '21

19 Apr '21

On Mon, Apr 19, 2021 at 08:24:40PM +0800, liulongfang wrote: > > I'm also confused how this works securely at all, as a general rule a > > VFIO PCI driver cannot access the MMIO memory of the function it is > > planning to assign to the guest. There is a lot of danger that the > > guest could access that MMIO space one way or another. > > VF's MMIO memory is divided into two parts, one is the guest part, > and the other is the live migration part. They do not affect each other, > so there is no security problem. AFAIK there are several scenarios where a guest can access this MMIO memory using DMA even if it is not mapped into the guest for CPU access. > If pci_release_mem_regions() is not added here, > The guests using pci_request_mem_regions() will return an error. > Then, the guest will not be able to obtain the MMIO address of the VF. Which is why VFIO has this protection to prevent sharing MMIO regions on the VF assigned to the guest Jason

1 0

Re: [PATCH v7] ethdev: add queue state when retrieve queue information
by Thomas Monjalon 19 Apr '21

19 Apr '21

19/04/2021 10:57, Lijun Ou: > Currently, upper-layer application could get queue state only > through pointers such as dev->data->tx_queue_state[queue_id], > this is not the recommended way to access it. So this patch > add get queue state when call rte_eth_rx_queue_info_get and > rte_eth_tx_queue_info_get API. > > Note: After add queue_state field, the 'struct rte_eth_rxq_info' size > remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so > it could be ABI compatible. > > Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > Acked-by: Konstantin Ananyev <konstantin.ananyev(a)intel.com> Acked-by: Thomas Monjalon <thomas(a)monjalon.net>

2 1

Re: [dpdk-dev] [PATCH V6] ethdev: add queue state when retrieve queue information
by Thomas Monjalon 19 Apr '21

19 Apr '21

19/04/2021 04:03, Lijun Ou: > --- a/doc/guides/rel_notes/release_21_05.rst > +++ b/doc/guides/rel_notes/release_21_05.rst > +* **Enhanced function for getting rxq/txq info ABI.** Reword: Added queue state in queried Rx/Tx queue info > + * Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure to > + provide indicated rxq queue state. s/rxq queue/Rx queue/ > + * Added new field ``queue_state`` to ``rte_eth_txq_info`` structure to > + provide indicated txq queue state. s/txq queue/Tx queue/ Thanks

2 1

Re: [dpdk-dev] [PATCH V4 0/3] add Hisilicon kunpeng CPU support
by Thomas Monjalon 19 Apr '21

19 Apr '21

16/04/2021 11:57, Lijun Ou: > Chengchang Tang (3): > config/arm: add Hisilicon kunpeng implementer > config/arm: add kunpeng920 cross target > config/arm: add kunpeng930 cross target Squashed, sorted SoCs alphabetically with others, and applied.

1 0

Re: [PATCH v3] iommu/iova: put free_iova_mem() outside of spinlock iova_rbtree_lock
by John Garry 19 Apr '21

19 Apr '21

On 19/04/2021 08:13, chenxiang wrote: > From: Xiang Chen<chenxiang66(a)hisilicon.com> > > It is not necessary to put free_iova_mem() inside of spinlock/unlock > iova_rbtree_lock which only leads to more completion for the spinlock. > It has a small promote on the performance after the change. And also > rename private_free_iova() as remove_iova() because the function will not > free iova after that change. > > Signed-off-by: Xiang Chen<chenxiang66(a)hisilicon.com> I think that you will need to resend after v5.13-rc1 comes out, however: Reviewed-by: John Garry <john.garry(a)huawei.com> > --- > drivers/iommu/

1 0

Re: [PATCH V5] ethdev: add queue state when retrieve queue information
by Ferruh Yigit 18 Apr '21

18 Apr '21

On 4/17/2021 4:09 AM, Lijun Ou wrote: > Currently, upper-layer application could get queue state only > through pointers such as dev->data->tx_queue_state[queue_id], > this is not the recommended way to access it. So this patch > add get queue state when call rte_eth_rx_queue_info_get and > rte_eth_tx_queue_info_get API. > > Note: After add queue_state field, the 'struct rte_eth_rxq_info' size > remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so > it could be ABI compatible. > > Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > Acked-by: Konstantin Ananyev <konstantin.ananyev(a)intel.com> > --- > V4->V5: > - Add acked-by > - add a note to the "New features" section to annouce the new feature. > > V3->V4: > - update libabigail.abignore for removing the CI warnings > > V2->V3: > - rewrite the commit log and delete the part Note > - rewrite tht comments for queue state > - move the queue_state definition locations > > V1->V2: > - move queue state defines to public file > --- > doc/guides/rel_notes/release_21_05.rst | 6 ++++++ > lib/librte_ethdev/ethdev_driver.h | 7 ------- > lib/librte_ethdev/rte_ethdev.c | 3 +++ > lib/librte_ethdev/rte_ethdev.h | 9 +++++++++ > 4 files changed, 18 insertions(+), 7 deletions(-) missing 'libabigail.abignore' that was in v4?

1 0

Re: [dpdk-dev] [PATCH V4] ethdev: add queue state when retrieve queue information
by Ananyev, Konstantin 16 Apr '21

16 Apr '21

> Currently, upper-layer application could get queue state only > through pointers such as dev->data->tx_queue_state[queue_id], > this is not the recommended way to access it. So this patch > add get queue state when call rte_eth_rx_queue_info_get and > rte_eth_tx_queue_info_get API. > > Note: After add queue_state field, the 'struct rte_eth_rxq_info' size > remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so > it could be ABI compatible. > > Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> > --- > devtools/libabigail.abignore | 12 +++++++++++- > doc/guides/rel_notes/release_21_05.rst | 6 ++++++ > lib/librte_ethdev/ethdev_driver.h | 7 ------- > lib/librte_ethdev/rte_ethdev.c | 3 +++ > lib/librte_ethdev/rte_ethdev.h | 9 +++++++++ > 5 files changed, 29 insertions(+), 8 deletions(-) > > diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore > index 6c0b389..54542a8 100644 > --- a/devtools/libabigail.abignore > +++ b/devtools/libabigail.abignore > @@ -19,4 +19,14 @@ > ; Ignore fields inserted in cacheline boundary of rte_cryptodev > [suppress_type] > name = rte_cryptodev > - has_data_member_inserted_between = {offset_after(attached), end} > \ No newline at end of file > + has_data_member_inserted_between = {offset_after(attached), end} > + > +; Ignore fields inserted in alignment hole of rte_eth_rxq_info > +[suppress_type] > + name = rte_eth_rxq_info > + has_data_member_inserted_at = offset_after(scattered_rx) > + > +; Ignore fields inserted in cacheline boundary of rte_eth_txq_info > +[suppress_type] > + name = rte_eth_txq_info > + has_data_member_inserted_between = {offset_after(nb_desc), end} > diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst > index 3bd7757..c6e45e2 100644 > --- a/doc/guides/rel_notes/release_21_05.rst > +++ b/doc/guides/rel_notes/release_21_05.rst > @@ -251,6 +251,12 @@ ABI Changes > function was already marked as internal in the API documentation for it, > and was not for use by external applications. > > +* Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure > + to provide indicated rxq queue state. > + > +* Added new field ``queue_state`` to ``rte_eth_txq_info`` structure > + to provide indicated txq queue state. > + > > Known Issues > ------------ > diff --git a/lib/librte_ethdev/ethdev_driver.h b/lib/librte_ethdev/ethdev_driver.h > index 113129d..40e474a 100644 > --- a/lib/librte_ethdev/ethdev_driver.h > +++ b/lib/librte_ethdev/ethdev_driver.h > @@ -952,13 +952,6 @@ struct eth_dev_ops { > }; > > /** > - * RX/TX queue states > - */ > -#define RTE_ETH_QUEUE_STATE_STOPPED 0 > -#define RTE_ETH_QUEUE_STATE_STARTED 1 > -#define RTE_ETH_QUEUE_STATE_HAIRPIN 2 > - > -/** > * @internal > * Check if the selected Rx queue is hairpin queue. > * > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c > index 6b5cfd6..ab188ec 100644 > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > @@ -5042,6 +5042,8 @@ rte_eth_rx_queue_info_get(uint16_t port_id, uint16_t queue_id, > > memset(qinfo, 0, sizeof(*qinfo)); > dev->dev_ops->rxq_info_get(dev, queue_id, qinfo); > + qinfo->queue_state = dev->data->rx_queue_state[queue_id]; > + > return 0; > } > > @@ -5082,6 +5084,7 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id, > > memset(qinfo, 0, sizeof(*qinfo)); > dev->dev_ops->txq_info_get(dev, queue_id, qinfo); > + qinfo->queue_state = dev->data->tx_queue_state[queue_id]; > > return 0; > } > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h > index 3b773b6..a0d01d2 100644 > --- a/lib/librte_ethdev/rte_ethdev.h > +++ b/lib/librte_ethdev/rte_ethdev.h > @@ -1588,6 +1588,13 @@ struct rte_eth_dev_info { > }; > > /** > + * RX/TX queue states > + */ > +#define RTE_ETH_QUEUE_STATE_STOPPED 0 > +#define RTE_ETH_QUEUE_STATE_STARTED 1 > +#define RTE_ETH_QUEUE_STATE_HAIRPIN 2 > + > +/** > * Ethernet device RX queue information structure. > * Used to retrieve information about configured queue. > */ > @@ -1595,6 +1602,7 @@ struct rte_eth_rxq_info { > struct rte_mempool *mp; /**< mempool used by that queue. */ > struct rte_eth_rxconf conf; /**< queue config parameters. */ > uint8_t scattered_rx; /**< scattered packets RX supported. */ > + uint8_t queue_state; /**< one of RTE_ETH_QUEUE_STATE_*. */ > uint16_t nb_desc; /**< configured number of RXDs. */ > uint16_t rx_buf_size; /**< hardware receive buffer size. */ > } __rte_cache_min_aligned; > @@ -1606,6 +1614,7 @@ struct rte_eth_rxq_info { > struct rte_eth_txq_info { > struct rte_eth_txconf conf; /**< queue config parameters. */ > uint16_t nb_desc; /**< configured number of TXDs. */ > + uint8_t queue_state; /**< one of RTE_ETH_QUEUE_STATE_*. */ > } __rte_cache_min_aligned; > > /* Generic Burst mode flag definition, values can be ORed. */ > -- Acked-by: Konstantin Ananyev <konstantin.ananyev(a)intel.com> > 2.7.4

1 0

Re: [PATCH v2] iommu/iova: put free_iova_mem() outside of spinlock iova_rbtree_lock
by John Garry 16 Apr '21

16 Apr '21

On 16/04/2021 04:30, chenxiang (M) wrote: >> >> you need to make this: >> if (iova) >> free_iova_mem(iova); >> >> as free_iova_mem(iova) dereferences iova: >> >> if (iova->pfn_lo != IOVA_ANCHOR) >> kmem_cache_free(iova_cache, iova) >> >> So if iova were NULL, we crash. >> >> Or you can make free_iova_mem() NULL safe. > > Right, it has the issue. What about changing it as below? > > @@ -472,10 +472,13 @@ free_iova(struct iova_domain *iovad, unsigned long > pfn) > > spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); > iova = private_find_iova(iovad, pfn); > - if (iova) > - private_free_iova(iovad, iova); > + if (!iova) { > + spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); > + return; > + } > + remove_iova(iovad, iova); > spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); > - > + free_iova_mem(iova); > } > EXPORT_SYMBOL_GPL(free_iova); I don't feel too strongly about how it's done. Please note that kmem_cache_free() is not NULL safe. So the NULL check could be added in free_iova_mem(), but we prob don't want silent free_iova_mem(NULL) calls, so I would stick with changing free_iova(). Thanks, John

2 1

Re: [PATCH V3] ethdev: add queue state when retrieve queue information
by Ferruh Yigit 16 Apr '21

16 Apr '21

On 4/15/2021 3:40 AM, Lijun Ou wrote: > Currently, upper-layer application could get queue state only > through pointers such as dev->data->tx_queue_state[queue_id], > this is not the recommended way to access it. So this patch > add get queue state when call rte_eth_rx_queue_info_get and > rte_eth_tx_queue_info_get API. > > Note: After add queue_state field, the 'struct rte_eth_rxq_info' size > remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so > it could be ABI compatible. > > Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> > Signed-off-by: Lijun Ou <oulijun(a)huawei.com> Looks good to me, but it is causing an ABI error as we already discussed before as that is false positive. Ray, David, Should we add any exception to libabigail.abignore for this?

3 7

[PATCH net v4 0/2] fix packet stuck problem for lockless qdisc
by Yunsheng Lin 16 Apr '21

16 Apr '21

This patchset fixes the packet stuck problem mentioned in [1]. Patch 1: Add STATE_MISSED flag to fix packet stuck problem. Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED flag is added in patch 1. V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED and add patch 2. [1]. https://lkml.org/lkml/2019/10/9/42 Yunsheng Lin (2): net: sched: fix packet stuck problem for lockless qdisc net: sched: fix endless tx action reschedule during deactivation include/net/pkt_sched.h | 7 +------ include/net/sch_generic.h | 37 ++++++++++++++++++++++++++++++++++++- net/core/dev.c | 26 ++++++++++++++++++++++---- net/sched/sch_generic.c | 16 +++++++++++++++- 4 files changed, 74 insertions(+), 12 deletions(-) -- 2.7.4

1 0

[PATCH RESEND net-next 0/2] net: hns3: updates for -next
by Huazhong Tan 16 Apr '21

16 Apr '21

This series adds support for pushing link status to VFs for the HNS3 ethernet driver. Guangbin Huang (2): net: hns3: PF add support for pushing link status to VFs net: hns3: VF not request link status when PF support push link status feature drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h | 3 ++ .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 35 +++++++++++++++++++++- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 1 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 12 ++++---- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 8 +++-- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 1 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 6 ++++ 7 files changed, 55 insertions(+), 11 deletions(-) -- 2.7.4

2 3

[RFC PATCH 0/3] vfio/hisilicon: add acc live migration driver
by Longfang Liu 16 Apr '21

16 Apr '21

The live migration solution relies on the vfio_device_migration_info protocol. The structure vfio_device_migration_info is placed at the 0th offset of the VFIO_REGION_SUBTYPE_MIGRATION region to get and set VFIO device related migration information. Field accesses from this structure are only supported at their native width and alignment. Otherwise, the result is undefined and vendor drivers should return an error. (1).The driver framework is based on vfio_pci_register_dev_region() of vfio-pci, and then a new live migration region is added, and the live migration is realized through the ops of this region. (2).In order to ensure the compatibility of the devices before and after the migration, the device compatibility information check will be performed in the Pre-copy stage. If the check fails, an error will be returned and the source VM will exit the migration function. (3).After the compatibility check is passed, it will enter the Stop-and-copy stage. At this time, all the live migration data will be copied, and then saved to the VF device of the destination, and then the VF device of the destination will be started and the VM of the source will be exited. Longfang Liu (3): vfio/hisilicon: add acc live migration driver vfio/hisilicon: register the driver to vfio vfio/hisilicom: add debugfs for driver drivers/vfio/pci/Kconfig | 8 + drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/hisilicon/acc_vf_migration.c | 1337 +++++++++++++++++++++++++ drivers/vfio/pci/hisilicon/acc_vf_migration.h | 170 ++++ drivers/vfio/pci/vfio_pci.c | 11 + drivers/vfio/pci/vfio_pci_private.h | 9 + 6 files changed, 1536 insertions(+) create mode 100644 drivers/vfio/pci/hisilicon/acc_vf_migration.c create mode 100644 drivers/vfio/pci/hisilicon/acc_vf_migration.h -- 2.8.1

3 5

[PATCH v2] iommu/iova: put free_iova_mem() outside of spinlock iova_rbtree_lock
by chenxiang 15 Apr '21

15 Apr '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> It is not necessary to put free_iova_mem() inside of spinlock/unlock iova_rbtree_lock which only leads to more completion for the spinlock. It has a small promote on the performance after the change. And also rename private_free_iova() as remove_iova() because the function will not free iova after that change. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- drivers/iommu/iova.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c index b7ecd5b..c10af23 100644 --- a/drivers/iommu/iova.c +++ b/drivers/iommu/iova.c @@ -412,12 +412,11 @@ private_find_iova(struct iova_domain *iovad, unsigned long pfn) return NULL; } -static void private_free_iova(struct iova_domain *iovad, struct iova *iova) +static void remove_iova(struct iova_domain *iovad, struct iova *iova) { assert_spin_locked(&iovad->iova_rbtree_lock); __cached_rbnode_delete_update(iovad, iova); rb_erase(&iova->node, &iovad->rbroot); - free_iova_mem(iova); } /** @@ -452,8 +451,9 @@ __free_iova(struct iova_domain *iovad, struct iova *iova) unsigned long flags; spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); - private_free_iova(iovad, iova); + remove_iova(iovad, iova); spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); + free_iova_mem(iova); } EXPORT_SYMBOL_GPL(__free_iova); @@ -473,9 +473,9 @@ free_iova(struct iova_domain *iovad, unsigned long pfn) spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); iova = private_find_iova(iovad, pfn); if (iova) - private_free_iova(iovad, iova); + remove_iova(iovad, iova); spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); - + free_iova_mem(iova); } EXPORT_SYMBOL_GPL(free_iova); @@ -825,7 +825,8 @@ iova_magazine_free_pfns(struct iova_magazine *mag, struct iova_domain *iovad) if (WARN_ON(!iova)) continue; - private_free_iova(iovad, iova); + remove_iova(iovad, iova); + free_iova_mem(iova); } spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); -- 2.8.1

2 1

FW: Patch "ice: Re-organizes reqstd/avail {R,T}XQ check/code for efficiency+readability" has been added to net-queue tree
by Salil Mehta 15 Apr '21

15 Apr '21

FYI. > From: anthony.l.nguyen(a)intel.com [mailto:anthony.l.nguyen@intel.com] > Sent: Wednesday, April 14, 2021 10:28 PM > To: Salil Mehta <salil.mehta(a)huawei.com> > Subject: Patch "ice: Re-organizes reqstd/avail {R,T}XQ check/code for > efficiency+readability" has been added to net-queue tree > > This is a note to let you know that I applied the following patch to > the dev-queue branch on the net-queue tree. > > http://patchwork.ozlabs.org/patch/1465962/ > > From 2c58268dac5bd0dbfe46614febd22b757e29582c Mon Sep 17 00:00:00 2001 > From: Salil Mehta <salil.mehta(a)huawei.com> > Date: Wed, 14 Apr 2021 12:01:49 -0700 > Subject: [PATCH] ice: Re-organizes reqstd/avail {R,T}XQ check/code for > efficiency+readability > > If user has explicitly requested the number of {R,T}XQs, then it is > unnecessary to get the count of already available {R,T}XQs from the > PF avail_{r,t}xqs bitmap. This value will get overridden by user specified > value in any case. > > This patch does minor re-organization of the code for improving the flow > and readabiltiy. This scope of improvement was found during the review of > the ICE driver code. > > FYI, I could not test this change due to unavailability of the hardware. > It would be helpful if somebody can test this patch and provide Tested-by > Tag. Many thanks! > > Fixes: 87324e747fde ("ice: Implement ethtool ops for channels") > Cc: intel-wired-lan(a)lists.osuosl.org > Cc: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> > Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> > --- > > checkpatch.pl reports: > > total: 0 errors, 0 warnings, 0 checks, 32 lines checked > > .apply/V2-net-ice-Re-organizes-reqstd-avail-R-T-XQ-check-code-for-efficienc > y-readability.patch has no obvious style problems and is ready for submission.

1 0

[PATCH net-next 0/2] net: hns3: updates for -next
by Huazhong Tan 15 Apr '21

15 Apr '21

This series adds support for pushing link status to VFs for the HNS3 ethernet driver. Guangbin Huang (2): net: hns3: PF add support for pushing link status to VFs net: hns3: VF not request link status when PF support push link status feature drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h | 3 ++ .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 35 +++++++++++++++++++++- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 1 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 12 ++++---- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 8 +++-- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 1 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 6 ++++ 7 files changed, 55 insertions(+), 11 deletions(-) -- 2.7.4

2 8

linuxarm@openeuler.org You have [9] qurantined messages in your quarantine portal
by openeuler.org 15 Apr '21

15 Apr '21

1 0

Re: [PATCH] iommu/iova: put free_iova_mem() outside of spinlock iova_rbtree_lock
by Robin Murphy 14 Apr '21

14 Apr '21

On 2021-04-14 07:38, chenxiang wrote: > From: Xiang Chen <chenxiang66(a)hisilicon.com> > > It is not necessary to put free_iova_mem() inside of spinlock/unlock > iova_rbtree_lock which only leads to more completion for the spinlock. > It has a small promote on the performance after the change. This seems not entirely unreasonable, but private_free_iova() really needs to be renamed (maybe something like remove_iova()?) if it's no longer actually freeing anything - otherwise it's just unnecessarily misleading. Robin. > Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> > --- > drivers/iommu/iova.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c > index c669526f..292ed4a 100644 > --- a/drivers/iommu/iova.c > +++ b/drivers/iommu/iova.c > @@ -339,7 +339,6 @@ static void private_free_iova(struct iova_domain *iovad, struct iova *iova) > assert_spin_locked(&iovad->iova_rbtree_lock); > __cached_rbnode_delete_update(iovad, iova); > rb_erase(&iova->node, &iovad->rbroot); > - free_iova_mem(iova); > } > > /** > @@ -376,6 +375,7 @@ __free_iova(struct iova_domain *iovad, struct iova *iova) > spin_lock_irqsave(&iovad->iova_rbtree_lock, flags); > private_free_iova(iovad, iova); > spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); > + free_iova_mem(iova); > } > EXPORT_SYMBOL_GPL(__free_iova); > > @@ -397,7 +397,7 @@ free_iova(struct iova_domain *iovad, unsigned long pfn) > if (iova) > private_free_iova(iovad, iova); > spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); > - > + free_iova_mem(iova); > } > EXPORT_SYMBOL_GPL(free_iova); > > @@ -746,6 +746,7 @@ iova_magazine_free_pfns(struct iova_magazine *mag, struct iova_domain *iovad) > continue; > > private_free_iova(iovad, iova); > + free_iova_mem(iova); > } > > spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags); >

1 0

[PATCH] ethdev: add queue state when retrieve queue information
by Lijun Ou 14 Apr '21

14 Apr '21

Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API. Note: The hairpin queue is not supported with above rte_eth_*x_queue_info_get, so the queue state could be RTE_ETH_QUEUE_STATE_STARTED or RTE_ETH_QUEUE_STATE_STOPPED. Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible. Signed-off-by: Chengwen Feng <fengchengwen(a)huawei.com> Signed-off-by: Lijun Ou <oulijun(a)huawei.com> --- doc/guides/rel_notes/release_21_05.rst | 6 ++++++ lib/librte_ethdev/rte_ethdev.c | 3 +++ lib/librte_ethdev/rte_ethdev.h | 4 ++++ 3 files changed, 13 insertions(+) diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index 43063e3..165b5f7 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -156,6 +156,12 @@ ABI Changes * No ABI change that would break compatibility with 20.11. +* Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure + to provide indicated rxq queue state. + +* Added new field ``queue_state`` to ``rte_eth_txq_info`` structure + to provide indicated txq queue state. + Known Issues ------------ diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c index 3059aa5..fbd10b2 100644 --- a/lib/librte_ethdev/rte_ethdev.c +++ b/lib/librte_ethdev/rte_ethdev.c @@ -5042,6 +5042,8 @@ rte_eth_rx_queue_info_get(uint16_t port_id, uint16_t queue_id, memset(qinfo, 0, sizeof(*qinfo)); dev->dev_ops->rxq_info_get(dev, queue_id, qinfo); + qinfo->queue_state = dev->data->rx_queue_state[queue_id]; + return 0; } @@ -5082,6 +5084,7 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id, memset(qinfo, 0, sizeof(*qinfo)); dev->dev_ops->txq_info_get(dev, queue_id, qinfo); + qinfo->queue_state = dev->data->tx_queue_state[queue_id]; return 0; } diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h index efda313..3b83c5a 100644 --- a/lib/librte_ethdev/rte_ethdev.h +++ b/lib/librte_ethdev/rte_ethdev.h @@ -1591,6 +1591,8 @@ struct rte_eth_rxq_info { uint8_t scattered_rx; /**< scattered packets RX supported. */ uint16_t nb_desc; /**< configured number of RXDs. */ uint16_t rx_buf_size; /**< hardware receive buffer size. */ + /**< Queues state: STARTED(1) / STOPPED(0). */ + uint8_t queue_state; } __rte_cache_min_aligned; /** @@ -1600,6 +1602,8 @@ struct rte_eth_rxq_info { struct rte_eth_txq_info { struct rte_eth_txconf conf; /**< queue config parameters. */ uint16_t nb_desc; /**< configured number of TXDs. */ + /**< Queues state: STARTED(1) / STOPPED(0). */ + uint8_t queue_state; } __rte_cache_min_aligned; /* Generic Burst mode flag definition, values can be ORed. */ -- 2.7.4

6 18

Re: [PATCH RFC net] net: hns3: fixes+refactors the broken set channel fallback logic
by Salil Mehta 14 Apr '21

14 Apr '21

> From: lipeng (Y) > Sent: Wednesday, April 14, 2021 2:59 AM > > > 在 2021/4/13 21:55, Salil Mehta 写道: > >> From: lipeng (Y) > >> Sent: Tuesday, April 13, 2021 1:38 PM > >> > >> > >> 在 2021/4/13 19:17, Salil Mehta 写道: > >>>> From: lipeng (Y) > >>>> Sent: Tuesday, April 13, 2021 10:30 AM > >>>> To: Salil Mehta <salil.mehta(a)huawei.com>; Linuxarm <linuxarm(a)huawei.com>; > >>>> linuxarm(a)openeuler.org > >>>> Cc: Zhuangyuzeng (Yisen) <yisen.zhuang(a)huawei.com>; huangdaode > >>>> <huangdaode(a)huawei.com>; linyunsheng <linyunsheng(a)huawei.com>; shenjian > (K) > >>>> <shenjian15(a)huawei.com>; moyufeng <moyufeng(a)huawei.com>; zhangjiaran > >>>> <zhangjiaran(a)huawei.com>; huangguangbin (A) <huangguangbin2(a)huawei.com>; > >>>> Jonathan Cameron <jonathan.cameron(a)huawei.com> > >>>> Subject: Re: [PATCH RFC net] net: hns3: fixes+refactors the broken set > channel > >>>> fallback logic > >>>> > >>>> > >>>> 在 2021/4/13 17:12, Salil Mehta 写道: > >>>>> The fallback logic of the set channels when set_channel() fails to configure > >>>>> TX Sched/RSS H/W configuration or for the code which brings down/restores > >>>>> client before/therafter is not handled properly. > >>>>> > >>>>> This patch fixes and refactors that code to improve the readibility. > >>>>> > >>>>> [INTERNAL ONLY] > >>>>> Fixes: <Tag TODO> ("Comment TODO") > >>>>> Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> > >>>>> --- > >>>>> .../net/ethernet/hisilicon/hns3/hns3_enet.c | 72 > +++++++++++-------- > >>>>> 1 file changed, 43 insertions(+), 29 deletions(-) > >>>>> > >>>>> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > >>>> b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > >>>>> index bf4302a5cf95..41d8bdb34f6e 100644 > >>>>> --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > >>>>> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c > >>>>> @@ -4692,23 +4692,56 @@ static int hns3_reset_notify(struct hnae3_handle > >>>> *handle, > >>>>> static int hns3_change_channels(struct hnae3_handle *handle, u32 > >>>> new_tqp_num, > >>>>> bool rxfh_configured) > >>>>> { > >>>>> - int ret; > >>>>> + const struct hnae3_ae_ops *ops = handle->ae_algo->ops; > >>>>> + u32 org_tqp_num = handle->kinfo.num_tqps; > >>>>> + struct device *dev = &handle->pdev->dev; > >>>>> + u32 req_tqp_num = new_tqp_num; > >>>>> + bool revert_old_config = false; > >>>>> + int ret, retval = 0; > >>>>> + > >>>>> + /* bring down the client */ > >>>>> + ret = hns3_reset_notify(handle, HNAE3_DOWN_CLIENT); > >>>>> + if (ret) > >>>>> + return ret; > >>>>> > >>>>> - ret = handle->ae_algo->ops->set_channels(handle, new_tqp_num, > >>>>> - rxfh_configured); > >>>>> - if (ret) { > >>>>> - dev_err(&handle->pdev->dev, > >>>>> - "Change tqp num(%u) fail.\n", new_tqp_num); > >>>>> + ret = hns3_reset_notify(handle, HNAE3_UNINIT_CLIENT); > >>>>> + if (ret) > >>>>> return ret; > >>>>> + > >>>>> +revert_old_tpqs_config: > >>>>> + /* update the traffic sched and RSS config in the H/W as per new TPQ > num > >>>> */ > >>>>> + ret = ops->set_channels(handle, req_tqp_num, rxfh_configured); > >>>>> + if (ret) { > >>>>> + dev_err(dev, "failed(=%d) to update TX sched/RSS h/w cfg for %s > >> TPQs\n", > >>>>> + ret, revert_old_config?"old":"new"); > >>>>> + > >>>>> + /* try reverting back h/w config with old TPQ num */ > >>>>> + if (!revert_old_config) { > >>>>> + dev_warn(dev, > >>>>> + "will try to revert TX sched/RSS h/w cfg with old TPQs\n"); > >>>>> + req_tqp_num = org_tqp_num; > >>>>> + revert_old_config = true; > >>>>> + retval = ret; > >>>>> + > >>>>> + goto revert_old_tpqs_config; > >>>>> + } > >>>>> + > >>>>> + /* bad, we could not revert to h/w config with old TQP number */ > >>>>> + goto err_set_chan_fail; > >>>> why you changelike this ? > >>>> > >>>> > >>>> when setting fail, the port should work OK just like setting before. > >>> The port can get into problematic state if the client remains in un-initialized > >>> state after errors are encountered during the process of setting the channels > >>> for new number of TPQs. Port cannot be said to be in sane state. > >>> > >>> Conditions(after desperate attempt to revert to old TPQ config fails): > >>> 1. half un-initialized state of the client or > >>> 2. client un-initialized but not re-initialized or > >>> 3. client re-initialization fails later > >>> > >>> > >>> This condition can only be recovered when you reset or re-load the driver. > >>> > >>> > >> do you have any test case for it ? > > > > We need to simulate the TX Sched/RSS hardware config failure at firmware/IMP. > > For the integration Testing, we can always create one but for system testing > > we need ways in the firmware to be able to simulate these failures. Some > > debugging feature is required in the firmware. Maybe somebody can take this > > task and introduce this feature in the IMP firmware code if it does not exists > > already? I would suggest to expose all these controls using 'devlink' interface > > to the user which can be used by sys test team as well. > > > > > >> when user change channel larger by ethtool command , and the > >> memory not enough, it will fail. > >> > >> we should recovered too. > > All of these should get conveyed by the hnae3 layer when you do set channels > or when > > we do client re-initialization(init+up) > > > This patch will make some test case fail, it is OK before this change. Can you please list down the test case which is failing or will fail?

1 0

[RFC PATCH v3 0/2] scheduler: expose the topology of clusters and add cluster scheduler
by Barry Song 14 Apr '21

14 Apr '21

ARM64 server chip Kunpeng 920 has 6 clusters in each NUMA node, and each cluster has 4 cpus. All clusters share L3 cache data while each cluster has local L3 tag. On the other hand, each cluster will share some internal system bus. This means cache is much more affine inside one cluster than across clusters. +-----------------------------------+ +---------+ | +------+ +------+ +---------------------------+ | | | CPU0 | | cpu1 | | +-----------+ | | | +------+ +------+ | | | | | | +----+ L3 | | | | +------+ +------+ cluster | | tag | | | | | CPU2 | | CPU3 | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | | | L3 | | | | +------+ +------+ +----+ tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | L3 | | data | +-----------------------------------+ | | | +------+ +------+ | +-----------+ | | | | | | | | | | | | | +------+ +------+ +----+ L3 | | | | | | tag | | | | +------+ +------+ | | | | | | | | | | ++ +-----------+ | | | +------+ +------+ |---------------------------+ | +-----------------------------------| | | +-----------------------------------| | | | +------+ +------+ +---------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | +----+ L3 | | | | +------+ +------+ | | tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | Through the following small program, you can see the performance impact of running it in one cluster and across two clusters: struct foo { int x; int y; } f; void *thread1_fun(void *param) { int s = 0; for (int i = 0; i < 0xfffffff; i++) s += f.x; } void *thread2_fun(void *param) { int s = 0; for (int i = 0; i < 0xfffffff; i++) f.y++; } int main(int argc, char **argv) { pthread_t tid1, tid2; pthread_create(&tid1, NULL, thread1_fun, NULL); pthread_create(&tid2, NULL, thread2_fun, NULL); pthread_join(tid1, NULL); pthread_join(tid2, NULL); } While running this program in one cluster, it takes: $ time taskset -c 0,1 ./a.out real 0m0.832s user 0m1.649s sys 0m0.004s As a contrast, it takes much more time if we run the same program in two clusters: $ time taskset -c 0,4 ./a.out real 0m1.133s user 0m1.960s sys 0m0.000s 0.832/1.133 = 73%, it is a huge difference. Also, hackbench running on 4 cpus in single one cluster and 4 cpus in different clusters also shows a large contrast: * inside a cluster: root@ubuntu:~# taskset -c 0,1,2,3 hackbench -p -T -l 20000 -g 1 Running in threaded mode with 1 groups using 40 file descriptors each (== 40 tasks) Each sender will pass 20000 messages of 100 bytes Time: 4.285 * across clusters: root@ubuntu:~# taskset -c 0,4,8,12 hackbench -p -T -l 20000 -g 1 Running in threaded mode with 1 groups using 40 file descriptors each (== 40 tasks) Each sender will pass 20000 messages of 100 bytes Time: 5.524 The score is 4.285 vs 5.524, shorter time means better performance. All these testing implies that we should let the Linux scheduler use this topology to make better load balancing and WAKE_AFFINE decisions. However, the current scheduler totally has no idea of clusters. This patchset exposed the cluster topology first, then added the sched domain for cluster. While it is named as "cluster", architectures and machines can define the exact meaning of cluster as long as they have some resources sharing under llc and they can leverage the affinity of this resource to achive better scheduling performance. -v3: - rebased againest 5.11-rc2 - with respect to the comments of Valentin Schneider, Peter Zijlstra, Vincent Guittot and Mel Gorman etc. * moved the scheduler changes from arm64 to the common place for all architectures. * added SD_SHARE_CLS_RESOURCES sd_flags specifying the sched_domain where select_idle_cpu() should begin to scan from * removed redundant select_idle_cluster() function since all code is in select_idle_cpu() now. it also avoided scanning cluster cpus twice in v2 code; * redo the hackbench in one numa after the above changes Valentin suggested that select_idle_cpu() could begin to scan from domain with SD_SHARE_PKG_RESOURCES. Changing like this might be too aggressive and limit the spreading of tasks. Thus, this patch lets the architectures and machines to decide where to start by adding a new SD_SHARE_CLS_RESOURCES. Barry Song (1): scheduler: add scheduler level for clusters Jonathan Cameron (1): topology: Represent clusters of CPUs within a die. Documentation/admin-guide/cputopology.rst | 26 +++++++++++--- arch/arm64/Kconfig | 7 ++++ arch/arm64/kernel/topology.c | 2 ++ drivers/acpi/pptt.c | 60 +++++++++++++++++++++++++++++++ drivers/base/arch_topology.c | 14 ++++++++ drivers/base/topology.c | 10 ++++++ include/linux/acpi.h | 5 +++ include/linux/arch_topology.h | 5 +++ include/linux/sched/sd_flags.h | 9 +++++ include/linux/sched/topology.h | 7 ++++ include/linux/topology.h | 13 +++++++ kernel/sched/fair.c | 27 ++++++++++---- kernel/sched/topology.c | 6 ++++ 13 files changed, 181 insertions(+), 10 deletions(-) -- 2.7.4

7 19

[PATCH RFC net] net: hns3: fixes+refactors the broken set channel fallback logic
by Salil Mehta 13 Apr '21

13 Apr '21

The fallback logic of the set channels when set_channel() fails to configure TX Sched/RSS H/W configuration or for the code which brings down/restores client before/therafter is not handled properly. This patch fixes and refactors that code to improve the readibility. [INTERNAL ONLY] Fixes: <Tag TODO> ("Comment TODO") Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> --- .../net/ethernet/hisilicon/hns3/hns3_enet.c | 72 +++++++++++-------- 1 file changed, 43 insertions(+), 29 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index bf4302a5cf95..41d8bdb34f6e 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -4692,23 +4692,56 @@ static int hns3_reset_notify(struct hnae3_handle *handle, static int hns3_change_channels(struct hnae3_handle *handle, u32 new_tqp_num, bool rxfh_configured) { - int ret; + const struct hnae3_ae_ops *ops = handle->ae_algo->ops; + u32 org_tqp_num = handle->kinfo.num_tqps; + struct device *dev = &handle->pdev->dev; + u32 req_tqp_num = new_tqp_num; + bool revert_old_config = false; + int ret, retval = 0; + + /* bring down the client */ + ret = hns3_reset_notify(handle, HNAE3_DOWN_CLIENT); + if (ret) + return ret; - ret = handle->ae_algo->ops->set_channels(handle, new_tqp_num, - rxfh_configured); - if (ret) { - dev_err(&handle->pdev->dev, - "Change tqp num(%u) fail.\n", new_tqp_num); + ret = hns3_reset_notify(handle, HNAE3_UNINIT_CLIENT); + if (ret) return ret; + +revert_old_tpqs_config: + /* update the traffic sched and RSS config in the H/W as per new TPQ num */ + ret = ops->set_channels(handle, req_tqp_num, rxfh_configured); + if (ret) { + dev_err(dev, "failed(=%d) to update TX sched/RSS h/w cfg for %s TPQs\n", + ret, revert_old_config?"old":"new"); + + /* try reverting back h/w config with old TPQ num */ + if (!revert_old_config) { + dev_warn(dev, + "will try to revert TX sched/RSS h/w cfg with old TPQs\n"); + req_tqp_num = org_tqp_num; + revert_old_config = true; + retval = ret; + + goto revert_old_tpqs_config; + } + + /* bad, we could not revert to h/w config with old TQP number */ + goto err_set_chan_fail; } + /* restore the client */ ret = hns3_reset_notify(handle, HNAE3_INIT_CLIENT); if (ret) - return ret; + goto err_set_chan_fail; ret = hns3_reset_notify(handle, HNAE3_UP_CLIENT); if (ret) - hns3_reset_notify(handle, HNAE3_UNINIT_CLIENT); + goto err_set_chan_fail; + + return retval; +err_set_chan_fail: + dev_warn(dev, "device could be in insane state. Reset rqd. or reload the driver!\n"); return ret; } @@ -4720,7 +4753,6 @@ int hns3_set_channels(struct net_device *netdev, struct hnae3_knic_private_info *kinfo = &h->kinfo; bool rxfh_configured = netif_is_rxfh_configured(netdev); u32 new_tqp_num = ch->combined_count; - u16 org_tqp_num; int ret; if (hns3_nic_resetting(netdev)) @@ -4750,28 +4782,10 @@ int hns3_set_channels(struct net_device *netdev, "set channels: tqp_num=%u, rxfh=%d\n", new_tqp_num, rxfh_configured); - ret = hns3_reset_notify(h, HNAE3_DOWN_CLIENT); - if (ret) - return ret; - - ret = hns3_reset_notify(h, HNAE3_UNINIT_CLIENT); - if (ret) - return ret; - - org_tqp_num = h->kinfo.num_tqps; ret = hns3_change_channels(h, new_tqp_num, rxfh_configured); if (ret) { - int ret1; - - netdev_warn(netdev, - "Change channels fail, revert to old value\n"); - ret1 = hns3_change_channels(h, org_tqp_num, rxfh_configured); - if (ret1) { - netdev_err(netdev, - "revert to old channel fail\n"); - return ret1; - } - + netdev_err(netdev, "fail(=%d) to set number of channels to %u\n", ret, + new_tqp_num); return ret; } -- 2.17.1

2 4

[PATCH net] ice: Re-organizes reqstd/avail {R,T}XQ check/code for efficiency+readability
by Salil Mehta 13 Apr '21

13 Apr '21

If user has explicitly requested the number of {R,T}XQs, then it is unnecessary to get the count of already available {R,T}XQs from the PF avail_{r,t}xqs bitmap. This value will get overriden by user specified value in any case. This patch does minor re-organization of the code for improving the flow and readabiltiy. This scope of improvement was found during the review of the ICE driver code. FYI, I could not test this change due to unavailability of the hardware. It would helpful if somebody can test this and provide Tested-by Tag. Many thanks! Fixes: 11b7551e096d ("ice: Implement ethtool ops for channels") Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_lib.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c index d13c7fc8fb0a..161e8dfe548c 100644 --- a/drivers/net/ethernet/intel/ice/ice_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_lib.c @@ -161,12 +161,13 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16 vf_id) switch (vsi->type) { case ICE_VSI_PF: - vsi->alloc_txq = min3(pf->num_lan_msix, - ice_get_avail_txq_count(pf), - (u16)num_online_cpus()); if (vsi->req_txq) { vsi->alloc_txq = vsi->req_txq; vsi->num_txq = vsi->req_txq; + } else { + vsi->alloc_txq = min3(pf->num_lan_msix, + ice_get_avail_txq_count(pf), + (u16)num_online_cpus()); } pf->num_lan_tx = vsi->alloc_txq; @@ -175,12 +176,13 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16 vf_id) if (!test_bit(ICE_FLAG_RSS_ENA, pf->flags)) { vsi->alloc_rxq = 1; } else { - vsi->alloc_rxq = min3(pf->num_lan_msix, - ice_get_avail_rxq_count(pf), - (u16)num_online_cpus()); if (vsi->req_rxq) { vsi->alloc_rxq = vsi->req_rxq; vsi->num_rxq = vsi->req_rxq; + } else { + vsi->alloc_rxq = min3(pf->num_lan_msix, + ice_get_avail_rxq_count(pf), + (u16)num_online_cpus()); } } -- 2.17.1

2 2

[PATCH v1 0/2] scsi: libsas: few clean up patches
by Luo Jiaxing 13 Apr '21

13 Apr '21

Two types of errors are detected by the checkpatch. 1. Alignment between switches and cases 2. Improper use of some spaces Here are the clean up patches. Luo Jiaxing (2): scsi: libsas: make switch and case at the same indent in sas_to_ata_err() scsi: libsas: clean up for white spaces drivers/scsi/libsas/sas_ata.c | 74 ++++++++++++++++++-------------------- drivers/scsi/libsas/sas_discover.c | 2 +- drivers/scsi/libsas/sas_expander.c | 15 ++++---- 3 files changed, 43 insertions(+), 48 deletions(-) -- 2.7.4

3 4

[RFC PATCH v3 0/3] vfio/hisilicon: add acc live migration driver
by Longfang Liu 13 Apr '21

13 Apr '21

The live migration solution relies on the vfio_device_migration_info protocol. The structure vfio_device_migration_info is placed at the 0th offset of the VFIO_REGION_SUBTYPE_MIGRATION region to get and set VFIO device related migration information. Field accesses from this structure are only supported at their native width and alignment. Otherwise, the result is undefined and vendor drivers should return an error. (1).The driver framework is based on vfio_pci_register_dev_region() of vfio-pci, and then a new live migration region is added, and the live migration is realized through the ops of this region. (2).In order to ensure the compatibility of the devices before and after the migration, the device compatibility information check will be performed in the Pre-copy stage. If the check fails, an error will be returned and the source VM will exit the migration function. (3).After the compatibility check is passed, it will enter the Stop-and-copy stage. At this time, all the live migration data will be copied, and then saved to the VF device of the destination, and then the VF device of the destination will be started and the VM of the source will be exited. Longfang Liu (3): vfio/hisilicon: add acc live migration driver vfio/hisilicon: register the driver to vfio vfio/hisilicom: add debugfs for driver drivers/vfio/pci/Kconfig | 9 + drivers/vfio/pci/Makefile | 3 +- drivers/vfio/pci/hisilicon/acc_vf_migration.c | 1357 +++++++++++++++++++++++++ drivers/vfio/pci/hisilicon/acc_vf_migration.h | 172 ++++ drivers/vfio/pci/vfio_pci.c | 11 + drivers/vfio/pci/vfio_pci_private.h | 10 + 6 files changed, 1561 insertions(+), 1 deletion(-) create mode 100644 drivers/vfio/pci/hisilicon/acc_vf_migration.c create mode 100644 drivers/vfio/pci/hisilicon/acc_vf_migration.h -- 2.8.1

2 4

[RFC PATCH v3 0/3] vfio/hisilicon: add acc live migration driver
by Longfang Liu 13 Apr '21

13 Apr '21

The live migration solution relies on the vfio_device_migration_info protocol. The structure vfio_device_migration_info is placed at the 0th offset of the VFIO_REGION_SUBTYPE_MIGRATION region to get and set VFIO device related migration information. Field accesses from this structure are only supported at their native width and alignment. Otherwise, the result is undefined and vendor drivers should return an error. (1).The driver framework is based on vfio_pci_register_dev_region() of vfio-pci, and then a new live migration region is added, and the live migration is realized through the ops of this region. (2).In order to ensure the compatibility of the devices before and after the migration, the device compatibility information check will be performed in the Pre-copy stage. If the check fails, an error will be returned and the source VM will exit the migration function. (3).After the compatibility check is passed, it will enter the Stop-and-copy stage. At this time, all the live migration data will be copied, and then saved to the VF device of the destination, and then the VF device of the destination will be started and the VM of the source will be exited. Longfang Liu (3): vfio/hisilicon: add acc live migration driver vfio/hisilicon: register the driver to vfio vfio/hisilicom: add debugfs for driver drivers/vfio/pci/Kconfig | 9 + drivers/vfio/pci/Makefile | 3 +- drivers/vfio/pci/hisilicon/acc_vf_migration.c | 1357 +++++++++++++++++++++++++ drivers/vfio/pci/hisilicon/acc_vf_migration.h | 172 ++++ drivers/vfio/pci/vfio_pci.c | 11 + drivers/vfio/pci/vfio_pci_private.h | 10 + 6 files changed, 1561 insertions(+), 1 deletion(-) create mode 100644 drivers/vfio/pci/hisilicon/acc_vf_migration.c create mode 100644 drivers/vfio/pci/hisilicon/acc_vf_migration.h -- 2.8.1

2 4

[PATCH 0/3] Fixes for testpmd
by Lijun Ou 12 Apr '21

12 Apr '21

This series add two test bug fixes and a print style. Hongbo Zheng (1): app/testpmd: use of Rx/Tx in testpmd Huisong Li (2): app/testpmd: fix forwarding configuration when DCB test app/testpmd: remove forwarding config from parsing Rx and Tx app/test-pmd/cmdline.c | 106 ++++++++++++++++---------------- app/test-pmd/config.c | 147 +++++++++++++++++++++++++-------------------- app/test-pmd/csumonly.c | 22 +++---- app/test-pmd/icmpecho.c | 2 +- app/test-pmd/ieee1588fwd.c | 18 +++--- app/test-pmd/parameters.c | 50 +++++++-------- app/test-pmd/testpmd.c | 132 ++++++++++++++++++++-------------------- app/test-pmd/testpmd.h | 28 ++++----- app/test-pmd/txonly.c | 2 +- 9 files changed, 263 insertions(+), 244 deletions(-) -- 2.7.4

7 37

[PATCH drivers/iio 0/3] convert sysfs sprintf/snprintf/scnprintf to sysfs_emit
by Tian Tao 12 Apr '21

12 Apr '21

Use the generic sysfs_emit() function to take place of sprintf/snprintf/scnprintf, to avoid buffer overrun. Tian Tao (3): iio:chemical:sps30: Convert sysfs sprintf/snprintf family to sysfs_emit iio: light: Convert sysfs sprintf/snprintf family to sysfs_emit iio: trigger: stm32-timer: Convert sysfs sprintf/snprintf family to sysfs_emit drivers/iio/chemical/sps30.c | 6 +++--- drivers/iio/light/veml6030.c | 2 +- drivers/iio/trigger/stm32-timer-trigger.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) -- 2.7.4

2 4

Re: [PATCH net v3] net: sched: fix packet stuck problem for lockless qdisc
by Yunsheng Lin 12 Apr '21

12 Apr '21

On 2021/4/9 13:31, Juergen Gross wrote: > On 25.03.21 04:13, Yunsheng Lin wrote: >> Lockless qdisc has below concurrent problem: >> cpu0 cpu1 >> . . >> q->enqueue . >> . . >> qdisc_run_begin() . >> . . >> dequeue_skb() . >> . . >> sch_direct_xmit() . >> . . >> . q->enqueue >> . qdisc_run_begin() >> . return and do nothing >> . . >> qdisc_run_end() . >> >> cpu1 enqueue a skb without calling __qdisc_run() because cpu0 >> has not released the lock yet and spin_trylock() return false >> for cpu1 in qdisc_run_begin(), and cpu0 do not see the skb >> enqueued by cpu1 when calling dequeue_skb() because cpu1 may >> enqueue the skb after cpu0 calling dequeue_skb() and before >> cpu0 calling qdisc_run_end(). >> >> Lockless qdisc has below another concurrent problem when >> tx_action is involved: >> >> cpu0(serving tx_action) cpu1 cpu2 >> . . . >> . q->enqueue . >> . qdisc_run_begin() . >> . dequeue_skb() . >> . . q->enqueue >> . . . >> . sch_direct_xmit() . >> . . qdisc_run_begin() >> . . return and do nothing >> . . . >> clear __QDISC_STATE_SCHED . . >> qdisc_run_begin() . . >> return and do nothing . . >> . . . >> . qdisc_run_end() . >> >> This patch fixes the above data race by: >> 1. Get the flag before doing spin_trylock(). >> 2. If the first spin_trylock() return false and the flag is not >> set before the first spin_trylock(), Set the flag and retry >> another spin_trylock() in case other CPU may not see the new >> flag after it releases the lock. >> 3. reschedule if the flags is set after the lock is released >> at the end of qdisc_run_end(). >> >> For tx_action case, the flags is also set when cpu1 is at the >> end if qdisc_run_end(), so tx_action will be rescheduled >> again to dequeue the skb enqueued by cpu2. >> >> Only clear the flag before retrying a dequeuing when dequeuing >> returns NULL in order to reduce the overhead of the above double >> spin_trylock() and __netif_schedule() calling. >> >> The performance impact of this patch, tested using pktgen and >> dummy netdev with pfifo_fast qdisc attached: >> >> threads without+this_patch with+this_patch delta >> 1 2.61Mpps 2.60Mpps -0.3% >> 2 3.97Mpps 3.82Mpps -3.7% >> 4 5.62Mpps 5.59Mpps -0.5% >> 8 2.78Mpps 2.77Mpps -0.3% >> 16 2.22Mpps 2.22Mpps -0.0% >> >> Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking") >> Signed-off-by: Yunsheng Lin <linyunsheng(a)huawei.com> > > I have a setup which is able to reproduce the issue quite reliably: > > In a Xen guest I'm mounting 8 NFS shares and run sysbench fileio on > each of them. The average latency reported by sysbench is well below > 1 msec, but at least once per hour I get latencies in the minute > range. > > With this patch I don't see these high latencies any longer (test > is running for more than 20 hours now). > > So you can add my: > > Tested-by: Juergen Gross <jgross(a)suse.com> Hi, Juergen Thanks for the testing. With the simulated test case suggested by Michal, I still has some potential issue to debug, hopefully will send out new version in this week. Also, is it possible to run your testcase any longer? I think "72 hours" would be enough to testify that it fixes the problem completely:) > > > Juergen

2 1

Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx
by oulijun 10 Apr '21

10 Apr '21

在 2021/4/9 15:08, Li, Xiaoyun 写道: > > >> -----Original Message----- >> From: oulijun <oulijun(a)huawei.com> >> Sent: Friday, April 9, 2021 14:10 >> To: linuxarm(a)openeuler.org; dev <dev(a)dpdk.org>; Li, Xiaoyun >> <xiaoyun.li(a)intel.com> >> Subject: Re: [Linuxarm] Re: [PATCH 2/3] app/testpmd: remove forwarding >> config from parsing Rx and Tx >> >> >> >> 在 2021/4/2 10:33, Li, Xiaoyun 写道: >>> >>> >>>> -----Original Message----- >>>> From: oulijun <oulijun(a)huawei.com> >>>> Sent: Friday, April 2, 2021 09:45 >>>> To: Li, Xiaoyun <xiaoyun.li(a)intel.com>; Yigit, Ferruh >>>> <ferruh.yigit(a)intel.com> >>>> Cc: dev(a)dpdk.org; linuxarm(a)openeuler.org >>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from >>>> parsing Rx and Tx >>>> >>>> >>>> >>>> 在 2021/3/29 9:53, Li, Xiaoyun 写道: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: oulijun <oulijun(a)huawei.com> >>>>>> Sent: Thursday, March 25, 2021 11:04 >>>>>> To: Li, Xiaoyun <xiaoyun.li(a)intel.com>; Yigit, Ferruh >>>>>> <ferruh.yigit(a)intel.com> >>>>>> Cc: dev(a)dpdk.org; linuxarm(a)openeuler.org >>>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from >>>>>> parsing Rx and Tx >>>>>> >>>>>> >>>>>> >>>>>> 在 2021/3/24 9:44, Li, Xiaoyun 写道: >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: oulijun <oulijun(a)huawei.com> >>>>>>>> Sent: Wednesday, March 24, 2021 09:01 >>>>>>>> To: Li, Xiaoyun <xiaoyun.li(a)intel.com>; Yigit, Ferruh >>>>>>>> <ferruh.yigit(a)intel.com> >>>>>>>> Cc: dev(a)dpdk.org; linuxarm(a)openeuler.org >>>>>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config >>>>>>>> from parsing Rx and Tx >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 在 2021/3/23 15:50, Li, Xiaoyun 写道: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lijun Ou <oulijun(a)huawei.com> >>>>>>>>>> Sent: Friday, March 5, 2021 18:22 >>>>>>>>>> To: Yigit, Ferruh <ferruh.yigit(a)intel.com> >>>>>>>>>> Cc: Li, Xiaoyun <xiaoyun.li(a)intel.com>; dev(a)dpdk.org; >>>>>>>>>> linuxarm(a)openeuler.org >>>>>>>>>> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from >>>>>>>>>> parsing Rx and Tx >>>>>>>>>> >>>>>>>>>> From: Huisong Li <lihuisong(a)huawei.com> >>>>>>>>>> >>>>>>>>> >>>>>>>>> The commit message should be more simple and avoids grammar >>>> mistakes. >>>>>>>>> >>>>>>>> All right, I will simply it. >>>>>>>>>> The "fwd_config_setup()" function does release and apply for >>>>>>>>>> memory of forwarding flows, and re-establish these streams when >>>>>>>>>> rxq/txq or rxd/txd is changed. The function is also called by >>>>>>>>>> "start_packet_forwarding()" when user executes "start" cmd. >>>>>>>>>> All changes for rxq/txq or rxd/txd can be updated uniformly >>>>>>>>>> when this command is executed. Therefore, it is a little >>>>>>>>>> redundant in the >>>>>>>> "cmd_config_rx_tx_parsed" >>>>>>>>>> function. >>>>>>>>> >>>>>>>>> It's not redundant. This command may configure number of rxq/txq. >>>>>>>>> So the >>>>>>>> fwd streams map may change. >>>>>>>>> Then it's common to check the fwd streams after this command >>>>>>>>> using "show >>>>>>>> config fwd". >>>>>>>>> If you remove this fwd stream update, users can't get the >>>>>>>>> correct new fwd >>>>>>>> streams until they start the traffic. >>>>>>>>> But they may change a lot of things and want to check if the >>>>>>>>> setting is correct >>>>>>>> before they start the traffic. >>>>>>>>> >>>>>>>> Yes, you are right. It's really unfriendly. >>>>>>>>>> >>>>>>>>>> In addition, the forwarding stream under one TC is configured >>>>>>>>>> based on number of queues allocated to TC. And number of queues >>>>>>>>>> allocated to TC is updated after calling "rte_eth_dev_configure" >>>>>>>>>> again. If the number of queues is reduced after configuring the >>>>>>>>>> DCB, and then, release and apply for stream memory, and >>>>>>>>>> reinitialize the forwarding stream under the DCB mode based on >>>>>>>>>> the old TC >>>>>> information. >>>>>>>>>> As a result, null pointer may be accessed. >>>>>>>>> >>>>>>>>> I think you should add "rte_eth_dev_configure " into >>>>>>>>> dcb_fwd_config_setup() >>>>>>>> before rte_eth_dev_get_dcb_info(). >>>>>>>>> >>>>>>>>> And the commit message should be similar like the following: >>>>>>>>> Segment fault might happen after configuring queue number to >>>>>>>>> less because >>>>>>>> dcb_fwd_config_setup setup dcb based on old dcb info. >>>>>>>>> And dcb info can only update after rte_eth_dev_configure(). >>>>>>>>> So this patch adds rte_eth_dev_configure() before >>>>>>>>> rte_eth_dev_get_dcb_info() >>>>>>>> to get updated dcb info to fix this issue. >>>>>>>>> >>>>>>>> Thank you for your advice. But the above adjustments may still >>>>>>>> not work for some drivers. The mapping between queues and TCs in >>>>>>>> these drivers is updated in the dev_start stage. >>>>>>>> >>>>>>>> I have an idea. We can move fwd_config_setup() to start_port(), >>>>>>>> which is called by main() and after starting ports This not only >>>>>>>> solves the segment fault, but also does not have the problem you >>>>>>>> mentioned above. I >>>>>> test it and it is ok. >>>>>>>> >>>>>>>> What do you think, xiaoyun? >>>>>>> >>>>>>> How can you fix the issue I mentioned? >>>>>>> You still need to start port first to see the updated fwd config. >>>>>> Yes. But it can make sure that users get the correct new fwd >>>>>> streams before executing the 'start' command. >>>>>>> And for those drivers, why does the mapping has to be updated in >>>>>>> dev_start >>>>>> stage? >>>>>>> What does it need? Can't it be moved to dev_configure? >>>>>> The framework does not require that the configuration parameters >>>>>> transferred by the dev_configure API must be updated in the >>>>>> interface of driver. The driver can verify the correctness of >>>>>> these parameters in the interface, and then complete the update in >>>>>> the dev_start stage. It depends on the design and need of the >>>>>> driver. Maybe it's more appropriate to put it in dev_configure, but >>>>>> now we can't ask all these >>>> drivers to modify the operation. >>>>> >>>>> I still think it's driver's responsibility to configure DCB in dev_configure. >>>>> >>>>> Calling fwd_config_setup here is because this command changes queue >>>> number. Users just change queue number so want to check fwd setup. >>>> It's a normal and reasonable behavior. >>>>> Starting port will be called in many situations. I don't think it's >>>>> appropriate to >>>> call fwd_config_setup every time calling port_start. And you can't >>>> expect users know the fwd setup only change after port_start. >>>>> >>>>> These are only my thoughts. If anyone else agrees you, they can give you >> ack. >>>>>>>> >>>> @Ferruh, what do you think? >>>> Currently, both ixgbe and i40e also have this problem. Even if >>>> testpmd can be modified according to Xiaoyun's suggestion, and the >>>> driver is not modified, this problem still exists in some drivers, such as ixgbe >> and hns3. >>> >>> NO. I40e and ixgbe DON'T have the issue. >>> I40e tc mapping is done in dev_configure. >>> ixgbe tc mapping is always fixed due to hw design. It only needs dev_configure >> to get dcb_conf info. No matter you configure dcb or not, the mapping is always >> the same. You can check ixgbe_dev_get_dcb_info(). >>> >>> So for i40e and ixgbe, you only need to add dev_configure in >> dcb_fwd_config_setup(). >>> >> Hi, Xiaoyun, >> >> The fwd_config_setup() is called when the port is in the stop state and start >> state. >> When we run "start" cmd, all port are in the start state. Namely, we need to >> decide whether to call rte_eth_dev_configure() based on the state of all ports >> before rte_eth_dev_get_dcb_info() in dcb_fwd_config_setup(). >> Modify as follows: >> @@ -1834,6 +1834,7 @@ cmd_config_rx_tx_parsed(void *parsed_result, >> return; >> } >> >> + fwd_config_setup(); >> init_port_config(); >> >> cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1); diff --git a/app/test- >> pmd/config.c b/app/test-pmd/config.c index bd6ee8b..5981b50 100644 >> --- a/app/test-pmd/config.c >> +++ b/app/test-pmd/config.c >> @@ -3179,7 +3179,24 @@ dcb_fwd_config_setup(void) >> uint16_t nb_rx_queue, nb_tx_queue; >> uint16_t i, j, k, sm_id = 0; >> uint16_t total_tc_num = 0; >> + struct rte_port *port; >> uint8_t tc = 0; >> + portid_t pid; >> + int ret; >> + >> + if (all_ports_stopped()) { >> + /* re-configure the device after changing queue numbers. */ >> + for (pid = 0; pid < nb_fwd_ports; pid++) { >> + port = &ports[pid]; >> + ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq, >> + &port->dev_conf); >> + if (ret < 0) { >> + printf("Failed to re-configure port %d, >> ret = %d.\n", >> + pid, ret); >> + return; >> + } >> + } >> + } >> >> cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores; >> cur_fwd_config.nb_fwd_ports = nb_fwd_ports; >> >> But there's still no way to get away with the segment fault for ixgbe and i40e. >> 1/ For ixgbe, tc mapping is always fixed after DCB is configured. If the number >> of queues is reduced, segment fault occur. >> Does it mean that the number of queues cannot be modified for ixgbe after >> DCB is configured? >> 2/ For i40e, it appears that the mapping between tc and queue is not updated >> after changing queue numbers. From i40e_vsi_config_tc(), its update seems to >> depend only on tc_map changes. >> >> please check it? > > No. > After users config queue numbers using cmd "port config all rxq 4". It's normal that they may want to check what new fwd config will be like using "show config fwd" > So you should call fwd_config_setup() in cmd_config_rx_tx_parsed(). The ports are in stopped state. > I see. The current modification has rolled back this behavior. dcb_fwd_config_setup() will call rte_eth_dev_get_dcb_info() at first to get the dcb info first. The segment fault happens because rte_eth_dev_get_dcb_info() get the wrong info based on old queue numbers (new queue number is small). > dcb_fwd_config_setup() will call rte_eth_dev_get_dcb_info() at first to get the dcb info first. > The segment fault happens because rte_eth_dev_get_dcb_info() get the wrong info based on old queue numbers (new queue number is small). > Yes! Currently, calling dev_configure at first in dcb_fwd_config_setup() is to update tc and queue mapping because of the change of queue number, so that testpmd can get valid the dcb info by rte_eth_dev_get_dcb_info(). For ixgbe, The fixed mapping means for maximum queue numbers for example 128 queues. Each queue and tc mapping is fixed to fill to hw. Fixed values. It's just you enable which queues or not. You can change queue number as you want. In dev_start stage, tc will actually take effect. get_dcb_info() only needs rx_adv_conf.dcb_rx_conf which info is included in dev_conf. So for ixgbe, you only need to call dev_configure to update the new dcb_rx_conf for get_dcb_info(). > For ixgbe, The fixed mapping means for maximum queue numbers for example 128 queues. Each queue and tc mapping is fixed to fill to hw. Fixed values. It's just you enable which queues or not. > You can change queue number as you want. In dev_start stage, tc will actually take effect. get_dcb_info() only needs rx_adv_conf.dcb_rx_conf which info is included in dev_conf. > So for ixgbe, you only need to call dev_configure to update the new dcb_rx_conf for get_dcb_info(). > > For i40e, dcb_setup is in dev_configure stage. i40e_dev_get_dcb_info() will get the correct info too. > The mapping for i40e is really updated in dev_configure. However, if the tc_map in i40e_vsi_config_tc() does not change, it seems that the mapping will not be updated. Namely, This mapping can not be remodified due to queue count changes. Maybe it is a bug for i40e. I think this suggestion is reasonable. It's just that I think ixgbe and i40e may have the above issues. >>>>>>>> >>>>>>>>>> >>>>>>>>>> Like: >>>>>>>>>> set nbcore 4 >>>>>>>>>> port stop all >>>>>>>>>> port config 0 dcb vt off 4 pfc on port start all port stop all >>>>>>>>>> port config all rxq 8 port config all txq 8 >>>>>>>>>> >>>>>>>>>> At the moment, a segmentation fault occurs. >>>>>>>>>> >>>>>>>>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration >>>>>>>>>> settings") >>>>>>>>>> Cc: stable(a)dpdk.org >>>>>>>>>> >>>>>>>>>> Signed-off-by: Huisong Li <lihuisong(a)huawei.com> >>>>>>>>>> Signed-off-by: Lijun Ou <oulijun(a)huawei.com> >>>>>>>>>> --- >>>>>>>>>> V1->V2: >>>>>>>>>> - use stream instead of flow >>>>>>>>>> --- >>>>>>>>>> app/test-pmd/cmdline.c | 2 -- >>>>>>>>>> 1 file changed, 2 deletions(-) >>>>>>>>>> >>>>>>>>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c >>>>>>>>>> index 4df0c32..e316f5c 100644 >>>>>>>>>> --- a/app/test-pmd/cmdline.c >>>>>>>>>> +++ b/app/test-pmd/cmdline.c >>>>>>>>>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void >>>> *parsed_result, >>>>>>>>>> return; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> - fwd_config_setup(); >>>>>>>>>> - >>>>>>>>>> init_port_config(); >>>>>>>>>> >>>>>>>>>> cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1); >>>>>>>>>> -- >>>>>>>>>> 2.7.4 >>>>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>> . >>>>>>> >>>>> . >>>>> >>> _______________________________________________ >>> Linuxarm mailing list -- linuxarm(a)openeuler.org To unsubscribe send an >>> email to linuxarm-leave(a)openeuler.org >>>

1 0

Re: [PATCH net] net: hns3: Trivial spell fix in hns3 driver
by patchwork-bot+netdevbpf＠kernel.org 10 Apr '21

10 Apr '21

Hello: This patch was applied to netdev/net.git (refs/heads/master): On Fri, 9 Apr 2021 08:42:23 +0100 you wrote: > Some trivial spelling mistakes which caught my eye during the > review of the code. > > Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> > --- > drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +- > drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) Here is the summary with links: - [net] net: hns3: Trivial spell fix in hns3 driver https://git.kernel.org/netdev/net/c/cd7e963d2f08 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html

1 0

[PATCH 00/10] tty: Fix some coding style issues
by Xiaofei Tan 09 Apr '21

09 Apr '21

Fix some issues reported by checkpatch.pl. All of them are coding style issues, no function changes. Xiaofei Tan (10): tty/sysrq: Add a blank line after declarations tty/sysrq: Fix issues of code indent should use tabs tty: tty_jobctrl: Add a blank line after declarations tty: tty_jobctrl: Fix coding style issues of block comments tty: tty_jobctrl: Remove spaces before tabs tty: tty_ldisc: Fix an issue of code indent should use tabs tty: tty_ldisc: Add a blank line after declarations tty: tty_ldisc: Fix coding style issues of block comments tty: tty_ldisc: Do not use assignment in if condition tty: tty_ldisc: Remove the repeated word 'the' drivers/tty/sysrq.c | 35 ++++++++++++++++++----------------- drivers/tty/tty_jobctrl.c | 29 +++++++++++++++++++---------- drivers/tty/tty_ldisc.c | 41 ++++++++++++++++++++++++++--------------- 3 files changed, 63 insertions(+), 42 deletions(-) -- 2.8.1

4 16

[PATCH net-next 0/2] net: hns3: add support for pm_ops
by Huazhong Tan 09 Apr '21

09 Apr '21

This series adds support for pm_ops in the HNS3 ethernet driver. Jiaran Zhang (2): net: hns3: change flr_prepare/flr_done function names net: hns3: add suspend and resume pm_ops drivers/net/ethernet/hisilicon/hns3/hnae3.h | 5 +-- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 37 +++++++++++++++++++--- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 29 ++++++++++------- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 27 +++++++++------- 4 files changed, 68 insertions(+), 30 deletions(-) -- 2.7.4

2 3

[PATCH v3 00/12] acpi: fix some coding style issues
by Xiaofei Tan 08 Apr '21

08 Apr '21

Fix some coding style issues reported by checkpatch.pl. Only cleanup and no function changes. Differences from v2 to v3: - Remove the modifications that may cause function change. Differences from v1 to v2: - Add subsystem and module name in the name of patch 05/15. - Change to use more proper module name for some patch names. Xiaofei Tan (12): ACPI: APD: fix a block comment align issue ACPI: processor: fix some coding style issues ACPI: ipmi: remove useless return statement for void function ACPI: LPSS: add a missed blank line after declarations ACPI: acpi_pad: add a missed blank line after declarations ACPI: battery: fix some coding style issues ACPI: button: fix some coding style issues ACPI: CPPC: fix some coding style issues ACPI: custom_method: fix a coding style issue ACPI: PM: add a missed blank line after declarations ACPI: sysfs: fix some coding style issues ACPI: dock: fix some coding style issues drivers/acpi/acpi_apd.c | 8 ++--- drivers/acpi/acpi_ipmi.c | 1 - drivers/acpi/acpi_lpss.c | 2 ++ drivers/acpi/acpi_pad.c | 4 +++ drivers/acpi/acpi_processor.c | 18 +++-------- drivers/acpi/battery.c | 63 ++++++++++++++++++++------------------ drivers/acpi/button.c | 9 ++---- drivers/acpi/cppc_acpi.c | 71 ++++++++++++++++++++++--------------------- drivers/acpi/custom_method.c | 2 +- drivers/acpi/device_pm.c | 3 ++ drivers/acpi/device_sysfs.c | 15 ++++++--- drivers/acpi/dock.c | 7 +++-- 12 files changed, 106 insertions(+), 97 deletions(-) -- 2.8.1

2 15

[PATCH v2] ACPI: AC: fix some coding style issues
by Xiaofei Tan 08 Apr '21

08 Apr '21

Fix some coding style issues reported by checkpatch.pl, including following types: ERROR: "foo * bar" should be "foo *bar" ERROR: code indent should use tabs where possible WARNING: Block comments use a trailing */ on a separate line WARNING: braces {} are not necessary for single statement blocks WARNING: void function return statements are not generally useful WARNING: CVS style keyword markers, these will _not_ be updated Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/acpi/ac.c | 28 ++++++++-------------------- 1 file changed, 8 insertions(+), 20 deletions(-) diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c index b86ee6e..b0cb662 100644 --- a/drivers/acpi/ac.c +++ b/drivers/acpi/ac.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-or-later /* - * acpi_ac.c - ACPI AC Adapter Driver ($Revision: 27 $) + * acpi_ac.c - ACPI AC Adapter Driver (Revision: 27) * * Copyright (C) 2001, 2002 Andy Grover <andrew.grover(a)intel.com> * Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh(a)intel.com> @@ -78,17 +78,14 @@ static struct acpi_driver acpi_ac_driver = { struct acpi_ac { struct power_supply *charger; struct power_supply_desc charger_desc; - struct acpi_device * device; + struct acpi_device *device; unsigned long long state; struct notifier_block battery_nb; }; #define to_acpi_ac(x) power_supply_get_drvdata(x) -/* -------------------------------------------------------------------------- - AC Adapter Management - -------------------------------------------------------------------------- */ - +/* AC Adapter Management */ static int acpi_ac_get_state(struct acpi_ac *ac) { acpi_status status = AE_OK; @@ -109,9 +106,7 @@ static int acpi_ac_get_state(struct acpi_ac *ac) return 0; } -/* -------------------------------------------------------------------------- - sysfs I/F - -------------------------------------------------------------------------- */ +/* sysfs I/F */ static int get_ac_property(struct power_supply *psy, enum power_supply_property psp, union power_supply_propval *val) @@ -138,10 +133,7 @@ static enum power_supply_property ac_props[] = { POWER_SUPPLY_PROP_ONLINE, }; -/* -------------------------------------------------------------------------- - Driver Model - -------------------------------------------------------------------------- */ - +/* Driver Model */ static void acpi_ac_notify(struct acpi_device *device, u32 event) { struct acpi_ac *ac = acpi_driver_data(device); @@ -174,8 +166,6 @@ static void acpi_ac_notify(struct acpi_device *device, u32 event) acpi_notifier_call_chain(device, event, (u32) ac->state); kobject_uevent(&ac->charger->dev.kobj, KOBJ_CHANGE); } - - return; } static int acpi_ac_battery_notify(struct notifier_block *nb, @@ -282,9 +272,8 @@ static int acpi_ac_add(struct acpi_device *device) ac->battery_nb.notifier_call = acpi_ac_battery_notify; register_acpi_notifier(&ac->battery_nb); end: - if (result) { + if (result) kfree(ac); - } return result; } @@ -293,7 +282,7 @@ static int acpi_ac_add(struct acpi_device *device) static int acpi_ac_resume(struct device *dev) { struct acpi_ac *ac; - unsigned old_state; + unsigned int old_state; if (!dev) return -EINVAL; @@ -352,9 +341,8 @@ static int __init acpi_ac_init(void) } result = acpi_bus_register_driver(&acpi_ac_driver); - if (result < 0) { + if (result < 0) return -ENODEV; - } return 0; } -- 2.8.1

2 1

[PATCH 0/2] meson build fixes for hns3
by Lijun Ou 08 Apr '21

08 Apr '21

This series fix meson build for kunpeng920 and kunpeng930 boards. Chengchang Tang (2): config/arm: fix Hisilicon kunpeng920 SoC build config/arm: fix Hisilicon kunpeng930 Soc build config/arm/arm64_kunpeng920_linux_gcc | 19 +++++++++++++++ config/arm/arm64_kunpeng930_linux_gcc | 19 +++++++++++++++ config/arm/meson.build | 27 ++++++++++++++++++++++ .../linux_gsg/cross_build_dpdk_for_arm64.rst | 5 ++++ 4 files changed, 70 insertions(+) create mode 100644 config/arm/arm64_kunpeng920_linux_gcc create mode 100644 config/arm/arm64_kunpeng930_linux_gcc -- 2.7.4

8 46

[PATCH] iommu: Fix a boundary issue to avoid performance drop
by chenxiang 07 Apr '21

07 Apr '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> After the change of patch ("iommu: Switch gather->end to the inclusive end"), the performace drops from 1600+K IOPS to 1200K in our kunpeng ARM64 platform. We find that the range [start1, end1) actually is joint from the range [end1, end2), but it is considered as disjoint after the change, so it needs more times of TLB sync, and spends more time on it. So fix the boundary issue to avoid performance drop. Fixes: 862c3715de8f ("iommu: Switch gather->end to the inclusive end") Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- include/linux/iommu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index ae8eddd..4d5bcc2 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -547,7 +547,7 @@ static inline void iommu_iotlb_gather_add_page(struct iommu_domain *domain, * structure can be rewritten. */ if (gather->pgsize != size || - end < gather->start || start > gather->end) { + end + 1 < gather->start || start > gather->end + 1) { if (gather->pgsize) iommu_iotlb_sync(domain, gather); gather->pgsize = size; -- 2.8.1

4 4

[PATCH v3 00/10] tty: Fix some coding style issues
by Xiaofei Tan 07 Apr '21

07 Apr '21

Fix some issues reported by checkpatch.pl. All of them are coding style issues, no function changes. Differences from v2 to v3: - Fix the misunderstanding of 'period' for the patch 04/10. Differences from v1 to v2: - Remove one redundant tab for the patch 02/10. - Add some expression optimization for some sentenses following - Jiri's advice for the patch 04/10. Xiaofei Tan (10): tty/sysrq: Add a blank line after declarations tty/sysrq: Fix issues of code indent should use tabs tty: tty_jobctrl: Add a blank line after declarations tty: tty_jobctrl: Fix coding style issues of block comments tty: tty_jobctrl: Remove spaces before tabs tty: tty_ldisc: Fix an issue of code indent should use tabs tty: tty_ldisc: Add a blank line after declarations tty: tty_ldisc: Fix coding style issues of block comments tty: tty_ldisc: Do not use assignment in if condition tty: tty_ldisc: Remove the repeated word 'the' drivers/tty/sysrq.c | 35 ++++++++++++++++++----------------- drivers/tty/tty_jobctrl.c | 29 +++++++++++++++++++---------- drivers/tty/tty_ldisc.c | 41 ++++++++++++++++++++++++++--------------- 3 files changed, 63 insertions(+), 42 deletions(-) -- 2.8.1

1 10

[PATCH v2 00/10] tty: Fix some coding style issues
by Xiaofei Tan 07 Apr '21

07 Apr '21

Fix some issues reported by checkpatch.pl. All of them are coding style issues, no function changes. Differences from v1 to v2: - Remove one redundant tab for the patch 02/10. - Add some expression optimization for some sentenses following - Jiri's advice for the patch 04/10. Xiaofei Tan (10): tty/sysrq: Add a blank line after declarations tty/sysrq: Fix issues of code indent should use tabs tty: tty_jobctrl: Add a blank line after declarations tty: tty_jobctrl: Fix coding style issues of block comments tty: tty_jobctrl: Remove spaces before tabs tty: tty_ldisc: Fix an issue of code indent should use tabs tty: tty_ldisc: Add a blank line after declarations tty: tty_ldisc: Fix coding style issues of block comments tty: tty_ldisc: Do not use assignment in if condition tty: tty_ldisc: Remove the repeated word 'the' drivers/tty/sysrq.c | 35 ++++++++++++++++++----------------- drivers/tty/tty_jobctrl.c | 29 +++++++++++++++++++---------- drivers/tty/tty_ldisc.c | 41 ++++++++++++++++++++++++++--------------- 3 files changed, 63 insertions(+), 42 deletions(-) -- 2.8.1

2 12

[PATCH net] net: hns3: clear VF down state bit before request link status
by Huazhong Tan 07 Apr '21

07 Apr '21

From: Guangbin Huang <huangguangbin2(a)huawei.com> Currently, the VF down state bit is cleared after VF sending link status request command. There is problem that when VF gets link status replied from PF, the down state bit may still set as 1. In this case, the link status replied from PF will be ignored and always set VF link status to down. To fix this problem, clear VF down state bit before VF requests link status. Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Guangbin Huang <huangguangbin2(a)huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong(a)huawei.com> --- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c index 700e068..14b83ec 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c @@ -2624,14 +2624,14 @@ static int hclgevf_ae_start(struct hnae3_handle *handle) { struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle); + clear_bit(HCLGEVF_STATE_DOWN, &hdev->state); + hclgevf_reset_tqp_stats(handle); hclgevf_request_link_info(hdev); hclgevf_update_link_mode(hdev); - clear_bit(HCLGEVF_STATE_DOWN, &hdev->state); - return 0; } -- 2.7.4

2 1

Would you please look this over?
by Sarah Johnson 06 Apr '21

06 Apr '21

How has your day been going? I want to share a message that has been spreading all over the internet that concerns the times we are living in. Whether you believe in God or not, this is a must read message! We can see throughout time how we have been slowly conditioned to come to this point where we are on the verge of a cashless society. Would it surprise you to know that the Bible foretold of this event? Don't believe me? This may be the most imporant message you will read in these times...please do not ignore this! This messsage reveals what the Mark of the Beast is, and the meaning behind counting a number people have been pondering for centuries, 666. This message also shares why Barack Obama will be the Antichrist as well as the gospel message. This is truly a message from God! In the Revelation of Jesus Christ given to the apostle John, we read: ..."Also he (the false prophet who deceives many by his miracles) forces everyone — great and small, rich and poor, free and slave — to receive a mark on his right hand or on his forehead preventing anyone from buying or selling unless he has the mark, that is, the name of the beast or the number of its name. This is where wisdom is needed; those who understand should count the number of the beast, for it is the number of a person, and its number is 666" (Revelation 13:16-18 CJB).... Referring to the last generation, this could only be speaking of a cashless money society, which we have yet to see, but are heading towards. Why? Revelation 13:17 tells us that we cannot buy or sell unless we receive the mark of the beast in our right-hand or forehead. We could still buy or sell among one another without receiving the mark if physical money was still currency. It logically deduces itself to this reason. These verses could not be referring to something spiritual because the word references two different physical locations (our right-hand or forehead) stating the mark will be on one "OR" the other. It once again logically deduces itself to this reason. Here is where it really starts to come together. It is shocking how accurate the Bible is concerning the RFID microchip. These are notes from a man named Carl Sanders who worked with a team of engineers to help develop this microchip in the late 1960's. Mr. Carl Sanders sat in seventeen New World Order meetings with heads of state officials such as Henry Kissinger and Bob Gates of the C.I.A. to discuss their agenda on how to bring forth this one-world system. The US government commissioned Mr. Sanders to engineer a microchip for identifying and controlling the peoples of the nations-a microchip that would be placed underneath the skin with a hypodermic needle (a quick, convenient process that would be progressively received by society). Mr. Sanders, along with a group of engineers behind him, with US grant monies provided by US tax dollars, took on this mission and produced a microchip which is powered by a lithium battery, rechargeable through the temperature fluctuations in our skin. Without having knowledge of the biblical scriptures (Carl was not a follower of Jesus at the time), these men spent one and a half million dollars gathering information on the best and most convenient spot to have the microchip placed in the body. Guess what? These researchers observed that the forehead and the back of the hand (the two spots Revelation says the mark will be placed) are not just the most convenient places, but are additionally the only viable spots for fast, consistent temperature fluctuations in the skin to recharge the lithium battery. The microchip is approximately seven millimeters in length, .75 millimeters in diameter, about the size of a grain of rice. It is capable of containing pages of details about you. All of your basic information, work information, crime data, health data, and financial history could be stored on this microchip. Mr. Sanders believes that this microchip, which he regretfully helped invent, is the "mark" mentioned in Revelation 13:16-18. The original Greek word for "mark" is "charagma," which is defined as a "scratch or etching." Additionally it is fascinating to be aware that the number 666 is in fact a word in the original Greek language. The word is "chi xi stigma," with the final word, "stigma," additionally meaning "to stick or prick. Carl believes this is referring to using a hypodermic needle being poked into a person to insert the microchip." Carl Sanders asked a Boston Medical Center doctor what would happen if the lithium contained within the RFID microchip leaked into the body. The doctor responded that if the microchip broke inside a human body, the lithium would cause a severe and painful wound filled with pus. This is what the book of Revelation has to say: "So the first angel poured his bowl on the earth, and a nasty and terrible sore appeared on the people who had the beast’s mark and worshipped its image" (Revelation 16:2 CEB). THE HIDDEN MEANING BEHIND THE NUMBER 666 REVEALED! What I first want to mention, before I share what the Holy Spirit has revealed to me concerning the number of the beast, is that God confirms in threes. We can see this throughout scripture: "For there are three that bear witness in heaven: the Father, the Word, and the Holy Spirit; and these three are one" (1 John 5:7 NKJV). "and that He was buried, and that He rose again the third day according to the Scriptures" (1 Corinthians 15:4 NKJV). "...Holy, holy, holy, Lord God Almighty, Who was and is and is to come!" (Revelation 4:8 NKJV). There are many more examples, but I thought I would just share three of them to make the point. Examining Revelation 13:16,17,18, the first group of three I would like to point out is that the mark of the beast is described in three separate verses, 16, 17 and 18. The next three I see is in verse 16, "He causes all..." is followed by three contrasting categories of people, 1 - "both small and great, 2 - rich and poor, 3 - free and slave...". Then unto verse 17, it opens with, "and that no one may buy or sell except one who has...", followed by three explanations of what one must have to buy or sell, 1 - "...the mark 2 - or the name of the beast, 3 - or the number of his name". Now unto verse 18, we read "Let him who has understanding calculate...", which is followed by, 1 - "the number of the beast, 2 - for it is the number of a man: 3 - His number is 666". The last three I see is the number "6" being used three times in a row. The reason I'm making this point about God confirming in three is because it is the key to unlocking how to calculate the number 666. Throughout the centuries there have been people trying to calculate numbers based on titles and names that come up to the number 666 to identify one person, the Antichrist; but from Revelation 13:18, I do not see where God is telling us to count up to 666, but rather to count the number of the beast. This number is identified as 666. So the verse is telling us to count the number 666. What does it mean to count? It means to add up. So how could we add up 666? Remember my previous point about God confirming in threes is key to unlocking the number 666. So logically, what would be the best way to count the number 666? To count it equally by using the rule of three based off the number. We cannot count it equally as 600+60+6, this would also bring us back to the start. We cannot count it as 600+600+600, or 60+60+60 because there are no zeroes in between or at the end of 666. The only logical option is 6+6+6=18. What is interesting is that the verse that reveals for us to count the number itself is verse 18 (there a total of 18 verses in Revelation Chapter 13), being the third verse out of the three verses that describe the mark of the beast in Revelation 13:16,17,18. What is 18 divided by 3? 6. So 3x6=18, or 6+6+6=18. Another interesting point is the only two other combinations (making a total of three possible combinations) for placing a "+" symbol in between 666 are: • 66+6=72 and 6+66=72. • Add both 72's together and you get 144. Why the number 144 is worth our attention is because the verse following Revelation 13:18 is the first time in the Bible where the 144,000 are being described in detail: "Then I looked, and behold, a Lamb standing on Mount Zion, and with Him one hundred and forty-four thousand, having His Father’s name written on their foreheads..." (Revelation 14:1). Now if you add up all three numbers from counting 666 by moving the "+" symbol around, it would be 72+72+18=162. What is compelling about the number 162, is, if you divide 144,000 by 162, you get 888. The name of Jesus in Greek gematria adds up to 888. The New Testament was originally written in the Greek language. Revelation 14:1 not only mentions the 144,000, but also the Lamb who is Jesus. Now what is interesting about the number for Jesus, 888, is that if you apply the same formula that was used to count 666, you get 8+8+8=24. Why the number 24? Revelation chapter 4 tells us there are 24 elders seated around the throne of God. This is the same throne where Jesus sits. Now if you take: • 8+8+8=24 • 8+88=96 • 88+8=96 you get 24+96+96=216. Take 144,000 divided by 216 and you get 666. Remember that this was the same exact formula we used to count the number 666 that ultimately brought forth the number 888. Here is a quick recap to demonstrate how this formula confirms itself as being the true way to count 666: 1: 6+6+6=18 » 66+6=72 » 6+66=72 » 18+72+72=162 2: 144,000 divided by 162=888 3: 8+8+8=24 » 88+8=96 » 8+88=96 » 24+96+96=216 4: 144,000 divided by 216=666 1: 6+6+6=18 » 66+6=72... As you can see, it is perpetual. And remember that we consistently used a formula that worked in threes being the number that God uses for confirmation. With utilizing the same formulation of counting by adding the "+" symbol in between the numbers, why do all these numbers relate in such a way? The book of Revelation contains the use of the number 7 in various forms. For instance 7 seals, 7 trumpets, and 7 bowls. What is interesting about the number 37 (three sevens) is if if you divide any number that contains the same single digit three times in a row, such as 111 to 999, it comes out to the value of if you were to add all three numbers up. For example 888 divided by 37 equals 24. So 8+8+8=24. Or 666 divided by 37 equals 18. So 6+6+6=18. Could this be another way of God's word confirming itself that the mystery behind calculating the number 666 indeed is 18? Another fascinating factor to be aware is that if you add up all the numbers from 1 to 36 (1+2+3...+36), it totals 666. The number 36, as in three sixes? May this be a sign that we need to add up three sixes as opposed to perceiving the number as six-hundred sixty six? Now what may this mean? We know in this world we are identified by numbers in numerous forms. From our birth certificate to social security, also with our drivers license, being identified founded on a system of ruler ship. So it is possible that this RFID chip will comprise a new identification that has a total of 18 characters. "here the wisdom is, the one having the mind let him calculate the number of the wild beast, number for "of human" it is, and the number of it 666" (Revelation 13:1, Greek Translation). The Greek word "anthrōpos" being used in verse 18 where it says "of human" is the Greek strongs concordance G444. The first two definitions of the word are "a human being, whether male or female", and, "generically, to include all human individuals". Could the number of the beast apply to all mankind? In the Greek (the New Testament was originally written in the Greek language), and other translations, you will notice the beast is described as an "it", instead of "him". The reason I'm making this point is because when a translation says "His number is 666", this would imply a singular person, the Antichrist. But by saying "the number of it 666", implies that it is of the beast system as a whole. We can know the number of the beast cannot be to identify products (like a new barcode) to buy or sell because scripture says we cannot buy or sell without the number of the beast. What am I getting at? There will be instances where you could buy something someone made themselves and it wouldn't have a store branded identification on it. But for this number to be in our chips, that is where it must be to conclude ultimately that we cannot buy or sell without having the number of the beast. As previously mentioned in Revelation 13:18, the number of the beast (6+6+6=18) is a "human number", definition "generically, to include all human individuals". May this be the title of the beast, the number of its name? The one-world beast system that's identified by 18 characters? This may fit the scriptures that speaks of a mark that we must have to buy or sell in our right-hand or forehead, and that it also includes the number of the beast, throughout a future cashless money society. Go to: http://bible-freedom.org http://45.55.61.201/index.php/campaigns[CAMPAIGN_UID/track-url/dz418dk4jd19… http://45.55.61.201/index.php/campaigns/xr701nhshj87c/track-url/dz418dk4jd1… http://45.55.61.201/index.php/campaigns/xr701nhshj87c/track-url/dz418dk4jd1…] to see all the proof! "Why did the Biden campaign choose 30330? 2020 divided by 666 = 3.0330 Who believes this to be a coincidence? October 2020 Isaiah 53:6 Someone said we are being whipsawed in 2020. Truly a great division is taking place between good and evil—both symbolically and literally (riots, unrest, politics). If you take the current year 2020 and divide it by the number 666 (known for its satanic implications) you will get the number 30330 (repeated). This number 30330 happens to be the number used to vote for Joe Biden and Kamala Harris. Freaky? Supernatural? Odd for sure. Whatever this means, it doesn’t seem good to me. First, why would anyone knowingly choose those particular numbers for their campaign? If they weren’t knowingly chosen, then it appears to be a supernatural act by the evil one himself and I would want to change those numbers ASAP. And if the numbers were chosen knowing their significance, are you satanic? Is this campaign satanic? Either way I do not believe this is a coincidence. And one thing is certain, 2020 is truly being divided by Satan. He is the master deceiver and spreader of chaos. Jesus calls him the father of lies." So I looked up this number 30330 concerning Joe Biden, and I found this information: If you send a text to that number (at that time), you would get a response asking to support Joe's campaign to take down Donald Trump, with one part in caps saying "CHIP IN >>" pointing to a link to go and donate. "CHIP IN"? Obama has used this phrase in the past on his twitter and people believe it is a subliminal message to receive the mark of the beast, that is to say the implantable RFID microCHIP that will go IN our body. The scriptures warns us in the last days that a false prophet will stand up doing miracles deceiving many to receive the mark of the beast: ..."And the beast was taken, and with him the false prophet that wrought the signs in his sight, wherewith he deceived them that had received the mark of the beast and them that worshipped his image: they two were cast alive into the lake of fire that burneth with brimstone" (Revelation 19:20 ASV)... At ALL COSTS, resist the mark! "Then a third angel followed them, saying with a loud voice, "If anyone worships the beast and his image, and receives his mark on his forehead or on his hand, he himself shall also drink of the wine of the wrath of God, which is poured out full strength into the cup of His indignation. He shall be tormented with fire and brimstone in the presence of the holy angels and in the presence of the Lamb. And the smoke of their torment ascends forever and ever; and they have no rest day or night, who worship the beast and his image, and whoever receives the mark of his name" (Revelation 14:9-11). We are living in very prophetic times with very important Biblical prophecies being fulfilled. When Donald Trump recognized Jerusalem as capital of Israel on December 6th of '17, this was a huge step to fulfill the Third Temple foretold within the the scriptures. God's holy Word's alerts us that the Antichrist will seat himself in this temple: "...and the man of sin is revealed, the son of perdition, who opposes and exalts himself above all that is called God or that is worshiped, so that he sits as God in the temple of God, showing himself that he is God" (2 Thessalonians 2:3-4). Within the Islamic religion, there is a figure called the Mahdi, referred to as their messiah who they are waiting to be revealed. There are various testimonies from people on the internet who believe this man shall be Barack Obama who is to be the biblical Antichrist. I have had unusual dreams about Obama. He got on stage declaring himself to be a follower of Christ with no affiliation to the Muslim faith, but was later revealed by his family that he indeed is a religious Muslim. So what's in the name? The meaning of someones name can say a lot about a person. God throughout history has given names to people that have a specific meaning tied to their lives. How about the name Barack Obama? Let us take a look at what may be hiding beneath the surface... Jesus says, "And He said to them, 'I saw Satan fall like lightning from heaven'" (Luke 10:18). In Hebrew, the name "Barack" means "lighting", and the use of "Bama" (Strongs Hebrew word 1116) is used to mean the "heights" of heaven. The day after the election of Barack Obama (11/04/08), the prevailing pick three lotto numbers in Illinois (Obama’s domestic state) for 11/5/08 were 666. Obama was a U.S. senator for the state of Illinois, and his zip code was 60606. Regardless, whoever seats himself in the future Third Temple that is to be built in Jerusalem, declaring himself to be God WILL BE THE ANTICHRIST. DO NOT BE LEAD ASTRAY. Why do we need Jesus? "for all have sinned and fall short of the glory of God" (Romans 2:23). "For the wages of sin is death, but the gift of God is eternal life in Christ Jesus our Lord" (Romans 6:23). Our good works can't save us from our sins. If we step before a judge, being guilty of a criminal offense, the judge will not judge us by the good that we have carried out, but rather the crimes we have committed. If we as fallen humanity, created in God's image, pose this kind of justice, how much more a perfect, righteous, and Holy creator? God has introduced to us His ethical law's by the ten commandments received by Moses at Mt. Siani. These legal guidelines were not given so we may be justified, but so that we might see the need for a saviour. They are the mirror of God's character of what He has put in each of us, with our conscious bearing witness that we all know that it is an act of evil to steal, lie, dishonor our mother and father, and so on. We may try to follow all the ethical guidelines of the ten commandments, but we'll never catch up to them to be justified before a Holy God. That same word of the law given to Moses became flesh over 2000 years ago in the body of Jesus Christ. He was brought forth to be our justification by perfectly fulfilling the law, living a sinless life that solely God could accomplish. The distance between us and the law of God can never be reconciled by our very own merit, but the arm of Jesus is stretched out by the grace and mercy of God. And if we are to seize hold of, by faith in Him, He'll pull us up being the one to justify us. As in the court of law, if someone steps in and pays your fine, even though you're guilty, the judge can do what is legal and just and let you go free. That is what Jesus did almost 2000 years in the past on the cross. It was a legal transaction being fulfilled in the spiritual realm by the shedding of His blood, with His last words being, "...It is finished!..." (John 19:30). Now why did Jesus have to die for us? Because God is Holy and just, the wrath that belongs to us could not go unnoticed. Because of the perfect righteousness and justice of God's character, it must be dealt with, it must be quenched and satisfied. For God takes no pleasure in the demise of the wicked (Ezekiel 18:23). That is why in Isaiah chapter 53, where it speaks of the coming Messiah and His soul being a sacrifice for our sins, why it says it satisfied God to crush His only begotten Son. That is due to the fact the wrath that we deserve was justified by being poured out upon His Son. For if it were to be poured out upon us who deserve it, we would all die and go to hell. God created a means of escape by pouring it out on His Son who's soul could not stay in Hades, but was raised and seated on the right hand of God in power. So now after we put on the Lord Jesus Christ (Romans 13:14), God no longer looks at the individual who deserves His wrath, but the glorious image of His perfect Son residing in our hearts, justifying us as if we obtained the wrath we deserve, making a means of escape from the curse of death. Now what we must do is turn from our sins and trust in the saviour, confessing and forsaking our sins. That is not just a head knowledge of believing in Jesus, but rather receiving His words, taking them to heart. In which we no longer live to practice sin, but turn away from our sins and practice righteousness: "Do you not know that the unrighteous will not inherit the kingdom of God? Do not be deceived. Neither fornicators, nor idolaters, nor adulterers, nor homosexuals, nor sodomites, nor thieves, nor covetous, nor drunkards, nor revilers, nor extortioners will inherit the kingdom of God. And such were some of you. But you were washed, but you were sanctified, but you were justified in the name of the Lord Jesus and by the Spirit of our God" (1 Corinthians 6:9-11). By doing so we will become transformed into the image of God by faith in His Son Christ Jesus Who's inclined to present the Holy Spirit to whoever ask of Him: "Most assuredly, I (Jesus) say to you, unless one is born of water and the Spirit, he cannot enter the kingdom of God. That which is born of the flesh is flesh, and that which is born of the Spirit is spirit. Do not marvel that I said to you, 'You must be born again.' (John 3:5-6). "But you are not in the flesh but in the Spirit, if indeed the Spirit of God dwells in you. Now if anyone does not have the Spirit of Christ, he is not His" (Romans 8:9). What are you waiting for? Our heavenly Father only wants the best for us all, restoring every little thing this world has stolen from us. That is what it means to be "holy". To be made whole. He is waiting to hear from you. That God given tongue to speak language, by way of faith, pray to Him, ask Him to forgive you by confessing to Him your sins and be willing to forsake them; that you receive the sacrifice of His Son Jesus on the cross, and that you need His Holy Spirit living inside you reworking you into a child of the living God. Jesus says, "but whoever drinks of the water that I shall give him (the Holy Spirit) will never thirst. But the water that I shall give him will become in him a fountain of water springing up into everlasting life." Did you realize that Jesus spoke more about hell than anyone else in the scriptures, even more than He spoke about heaven?! For this very reason He was brought forth to die for us, to deliver us from this place that we earned by our sins. He describes hell as a real place where, "Their worm does not die And the fire is not quenched" (Mark 9:44). And where, "There will be weeping and gnashing of teeth..." (Luke 13:28). Jesus tells us who to fear, "And do not fear those who kill the body but cannot kill the soul. But rather fear Him who is able to destroy both soul and body in hell" (Matthew 10:28). "Now I saw a new heaven and a new earth, for the first heaven and the first earth had passed away. Also there was no more sea. Then I, John, saw the holy city, New Jerusalem, coming down out of heaven from God, prepared as a bride adorned for her husband. And I heard a loud voice from heaven saying, 'Behold, the tabernacle of God is with men, and He will dwell with them, and they shall be His people. God Himself will be with them and be their God. And God will wipe away every tear from their eyes; there shall be no more death, nor sorrow, nor crying. There shall be no more pain, for the former things have passed away.' Then He who sat on the throne said, 'Behold, I make all things new.' And He said to me, 'Write, for these words are true and faithful.' And He said to me, 'It is done! I am the Alpha and the Omega, the Beginning and the End. I will give of the fountain of the water of life freely to him who thirsts. He who overcomes shall inherit all things, and I will be his God and he shall be My son. But the cowardly, unbelieving, abominable, murderers, sexually immoral, sorcerers, idolaters, and all liars shall have their part in the lake which burns with fire and brimstone, which is the second death.'" (Revelation 21:1-8).

1 0

[PATCH net] net: hns3: Limiting the scope of vector_ring_chain variable
by Salil Mehta 06 Apr '21

06 Apr '21

Limiting the scope of the variable vector_ring_chain to the block where it is used. Fixes: 424eb834a9be ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC") Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index bf4302a5cf95..65752f363f43 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -3704,7 +3704,6 @@ static void hns3_nic_set_cpumask(struct hns3_nic_priv *priv) static int hns3_nic_init_vector_data(struct hns3_nic_priv *priv) { - struct hnae3_ring_chain_node vector_ring_chain; struct hnae3_handle *h = priv->ae_handle; struct hns3_enet_tqp_vector *tqp_vector; int ret; @@ -3736,6 +3735,8 @@ static int hns3_nic_init_vector_data(struct hns3_nic_priv *priv) } for (i = 0; i < priv->vector_num; i++) { + struct hnae3_ring_chain_node vector_ring_chain; + tqp_vector = &priv->tqp_vector[i]; tqp_vector->rx_group.total_bytes = 0; -- 2.17.1

2 2

Hi
by Rachel Johnson 06 Apr '21

06 Apr '21

Hi there, I want to share a message that has been spreading all over the internet that concerns the times we are living in. Whether you believe in God or not, this is a must read message! We can see throughout time how we have been slowly conditioned to come to this point where we are on the verge of a cashless society. Would it surprise you to know that the Bible foretold of this event? Don't believe me? This may be the most imporant message you will read in these times...please do not ignore this! This messsage reveals what the Mark of the Beast is, and the meaning behind counting a number people have been pondering for centuries, 666. This message also shares why Barack Obama will be the Antichrist as well as the gospel message. This is truly a message from God! In the Revelation of Jesus Christ given to the apostle John, we read: ...."He (the false prophet who deceives many by his miracles) forces everyone—the small and great, the rich and poor, the free and slaves—to have a mark put on their right hand or on their forehead. He will not allow anyone to make a purchase or sell anything unless the person has the mark with the beast’s name or the number of its name. This calls for wisdom. Let the one who understands calculate the beast’s number, for it’s a human being’s number. Its number is six hundred sixty-six" (Revelation 13:16-18 CEB)..... Referring to the last generation, this could only be speaking of a cashless money society, which we have yet to see, but are heading towards. Why? Revelation 13:17 tells us that we cannot buy or sell unless we receive the mark of the beast in our right-hand or forehead. We could still buy or sell among one another without receiving the mark if physical money was still currency. It logically deduces itself to this reason. These verses could not be referring to something spiritual because the word references two different physical locations (our right-hand or forehead) stating the mark will be on one "OR" the other. It once again logically deduces itself to this reason. Here is where it really starts to come together. It is shocking how accurate the Bible is concerning the RFID microchip. These are notes from a man named Carl Sanders who worked with a team of engineers to help develop this microchip in the late 1960's. Mr. Carl Sanders sat in 17 New World Order meetings with heads-of-state officials such as Henry Kissinger and Bob Gates of the C.I.A. to discuss their agenda on how to bring about this one-world system. The government commissioned Carl Sanders to invent a microchip for identifying and controlling the peoples of the world-a microchip that might be inserted underneath the skin with a hypodermic needle (a quick, convenient process that would be gradually accepted by society). Carl Sanders, with a crew of engineers behind him, with US grant monies supplied by tax dollars, took on this challenge and designed a microchip that is powered by a lithium battery, rechargeable through the temperature changes in our skin. With out the knowledge of the Bible (Mr. Sanders was not a follower of Jesus at the time), these engineers spent one-and-a-half-million dollars doing research on the best and most convenient spot to have the microchip placed within the body. Guess what? These researchers determined that the forehead and the back of the hand (the two locations Revelation says the mark will be received) are not only the most convenient places, however are additionally the only viable locations for rapid, consistent temperature changes inside the skin to recharge the lithium battery. The microchip is approximately 7 millimeters in length, .75 millimeters in diameter, about the size of a grain of rice. It's capable of holding pages upon pages of details about you. All of your common information, work data, crime records, health records, and financial information will be saved on this microchip. Mr. Sanders believes that this microchip, which he regretfully helped engineer, is the "mark" mentioned in Revelation 13:16-18. The Greek word for "mark" is "charagma," which is defined as a "scratch or etching." It's also fascinating to observe that the number 666 is actually a word in the original Greek. This word being "chi xi stigma," with the final part, "stigma," additionally meaning "to stick or prick. Carl believes that is referencing to using a hypodermic needle being poked in the human flesh to insert the microchip." Carl asked a Boston Medical Center doctor what would happen if the lithium contained within the RFID microchip leaked into the body. The doctor responded that if the microchip broke inside a human body, the lithium would cause a severe and painful wound filled with pus. This is what the book of Revelation has to say: "So the first angel poured his bowl on the earth, and a nasty and terrible sore appeared on the people who had the beast’s mark and worshipped its image" (Revelation 16:2 CEB). THE HIDDEN MEANING BEHIND THE NUMBER 666 REVEALED! What I first want to mention, before I share what the Holy Spirit has revealed to me concerning the number of the beast, is that God confirms in threes. We can see this throughout scripture: "For there are three that bear witness in heaven: the Father, the Word, and the Holy Spirit; and these three are one" (1 John 5:7 NKJV). "and that He was buried, and that He rose again the third day according to the Scriptures" (1 Corinthians 15:4 NKJV). "...Holy, holy, holy, Lord God Almighty, Who was and is and is to come!" (Revelation 4:8 NKJV). There are many more examples, but I thought I would just share three of them to make the point. Examining Revelation 13:16,17,18, the first group of three I would like to point out is that the mark of the beast is described in three separate verses, 16, 17 and 18. The next three I see is in verse 16, "He causes all..." is followed by three contrasting categories of people, 1 - "both small and great, 2 - rich and poor, 3 - free and slave...". Then unto verse 17, it opens with, "and that no one may buy or sell except one who has...", followed by three explanations of what one must have to buy or sell, 1 - "...the mark 2 - or the name of the beast, 3 - or the number of his name". Now unto verse 18, we read "Let him who has understanding calculate...", which is followed by, 1 - "the number of the beast, 2 - for it is the number of a man: 3 - His number is 666". The last three I see is the number "6" being used three times in a row. The reason I'm making this point about God confirming in three is because it is the key to unlocking how to calculate the number 666. Throughout the centuries there have been people trying to calculate numbers based on titles and names that come up to the number 666 to identify one person, the Antichrist; but from Revelation 13:18, I do not see where God is telling us to count up to 666, but rather to count the number of the beast. This number is identified as 666. So the verse is telling us to count the number 666. What does it mean to count? It means to add up. So how could we add up 666? Remember my previous point about God confirming in threes is key to unlocking the number 666. So logically, what would be the best way to count the number 666? To count it equally by using the rule of three based off the number. We cannot count it equally as 600+60+6, this would also bring us back to the start. We cannot count it as 600+600+600, or 60+60+60 because there are no zeroes in between or at the end of 666. The only logical option is 6+6+6=18. What is interesting is that the verse that reveals for us to count the number itself is verse 18 (there a total of 18 verses in Revelation Chapter 13), being the third verse out of the three verses that describe the mark of the beast in Revelation 13:16,17,18. What is 18 divided by 3? 6. So 3x6=18, or 6+6+6=18. Another interesting point is the only two other combinations (making a total of three possible combinations) for placing a "+" symbol in between 666 are: • 66+6=72 and 6+66=72. • Add both 72's together and you get 144. Why the number 144 is worth our attention is because the verse following Revelation 13:18 is the first time in the Bible where the 144,000 are being described in detail: "Then I looked, and behold, a Lamb standing on Mount Zion, and with Him one hundred and forty-four thousand, having His Father’s name written on their foreheads..." (Revelation 14:1). Now if you add up all three numbers from counting 666 by moving the "+" symbol around, it would be 72+72+18=162. What is compelling about the number 162, is, if you divide 144,000 by 162, you get 888. The name of Jesus in Greek gematria adds up to 888. The New Testament was originally written in the Greek language. Revelation 14:1 not only mentions the 144,000, but also the Lamb who is Jesus. Now what is interesting about the number for Jesus, 888, is that if you apply the same formula that was used to count 666, you get 8+8+8=24. Why the number 24? Revelation chapter 4 tells us there are 24 elders seated around the throne of God. This is the same throne where Jesus sits. Now if you take: • 8+8+8=24 • 8+88=96 • 88+8=96 you get 24+96+96=216. Take 144,000 divided by 216 and you get 666. Remember that this was the same exact formula we used to count the number 666 that ultimately brought forth the number 888. Here is a quick recap to demonstrate how this formula confirms itself as being the true way to count 666: 1: 6+6+6=18 » 66+6=72 » 6+66=72 » 18+72+72=162 2: 144,000 divided by 162=888 3: 8+8+8=24 » 88+8=96 » 8+88=96 » 24+96+96=216 4: 144,000 divided by 216=666 1: 6+6+6=18 » 66+6=72... As you can see, it is perpetual. And remember that we consistently used a formula that worked in threes being the number that God uses for confirmation. With using the identical formulation of counting by adding the "+" symbol in between the numbers, why do all these numbers relate in such a way? The book of Revelation contains the use of the number 7 in various forms. For instance 7 seals, 7 trumpets, and 7 bowls. What is interesting about the number 37 (three sevens) is if if you divide any number that contains the same single digit three times in a row, such as 111 to 999, it comes out to the value of if you were to add all three numbers up. For example 888 divided by 37 equals 24. So 8+8+8=24. Or 666 divided by 37 equals 18. So 6+6+6=18. Could this be another way of God's word confirming itself that the mystery behind calculating the number 666 indeed is 18? Yet another fascinating point to observe is that if you add up all the numbers from 1 to 36 (1+2+3...+36), it totals 666. The number 36, as in three sixes? Could this be a sign that we need to add up three sixes instead of perceiving the number as six-hundred sixty six? Now what may this suggest? We all know in this world we are identified by numbers in numerous forms. Starting from our birth certificates to our social security card, as well as our drivers license, being identified founded on a system of ruler ship. So it's possible that this RFID chip will include a brand new identification that has a total of 18 characters. "here the wisdom is, the one having the mind let him calculate the number of the wild beast, number for "of human" it is, and the number of it 666" (Revelation 13:1, Greek Translation). The Greek word "anthrōpos" being used in verse 18 where it says "of human" is the Greek strongs concordance G444. The first two definitions of the word are "a human being, whether male or female", and, "generically, to include all human individuals". Could the number of the beast apply to all mankind? In the Greek (the New Testament was originally written in the Greek language), and other translations, you will notice the beast is described as an "it", instead of "him". The reason I'm making this point is because when a translation says "His number is 666", this would imply a singular person, the Antichrist. But by saying "the number of it 666", implies that it is of the beast system as a whole. We can know the number of the beast cannot be to identify products (like a new barcode) to buy or sell because scripture says we cannot buy or sell without the number of the beast. What am I getting at? There will be instances where you could buy something someone made themselves and it wouldn't have a store branded identification on it. But for this number to be in our chips, that is where it must be to conclude ultimately that we cannot buy or sell without having the number of the beast. As previously mentioned in Revelation 13:18, the number of the beast (6+6+6=18) is a "human number", definition "generically, to include all human individuals". Could this be the identification of the beast, the number of its name? The one-world beast system that's identified by 18 characters? This may fit the scriptures that speaks of a mark that we must have to buy or sell in our right-hand or forehead, and that it additionally consists of the number of the beast, during a future cashless money society. Go to: http://bible-freedom.org http://je-schools.com/index.php/campaigns[CAMPAIGN_UID/track-url/hh974bmo22… http://je-schools.com/index.php/campaigns/so9648ll8ob7c/track-url/hh974bmo2… http://je-schools.com/index.php/campaigns/so9648ll8ob7c/track-url/hh974bmo2…] to see all the proof! "Why did the Biden campaign choose 30330? 2020 divided by 666 = 3.0330 Who believes this to be a coincidence? October 2020 Isaiah 53:6 Someone said we are being whipsawed in 2020. Truly a great division is taking place between good and evil—both symbolically and literally (riots, unrest, politics). If you take the current year 2020 and divide it by the number 666 (known for its satanic implications) you will get the number 30330 (repeated). This number 30330 happens to be the number used to vote for Joe Biden and Kamala Harris. Freaky? Supernatural? Odd for sure. Whatever this means, it doesn’t seem good to me. First, why would anyone knowingly choose those particular numbers for their campaign? If they weren’t knowingly chosen, then it appears to be a supernatural act by the evil one himself and I would want to change those numbers ASAP. And if the numbers were chosen knowing their significance, are you satanic? Is this campaign satanic? Either way I do not believe this is a coincidence. And one thing is certain, 2020 is truly being divided by Satan. He is the master deceiver and spreader of chaos. Jesus calls him the father of lies." So I looked up this number 30330 concerning Joe Biden, and I found this information: If you send a text to that number (at that time), you would get a response asking to support Joe's campaign to take down Donald Trump, with one part in caps saying "CHIP IN >>" pointing to a link to go and donate. "CHIP IN"? Obama has used this phrase in the past on his twitter and people believe it is a subliminal message to receive the mark of the beast, that is to say the implantable RFID microCHIP that will go IN our body. The Bible warns us in the end times that a false prophet will stand up performing miracles deceiving many to acquire the mark of the beast: ...."Then the beast was captured, and with him the false prophet who worked signs in his presence, by which he deceived those who received the mark of the beast and those who worshiped his image" (Revelation 19:20).... At ALL COSTS, resist the mark! "Then a third angel followed them, saying with a loud voice, "If anyone worships the beast and his image, and receives his mark on his forehead or on his hand, he himself shall also drink of the wine of the wrath of God, which is poured out full strength into the cup of His indignation. He shall be tormented with fire and brimstone in the presence of the holy angels and in the presence of the Lamb. And the smoke of their torment ascends forever and ever; and they have no rest day or night, who worship the beast and his image, and whoever receives the mark of his name" (Revelation 14:9-11). We are dwelling in very prophetic times with major Biblical prophecies coming to pass. When Donald Trump acknowledged Jerusalem as capital of Israel on December 6 2017, this was a large step to bring forth the Third Temple foretold within the words of God. God's word warns us that the Antichrist will seat himself in this temple: "...and the man of sin is revealed, the son of perdition, who opposes and exalts himself above all that is called God or that is worshiped, so that he sits as God in the temple of God, showing himself that he is God" (2 Thessalonians 2:3-4). Within the Islamic religion, they have a person called the Mahdi, referred to as their messiah who they are awaiting to be revealed. There are various testimonies from people online who believe this man shall be Barack Obama who is to be the biblical Antichrist. I personally have had strange dreams concerning Obama. He got on stage claiming to be a follower of Jesus with no affiliation to the Muslim faith, however it was later revealed by his own family members that he certainly is a religious Muslim. So what's in the name? The meaning of someones name can say a lot about a person. God throughout history has given names to people that have a specific meaning tied to their lives. How about the name Barack Obama? Let us take a look at what may be hiding beneath the surface... Jesus says, "And He said to them, 'I saw Satan fall like lightning from heaven'" (Luke 10:18). In Hebrew, the name "Barack" means "lighting", and the usage of "Bama" (Strongs Hebrew phrase 1116) is used to mean the "heights" of heaven. The day following the election of Barack Obama (11/04/08), the triumphing pick three lotto numbers in Illinois (Obama’s home state) for 11/5/08 were 666. Obama had been U.S. senator for Illinois, and his zip code was 60606. Regardless, whomsoever seats themselves in the future Third Temple that is to be built in Jerusalem, declaring themselves to be God IS THE ANTICHRIST. DO NOT BE DECEIVED. Why do we need Jesus? "for all have sinned and fall short of the glory of God" (Romans 2:23). "For the wages of sin is death, but the gift of God is eternal life in Christ Jesus our Lord" (Romans 6:23). Our good works can't save us. If we step before a judge, being responsible for breaking the law, the judge won't judge us by the good that we have accomplished, rather the crimes we have committed. If we as fallen humanity, created in God's image, pose this type of moral justice, how much more a perfect, righteous, and Holy God? God has introduced to us His ethical law's by way of the ten commandments received by Moses at Mt. Siani. These laws were not given so we can be justified, however so that we may see the need for a savior. They're the mirror of God's character of what He has put in each of us, with our conscious bearing witness that we know that it's wrong to steal, lie, dishonor our parents, and so on. We can attempt to follow all the ethical laws of the ten commandments, however we will never catch up to them to be justified before a Holy God. The same word of the law given to Moses manifested as flesh over 2000 years ago inside the body of Jesus Christ. He was brought forth to be our justification by perfectly fulfilling the commandments of God, living a sinless life that only God could fulfill. The distance between us and the law can never be reconciled by our very own merit, but the arm of Jesus is stretched out by the grace and mercy of God. And if we are to seize hold of, by way of faith in Him, He will pull us up being the one to justify us. As inside the court of law, if someone steps in and pays your fine, despite the fact that you're guilty, the judge can do what's legal and just and let you go free. That is what Jesus did almost 2000 years in the past on the cross. It was a legal transaction being fulfilled inside the spiritual realm by the shedding of His blood, with His last words being, "...It is finished!..." (John 19:30). So why did Jesus have to die for us? Due to the fact that God is Holy and just, the wrath that belongs to us could not be brushed away. Because of the perfect righteousness and justice of God's character, it must be dealt with, it must be quenched and satisfied. For God takes no pleasure in the demise of the wicked (Ezekiel 18:23). That is why in Isaiah chapter 53, the place it speaks of the coming Messiah and His soul being a sacrifice for our sins, why it says it satisfied God to crush His only begotten Son. That is because the wrath that we deserve was justified by being poured out upon His Son. For if it were to be poured out upon us who deserve it, we would all perish and go to hell. God created a means of escape by pouring it out on His Son who's soul could not stay in Hades, however was raised and seated on the right hand of God in power. Now when we put on the Lord Jesus Christ (Romans 13:14), God no longer looks at the individual who deserves His wrath, but rather the glorious image of His perfect Son residing in us, justifying us as if we acquired the wrath we deserve, making a means of escape from the curse of death. Now what we must do is turn from our sins and believe in the savior, confessing and turning from our sins. That is not just a head knowledge of believing in Jesus, instead receiving His words, taking them to heart. In which we no longer live to exercise sin, however turn away from our sins and exercise righteousness: "Do you not know that the unrighteous will not inherit the kingdom of God? Do not be deceived. Neither fornicators, nor idolaters, nor adulterers, nor homosexuals, nor sodomites, nor thieves, nor covetous, nor drunkards, nor revilers, nor extortioners will inherit the kingdom of God. And such were some of you. But you were washed, but you were sanctified, but you were justified in the name of the Lord Jesus and by the Spirit of our God" (1 Corinthians 6:9-11). By doing so we may come to be transformed into the image of God by way of faith in His Son Christ Jesus Who is inclined to offer the Holy Spirit to whoever ask of Him: "Most assuredly, I (Jesus) say to you, unless one is born of water and the Spirit, he cannot enter the kingdom of God. That which is born of the flesh is flesh, and that which is born of the Spirit is spirit. Do not marvel that I said to you, 'You must be born again.' (John 3:5-6). "But you are not in the flesh but in the Spirit, if indeed the Spirit of God dwells in you. Now if anyone does not have the Spirit of Christ, he is not His" (Romans 8:9). Now what are you waiting for? Our Father in heaven only wishes the best for us, restoring all the pieces this world has stolen from us. That is what it means to be "holy". To be made whole. He's waiting to hear from you. That God given tongue to speak language, by using faith, pray to Him, ask Him to forgive you by confessing to Him your sins and be willing to forsake them; that you receive the sacrifice of His Son Jesus on the cross, and that you need His Holy Spirit dwelling inside you transforming you into a child of God. Jesus says, "but whoever drinks of the water that I shall give him (the Holy Spirit) will never thirst. But the water that I shall give him will become in him a fountain of water springing up into everlasting life." Did you realize that Jesus spoke more about hell than anybody in God's holy word, even more than He spoke about heaven?! For this very cause He was brought forth to die for us, to deliver us from this place that we earned by our sins against a holy God. He describes hell as a real place where, "Their worm does not die And the fire is not quenched" (Mark 9:44). And where, "There will be weeping and gnashing of teeth..." (Luke 13:28). Jesus tells us who to fear, "And do not fear those who kill the body but cannot kill the soul. But rather fear Him who is able to destroy both soul and body in hell" (Matthew 10:28). "Now I saw a new heaven and a new earth, for the first heaven and the first earth had passed away. Also there was no more sea. Then I, John, saw the holy city, New Jerusalem, coming down out of heaven from God, prepared as a bride adorned for her husband. And I heard a loud voice from heaven saying, 'Behold, the tabernacle of God is with men, and He will dwell with them, and they shall be His people. God Himself will be with them and be their God. And God will wipe away every tear from their eyes; there shall be no more death, nor sorrow, nor crying. There shall be no more pain, for the former things have passed away.' Then He who sat on the throne said, 'Behold, I make all things new.' And He said to me, 'Write, for these words are true and faithful.' And He said to me, 'It is done! I am the Alpha and the Omega, the Beginning and the End. I will give of the fountain of the water of life freely to him who thirsts. He who overcomes shall inherit all things, and I will be his God and he shall be My son. But the cowardly, unbelieving, abominable, murderers, sexually immoral, sorcerers, idolaters, and all liars shall have their part in the lake which burns with fire and brimstone, which is the second death.'" (Revelation 21:1-8).

1 0

[PATCH V2 net 0/2] Misc. fixes for hns3 driver
by Salil Mehta 06 Apr '21

06 Apr '21

Fixes for the miscellaneous problems found during the review of the code. Change Summary: Patch 1/2, Change V1->V2: [1] Fixed comments from Leon Romanovsky Link: https://lkml.org/lkml/2021/4/4/14 Patch 2/2, Change V1->V2: None Salil Mehta (2): net: hns3: Remove the left over redundant check & assignment net: hns3: Remove un-necessary 'else-if' in the hclge_reset_event() drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) -- 2.17.1

2 3

[PATCH net 0/2] Misc. fixes for hns3 driver
by Salil Mehta 06 Apr '21

06 Apr '21

Fixes for the miscellaneous problems found during the review of the code. Salil Mehta (2): net: hns3: Remove the left over redundant check & assignment net: hns3: Remove un-necessary 'else-if' in the hclge_reset_event() drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.17.1

2 6

[PATCH] dma-mapping: benchmark: use the correct HiSilicon copyright
by Hao Fang 02 Apr '21

02 Apr '21

s/Hisilicon/HiSilicon/g. It should use capital S, according to https://www.hisilicon.com/en/terms-of-use. Signed-off-by: Hao Fang <fanghao11(a)huawei.com> --- kernel/dma/map_benchmark.c | 2 +- tools/testing/selftests/dma/dma_map_benchmark.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index e0e64f8..00d6549 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-only /* - * Copyright (C) 2020 Hisilicon Limited. + * Copyright (C) 2020 HiSilicon Limited. */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt diff --git a/tools/testing/selftests/dma/dma_map_benchmark.c b/tools/testing/selftests/dma/dma_map_benchmark.c index fb23ce9..b492bed 100644 --- a/tools/testing/selftests/dma/dma_map_benchmark.c +++ b/tools/testing/selftests/dma/dma_map_benchmark.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-only /* - * Copyright (C) 2020 Hisilicon Limited. + * Copyright (C) 2020 HiSilicon Limited. */ #include <fcntl.h> -- 2.8.1

3 2

[PATCH] dma-mapping: benchmark: Add support for multi-pages map/unmap
by chenxiang 02 Apr '21

02 Apr '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> Currently it only support one page map/unmap once a time for dma-map benchmark, but there are some other scenaries which need to support for multi-page map/unmap: for those multi-pages interfaces such as dma_alloc_coherent() and dma_map_sg(), the time spent on multi-pages map/unmap is not the time of a single page * npages (not linear) as it may use block description instead of page description when it is satified with the size such as 2M/1G, and also it can send a single TLB invalidation command to invalidate multi-pages instead of multi-times when RIL is enabled (which will short the time of unmap). So it is necessary to add support for multi-pages map/unmap. Add a parameter "-g" to support multi-pages map/unmap. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- kernel/dma/map_benchmark.c | 21 ++++++++++++++------- tools/testing/selftests/dma/dma_map_benchmark.c | 20 ++++++++++++++++---- 2 files changed, 30 insertions(+), 11 deletions(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index e0e64f8..a5c1b01 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -38,7 +38,8 @@ struct map_benchmark { __u32 dma_bits; /* DMA addressing capability */ __u32 dma_dir; /* DMA data direction */ __u32 dma_trans_ns; /* time for DMA transmission in ns */ - __u8 expansion[80]; /* For future use */ + __u32 granule; /* how many PAGE_SIZE will do map/unmap once a time */ + __u8 expansion[76]; /* For future use */ }; struct map_benchmark_data { @@ -58,9 +59,11 @@ static int map_benchmark_thread(void *data) void *buf; dma_addr_t dma_addr; struct map_benchmark_data *map = data; + int npages = map->bparam.granule; + u64 size = npages * PAGE_SIZE; int ret = 0; - buf = (void *)__get_free_page(GFP_KERNEL); + buf = alloc_pages_exact(size, GFP_KERNEL); if (!buf) return -ENOMEM; @@ -76,10 +79,10 @@ static int map_benchmark_thread(void *data) * 66 means evertything goes well! 66 is lucky. */ if (map->dir != DMA_FROM_DEVICE) - memset(buf, 0x66, PAGE_SIZE); + memset(buf, 0x66, size); map_stime = ktime_get(); - dma_addr = dma_map_single(map->dev, buf, PAGE_SIZE, map->dir); + dma_addr = dma_map_single(map->dev, buf, size, map->dir); if (unlikely(dma_mapping_error(map->dev, dma_addr))) { pr_err("dma_map_single failed on %s\n", dev_name(map->dev)); @@ -93,7 +96,7 @@ static int map_benchmark_thread(void *data) ndelay(map->bparam.dma_trans_ns); unmap_stime = ktime_get(); - dma_unmap_single(map->dev, dma_addr, PAGE_SIZE, map->dir); + dma_unmap_single(map->dev, dma_addr, size, map->dir); unmap_etime = ktime_get(); unmap_delta = ktime_sub(unmap_etime, unmap_stime); @@ -112,7 +115,7 @@ static int map_benchmark_thread(void *data) } out: - free_page((unsigned long)buf); + free_pages_exact(buf, size); return ret; } @@ -203,7 +206,6 @@ static long map_benchmark_ioctl(struct file *file, unsigned int cmd, struct map_benchmark_data *map = file->private_data; void __user *argp = (void __user *)arg; u64 old_dma_mask; - int ret; if (copy_from_user(&map->bparam, argp, sizeof(map->bparam))) @@ -234,6 +236,11 @@ static long map_benchmark_ioctl(struct file *file, unsigned int cmd, return -EINVAL; } + if (map->bparam.granule < 1 || map->bparam.granule > 1024) { + pr_err("invalid granule size\n"); + return -EINVAL; + } + switch (map->bparam.dma_dir) { case DMA_MAP_BIDIRECTIONAL: map->dir = DMA_BIDIRECTIONAL; diff --git a/tools/testing/selftests/dma/dma_map_benchmark.c b/tools/testing/selftests/dma/dma_map_benchmark.c index fb23ce9..6f2caa6 100644 --- a/tools/testing/selftests/dma/dma_map_benchmark.c +++ b/tools/testing/selftests/dma/dma_map_benchmark.c @@ -40,7 +40,8 @@ struct map_benchmark { __u32 dma_bits; /* DMA addressing capability */ __u32 dma_dir; /* DMA data direction */ __u32 dma_trans_ns; /* time for DMA transmission in ns */ - __u8 expansion[80]; /* For future use */ + __u32 granule; /* how many PAGE_SIZE will do map/unmap once a time */ + __u8 expansion[76]; /* For future use */ }; int main(int argc, char **argv) @@ -51,11 +52,13 @@ int main(int argc, char **argv) int threads = 1, seconds = 20, node = -1; /* default dma mask 32bit, bidirectional DMA */ int bits = 32, xdelay = 0, dir = DMA_MAP_BIDIRECTIONAL; + /* default granule 1 PAGESIZE */ + int granule = 1; int cmd = DMA_MAP_BENCHMARK; char *p; - while ((opt = getopt(argc, argv, "t:s:n:b:d:x:")) != -1) { + while ((opt = getopt(argc, argv, "t:s:n:b:d:x:g:")) != -1) { switch (opt) { case 't': threads = atoi(optarg); @@ -75,6 +78,9 @@ int main(int argc, char **argv) case 'x': xdelay = atoi(optarg); break; + case 'g': + granule = atoi(optarg); + break; default: return -1; } @@ -110,6 +116,11 @@ int main(int argc, char **argv) exit(1); } + if (granule < 1 || granule > 1024) { + fprintf(stderr, "invalid granule size\n"); + exit(1); + } + fd = open("/sys/kernel/debug/dma_map_benchmark", O_RDWR); if (fd == -1) { perror("open"); @@ -123,14 +134,15 @@ int main(int argc, char **argv) map.dma_bits = bits; map.dma_dir = dir; map.dma_trans_ns = xdelay; + map.granule = granule; if (ioctl(fd, cmd, &map)) { perror("ioctl"); exit(1); } - printf("dma mapping benchmark: threads:%d seconds:%d node:%d dir:%s\n", - threads, seconds, node, dir[directions]); + printf("dma mapping benchmark: threads:%d seconds:%d node:%d dir:%s granule: %d\n", + threads, seconds, node, dir[directions], granule); printf("average map latency(us):%.1f standard deviation:%.1f\n", map.avg_map_100ns/10.0, map.map_stddev/10.0); printf("average unmap latency(us):%.1f standard deviation:%.1f\n", -- 2.8.1

3 2

[PATCH] tty: pty: Add a blank line after declarations
by Xiaofei Tan 02 Apr '21

02 Apr '21

Add a blank line after declarations, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/pty.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c index 5e23745..106265a 100644 --- a/drivers/tty/pty.c +++ b/drivers/tty/pty.c @@ -159,6 +159,7 @@ static int pty_chars_in_buffer(struct tty_struct *tty) static int pty_set_lock(struct tty_struct *tty, int __user *arg) { int val; + if (get_user(val, arg)) return -EFAULT; if (val) @@ -171,6 +172,7 @@ static int pty_set_lock(struct tty_struct *tty, int __user *arg) static int pty_get_lock(struct tty_struct *tty, int __user *arg) { int locked = test_bit(TTY_PTY_LOCK, &tty->flags); + return put_user(locked, arg); } @@ -200,6 +202,7 @@ static int pty_set_pktmode(struct tty_struct *tty, int __user *arg) static int pty_get_pktmode(struct tty_struct *tty, int __user *arg) { int pktmode = tty->packet; + return put_user(pktmode, arg); } @@ -463,6 +466,7 @@ static int pty_install(struct tty_driver *driver, struct tty_struct *tty) static void pty_remove(struct tty_driver *driver, struct tty_struct *tty) { struct tty_struct *pair = tty->link; + driver->ttys[tty->index] = NULL; if (pair) pair->driver->ttys[pair->index] = NULL; -- 2.8.1

1 0

[PATCH v2 00/15] acpi: fix some coding style issues
by Xiaofei Tan 02 Apr '21

02 Apr '21

Fix some coding style issues reported by checkpatch.pl. Differences from v1 to v2: - Add subsystem and module name in the name of patch 05/15. - Change to use more proper module name for some patch names. Xiaofei Tan (15): ACPI: APD: fix a block comment align issue ACPI: processor: fix some coding style issues ACPI: debug: fix some coding style issues ACPI: table: replace __attribute__((packed)) by __packed ACPI: ipmi: remove useless return statement for void function ACPI: LPSS: fix some coding style issues ACPI: memhotplug: fix a coding style issue ACPI: acpi_pad: fix a coding style issue ACPI: battery: fix some coding style issues ACPI: button: fix some coding style issues ACPI: CPPC: fix some coding style issues ACPI: custom_method: fix a coding style issue ACPI: PM: fix some coding style issues ACPI: sysfs: fix some coding style issues ACPI: dock: fix some coding style issues drivers/acpi/acpi_apd.c | 8 ++--- drivers/acpi/acpi_dbg.c | 40 +++++++++++------------- drivers/acpi/acpi_fpdt.c | 6 ++-- drivers/acpi/acpi_ipmi.c | 1 - drivers/acpi/acpi_lpss.c | 4 ++- drivers/acpi/acpi_memhotplug.c | 2 +- drivers/acpi/acpi_pad.c | 4 +++ drivers/acpi/acpi_processor.c | 18 +++-------- drivers/acpi/battery.c | 64 +++++++++++++++++++++---------------- drivers/acpi/button.c | 10 +++--- drivers/acpi/cppc_acpi.c | 71 +++++++++++++++++++++--------------------- drivers/acpi/custom_method.c | 2 +- drivers/acpi/device_pm.c | 3 ++ drivers/acpi/device_sysfs.c | 15 ++++++--- drivers/acpi/dock.c | 7 +++-- 15 files changed, 138 insertions(+), 117 deletions(-) -- 2.8.1

7 36

[PATCH v1] ata: ahci: Disable SXS for Hisilicon Kunpeng920
by Luo Jiaxing 31 Mar '21

31 Mar '21

From: Xingui Yang <yangxingui(a)huawei.com> On Hisilicon Kunpeng920, ESP is set to 1 by default for all ports of SATA controller. In some scenarios, some ports are not external SATA ports, and it cause disks connected to these ports to be identified as removable disks. So disable the SXS capability on the software side to prevent users from mistakenly considering non-removable disks as removable disks and performing related operations. Signed-off-by: Xingui Yang <yangxingui(a)huawei.com> Signed-off-by: Luo Jiaxing <luojiaxing(a)huawei.com> Reviewed-by: John Garry <john.garry(a)huawei.com> --- drivers/ata/ahci.c | 5 +++++ drivers/ata/ahci.h | 1 + drivers/ata/libahci.c | 5 +++++ 3 files changed, 11 insertions(+) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 00ba8e5..33192a8 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1772,6 +1772,11 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) hpriv->flags |= AHCI_HFLAG_NO_DEVSLP; #ifdef CONFIG_ARM64 + if (pdev->vendor == PCI_VENDOR_ID_HUAWEI && + pdev->device == 0xa235 && + pdev->revision < 0x30) + hpriv->flags |= AHCI_HFLAG_NO_SXS; + if (pdev->vendor == 0x177d && pdev->device == 0xa01c) hpriv->irq_handler = ahci_thunderx_irq_handler; #endif diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h index 98b8baa..d1f284f 100644 --- a/drivers/ata/ahci.h +++ b/drivers/ata/ahci.h @@ -242,6 +242,7 @@ enum { suspend/resume */ AHCI_HFLAG_IGN_NOTSUPP_POWER_ON = (1 << 27), /* ignore -EOPNOTSUPP from phy_power_on() */ + AHCI_HFLAG_NO_SXS = (1 << 28), /* SXS not supported */ /* ap->flags bits */ diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c index ea5bf5f..fec2e97 100644 --- a/drivers/ata/libahci.c +++ b/drivers/ata/libahci.c @@ -493,6 +493,11 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv) cap |= HOST_CAP_ALPM; } + if ((cap & HOST_CAP_SXS) && (hpriv->flags & AHCI_HFLAG_NO_SXS)) { + dev_info(dev, "controller does not support SXS, disabling CAP_SXS\n"); + cap &= ~HOST_CAP_SXS; + } + if (hpriv->force_port_map && port_map != hpriv->force_port_map) { dev_info(dev, "forcing port_map 0x%x -> 0x%x\n", port_map, hpriv->force_port_map); -- 2.7.4

3 4

[PATCH RFC for-next 1/1] arm64: sve: Fix some compile errors about sve_cond_update_zcr_vq
by Xiaofei Tan 31 Mar '21

31 Mar '21

There are some compile errors of ARM64 KVM when ARM64_SVE is not selected, in the locations of sve_cond_update_zcr_vq used. One error log is as following: CC arch/arm64/kvm/sys_regs.o In file included from arch/arm64/kvm/hyp/vhe/switch.c:8:0: ./arch/arm64/kvm/hyp/include/hyp/switch.h: In function ‘__hyp_sve_restore_guest’: ./arch/arm64/kvm/hyp/include/hyp/switch.h:220:2: error: implicit declaration of function ‘sve_cond_update_zcr_vq’; did you mean ‘kvm_pmu_update_run’? [-Werror=implicit-function-declaration] sve_cond_update_zcr_vq(vcpu_sve_max_vq(vcpu) - 1, SYS_ZCR_EL2); ^~~~~~~~~~~~~~~~~~~~~~ kvm_pmu_update_run The root cause is that sve_cond_update_zcr_vq is not defined when ARM64_SVE is not selected. Fix it by adding an empty definition when CONFIG_ARM64_SVE=n. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- arch/arm64/include/asm/fpsimd.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h index 05c9c55..3f93b63 100644 --- a/arch/arm64/include/asm/fpsimd.h +++ b/arch/arm64/include/asm/fpsimd.h @@ -168,6 +168,8 @@ static inline int sve_get_current_vl(void) static inline void sve_user_disable(void) { BUILD_BUG(); } static inline void sve_user_enable(void) { BUILD_BUG(); } +#define sve_cond_update_zcr_vq(val, reg) + static inline void sve_init_vq_map(void) { } static inline void sve_update_vq_map(void) { } static inline int sve_verify_vq_map(void) { return 0; } -- 2.8.1

2 1

[RESEND net-next 0/4] net: remove repeated words
by Huazhong Tan 31 Mar '21

31 Mar '21

This patch-set removes some repeated words in comments. Peng Li (4): net: i40e: remove repeated words net: bonding: remove repeated word net: phy: remove repeated word net: ipa: remove repeated words drivers/net/bonding/bond_alb.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_main.c | 4 ++-- drivers/net/ipa/ipa_endpoint.c | 4 ++-- drivers/net/phy/mdio_bus.c | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) -- 2.7.4

6 9

[PATCH v2] iommu/arm-smmu-v3: Add a check to avoid invalid iotlb sync
by chenxiang 30 Mar '21

30 Mar '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> It may send a invalid tlb sync for smmuv3 if iotlb_gather is not valid (iotlb_gather->pgsize = 0). So add a check to avoid invalid iotlb sync for it. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++ 1 file changed, 3 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 8594b4a..941ba54 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -2305,6 +2305,9 @@ static void arm_smmu_iotlb_sync(struct iommu_domain *domain, { struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); + if (!gather->pgsize) + return; + arm_smmu_tlb_inv_range_domain(gather->start, gather->end - gather->start + 1, gather->pgsize, true, smmu_domain); -- 2.8.1

2 1

[PATCH] iommu: Add a check to avoid invalid iotlb sync
by chenxiang 30 Mar '21

30 Mar '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> Currently it will send a iotlb sync at end of iommu unmap even if iotlb_gather is not valid (iotlb_gather->pgsize = 0). Actually it is not necessary, so add a check to avoid invalid iotlb sync. Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> --- include/linux/iommu.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 9ca6e6b..6afa61b 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -529,6 +529,9 @@ static inline void iommu_flush_iotlb_all(struct iommu_domain *domain) static inline void iommu_iotlb_sync(struct iommu_domain *domain, struct iommu_iotlb_gather *iotlb_gather) { + if (!iotlb_gather->pgsize) + return; + if (domain->ops->iotlb_sync) domain->ops->iotlb_sync(domain, iotlb_gather); -- 2.8.1

4 5

[PATCH net-next 0/4] net: remove repeated words
by Huazhong Tan 30 Mar '21

30 Mar '21

This patch-set removes some repeated words in comments. Peng Li (4): net: i40e: remove repeated words net: bonding: remove repeated word net: phy: remove repeated word net: ipa: remove repeated words drivers/net/bonding/bond_alb.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_main.c | 4 ++-- drivers/net/ipa/ipa_endpoint.c | 4 ++-- drivers/net/phy/mdio_bus.c | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) -- 2.7.4

1 5

Re: [PATCH] libata: Increase the timeout of command ATA_CMD_READ_LOG_DMA_EXT
by chenxiang (M) 30 Mar '21

30 Mar '21

Ping.... 在 2020/10/15 9:57, chenxiang 写道: > From: Xiang Chen <chenxiang66(a)hisilicon.com> > > ATA_CMD_READ_LOG_DMA_EXT command normally uses the common internal command > default timeout (5s), and it is adequate in most situations. But it is not > enough for some disks such as ST4000NM0035 which causes qc timeout > sometimes as follows: > ... > [ 157.284284] sas: Enter sas_scsi_recover_host busy: 0 failed: 0 > [ 157.290124] sas: ata8: end_device-4:0:2: dev error handler > [ 157.290128] sas: ata9: end_device-4:0:8: dev error handler > [ 157.290131] sas: ata10: end_device-4:0:11: dev error handler > [ 164.588391] ata9.00: qc timeout (cmd 0x47) > [ 164.588393] ata8.00: qc timeout (cmd 0x47) > [ 164.588395] ata10.00: qc timeout (cmd 0x47) > [ 166.582572] ata10.00: READ LOG DMA EXT failed, trying PIO > [ 166.587960] ata10.00: NCQ Send/Recv Log not supported > [ 166.592997] ata10.00: ATA-10: ST4000NM0035-1V4107, TN03, max UDMA/133 > [ 166.599414] ata10.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 32) > [ 166.606011] ata10.00: failed to set xfermode (err_mask=0x40) > [ 166.659253] ata8.00: READ LOG DMA EXT failed, trying PIO > [ 166.664559] ata8.00: NCQ Send/Recv Log not supported > [ 166.669506] ata8.00: ATA-10: ST4000NM0035-1V4107, TN03, max UDMA/133 > [ 166.675837] ata8.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 32) > [ 166.682343] ata8.00: failed to set xfermode (err_mask=0x40) > [ 166.743458] ata9.00: READ LOG DMA EXT failed, trying PIO > [ 166.748765] ata9.00: NCQ Send/Recv Log not supported > [ 166.753713] ata9.00: ATA-10: ST4000NM0035-1V4107, TN03, max UDMA/133 > [ 166.760045] ata9.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 32) > [ 166.766553] ata9.00: failed to set xfermode (err_mask=0x40) > [ 168.886378] ata10.00: configured for UDMA/133 > [ 168.999943] ata8.00: configured for UDMA/133 > [ 169.050801] ata9.00: configured for UDMA/133 > [ 169.055071] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1 > ... > Actually it may takes about 9s to complete the command for disk ST4000NM0035 > sometimes. So to avoid the issue, increase the timeout of command > ATA_CMD_READ_LOG_DMA_EXT from 5s to 15s. > > Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> > Reviewed-by: John Garry <john.garry(a)huawei.com> > --- > drivers/ata/libata-eh.c | 9 +++++++++ > include/linux/libata.h | 2 +- > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c > index 474c6c3..6db9474 100644 > --- a/drivers/ata/libata-eh.c > +++ b/drivers/ata/libata-eh.c > @@ -100,6 +100,13 @@ static const unsigned long ata_eh_flush_timeouts[] = { > ULONG_MAX, > }; > > +static const unsigned long ata_eh_read_log_ext_timeouts[] = { > + 15000, > + 15000, > + 30000, > + ULONG_MAX, > +}; > + > static const unsigned long ata_eh_other_timeouts[] = { > 5000, /* same rationale as identify timeout */ > 10000, /* ditto */ > @@ -139,6 +146,8 @@ ata_eh_cmd_timeout_table[ATA_EH_CMD_TIMEOUT_TABLE_SIZE] = { > .timeouts = ata_eh_other_timeouts, }, > { .commands = CMDS(ATA_CMD_FLUSH, ATA_CMD_FLUSH_EXT), > .timeouts = ata_eh_flush_timeouts }, > + { .commands = CMDS(ATA_CMD_READ_LOG_DMA_EXT, ATA_CMD_READ_LOG_EXT), > + .timeouts = ata_eh_read_log_ext_timeouts }, > }; > #undef CMDS > > diff --git a/include/linux/libata.h b/include/linux/libata.h > index b0bd30e..bcc68b3 100644 > --- a/include/linux/libata.h > +++ b/include/linux/libata.h > @@ -390,7 +390,7 @@ enum { > /* This should match the actual table size of > * ata_eh_cmd_timeout_table in libata-eh.c. > */ > - ATA_EH_CMD_TIMEOUT_TABLE_SIZE = 6, > + ATA_EH_CMD_TIMEOUT_TABLE_SIZE = 7, > > /* Horkage types. May be set by libata or controller on drives > (some horkage may be drive/controller pair dependent */

1 0

[PATCH net-next 0/9] net: hns3: misc updates for -next
by Huazhong Tan 30 Mar '21

30 Mar '21

This series include some updates for the HNS3 ethernet driver. #1 & #2 fix two bugs in commit fc4243b8de8b ("net: hns3: refactor flow director configuration"). #3 modifies a potential overflow risk. #4 remove the rss_size limitation when updating rss size. #5 optimizes the resetting of tqp. #6 & #7 add updates for the IO path. #8 expands the tc config command. #9 adds a new stats. Guangbin Huang (1): net: hns3: remediate a potential overflow risk of bd_num_list Guojia Liao (1): net: hns3: expand the tc config command Jian Shen (3): net: hns3: fix missing rule state assignment net: hns3: fix use-after-free issue for hclge_add_fd_entry_common() net: hns3: remove the rss_size limitation by vector num Yufeng Mo (1): net: hns3: optimize the process of queue reset Yunsheng Lin (3): net: hns3: add handling for xmit skb with recursive fraglist net: hns3: add tx send size handling for tso skb net: hns3: add stats logging when skb padding fails drivers/net/ethernet/hisilicon/hns3/hnae3.h | 2 +- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 153 +++++++++----- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 9 +- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 2 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 8 +- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 219 ++++++++++++--------- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 3 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 26 ++- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 9 - .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 7 +- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 62 ++++-- 11 files changed, 321 insertions(+), 179 deletions(-) -- 2.7.4

2 10

[PATCH v2] coresight: core: Fix typo in coresight-core.c
by Qi Liu 28 Mar '21

28 Mar '21

Fix the following checkpatch warning: WARNING: 'compoment' may be misspelled - perhaps 'component'? Fixes: 8e264c52e1da ("coresight: core: Allow the coresight core driver to be built as a module") Signed-off-by: Qi Liu <liuqi115(a)huawei.com> --- drivers/hwtracing/coresight/coresight-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c index 0062c89..b57bea1 100644 --- a/drivers/hwtracing/coresight/coresight-core.c +++ b/drivers/hwtracing/coresight/coresight-core.c @@ -86,7 +86,7 @@ static int coresight_id_match(struct device *dev, void *data) i_csdev->type != CORESIGHT_DEV_TYPE_SOURCE) return 0; - /* Get the source ID for both compoment */ + /* Get the source ID for both components */ trace_id = source_ops(csdev)->trace_id(csdev); i_trace_id = source_ops(i_csdev)->trace_id(i_csdev); -- 2.8.1

2 2

[PATCH 00/15] acpi: fix some coding style issues
by Xiaofei Tan 27 Mar '21

27 Mar '21

Fix some coding style issues reported by checkpatch.pl. Xiaofei Tan (15): ACPI: APD: fix a block comment align issue ACPI: processor: fix some coding style issues ACPI: acpi_dbg: fix some coding style issues ACPI: acpi_fpdt: replace __attribute__((packed)) by __packed remove useless return statement for void function ACPI: acpi_lpss: fix some coding style issues ACPI: acpi_memhotplug: fix a coding style issue ACPI: acpi_pad: fix a coding style issue ACPI: battery: fix some coding style issues ACPI: button: fix some coding style issues ACPI: cppc_acpi: fix some coding style issues ACPI: custom_method: fix a coding style issue ACPI: device_pm: fix some coding style issues ACPI: device_sysfs: fix some coding style issues ACPI: dock: fix some coding style issues drivers/acpi/acpi_apd.c | 8 ++--- drivers/acpi/acpi_dbg.c | 40 +++++++++++------------- drivers/acpi/acpi_fpdt.c | 6 ++-- drivers/acpi/acpi_ipmi.c | 1 - drivers/acpi/acpi_lpss.c | 4 ++- drivers/acpi/acpi_memhotplug.c | 2 +- drivers/acpi/acpi_pad.c | 4 +++ drivers/acpi/acpi_processor.c | 18 +++-------- drivers/acpi/battery.c | 64 +++++++++++++++++++++---------------- drivers/acpi/button.c | 10 +++--- drivers/acpi/cppc_acpi.c | 71 +++++++++++++++++++++--------------------- drivers/acpi/custom_method.c | 2 +- drivers/acpi/device_pm.c | 3 ++ drivers/acpi/device_sysfs.c | 15 ++++++--- drivers/acpi/dock.c | 7 +++-- 15 files changed, 138 insertions(+), 117 deletions(-) -- 2.8.1

3 19

[PATCH] sched/fair: Remove the redundant check in numa_id_core
by Tian Tao 27 Mar '21

27 Mar '21

the numa_idle_core() function have a little redundant. then this patch move the "idle_core >= 0" check in numa_idle_core() to its caller in update_numa_stats() and then remove the redundant check in !static_branch_likely(&sched_smt_present) check in numa_idle_core. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- kernel/sched/fair.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index afb895a3..bae974a 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1569,8 +1569,7 @@ numa_type numa_classify(unsigned int imbalance_pct, static inline bool test_idle_cores(int cpu, bool def); static inline int numa_idle_core(int idle_core, int cpu) { - if (!static_branch_likely(&sched_smt_present) || - idle_core >= 0 || !test_idle_cores(cpu, false)) + if (!test_idle_cores(cpu, false)) return idle_core; /* @@ -1622,7 +1621,8 @@ static void update_numa_stats(struct task_numa_env *env, if (ns->idle_cpu == -1) ns->idle_cpu = cpu; - idle_core = numa_idle_core(idle_core, cpu); + if (idle_core >= 0) + idle_core = numa_idle_core(idle_core, cpu); } } rcu_read_unlock(); -- 2.7.4

2 1

[PATCH for-next 0/5] RDMA/hns: Refactor and reorganization
by Weihang Li 27 Mar '21

27 Mar '21

Refactor the process of polling CQ and several control paths in the hns driver. Weihang Li (1): RDMA/hns: Refactor hns_roce_v2_poll_one() Xi Wang (3): RDMA/hns: Refactor reset state checking flow RDMA/hns: Reorganize process of setting HEM RDMA/hns: Simplify command fields for HEM base address configuration Yixing Liu (1): RDMA/hns: Reorganize hns_roce_create_cq() drivers/infiniband/hw/hns/hns_roce_cmd.c | 35 +- drivers/infiniband/hw/hns/hns_roce_cq.c | 87 ++- drivers/infiniband/hw/hns/hns_roce_device.h | 11 +- drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 2 +- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 971 +++++++++++++++------------- drivers/infiniband/hw/hns/hns_roce_hw_v2.h | 116 ++-- 6 files changed, 626 insertions(+), 596 deletions(-) -- 2.8.1

3 9

[PATCH net-next 0/9] net: hns3: add some cleanups
by Huazhong Tan 27 Mar '21

27 Mar '21

This series includes some cleanups for the HNS3 ethernet driver. Guojia Liao (1): net: hns3: split out hclge_tm_vport_tc_info_update() Huazhong Tan (3): net: hns3: remove unused parameter from hclge_dbg_dump_loopback() net: hns3: fix prototype warning net: hns3: fix some typos in hclge_main.c Jian Shen (1): net: hns3: remove unused code of vmdq Jiaran Zhang (1): net: hns3: remove redundant query in hclge_config_tm_hw_err_int() Peng Li (2): net: hns3: remove redundant blank lines net: hns3: remove unused parameter from hclge_set_vf_vlan_common() Yufeng Mo (1): net: hns3: split function hclge_reset_rebuild() drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 7 - drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 2 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 1 - .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 2 - .../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 5 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 10 +- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 283 +++++++++------------ .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 2 - .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 11 +- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 1 - .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 2 - .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 1 - 12 files changed, 130 insertions(+), 197 deletions(-) -- 2.7.4

2 10

[PATCH for-next] RDMA/hns: Support to query firmware version
by Weihang Li 26 Mar '21

26 Mar '21

From: Lang Cheng <chenglang(a)huawei.com> Implement the ops named get_dev_fw_str to support ib_get_device_fw_str(). Signed-off-by: Lang Cheng <chenglang(a)huawei.com> Signed-off-by: Weihang Li <liweihang(a)huawei.com> --- drivers/infiniband/hw/hns/hns_roce_main.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c index 1a747f7..2b9e501 100644 --- a/drivers/infiniband/hw/hns/hns_roce_main.c +++ b/drivers/infiniband/hw/hns/hns_roce_main.c @@ -394,6 +394,19 @@ static void hns_roce_disassociate_ucontext(struct ib_ucontext *ibcontext) { } +static void hns_roce_get_fw_ver(struct ib_device *device, char *str) +{ + u64 fw_ver = to_hr_dev(device)->caps.fw_ver; + unsigned int major, minor, sub_minor; + + major = upper_32_bits(fw_ver); + minor = high_16_bits(lower_32_bits(fw_ver)); + sub_minor = low_16_bits(fw_ver); + + snprintf(str, IB_FW_VERSION_NAME_MAX, "%u.%u.%04u", major, minor, + sub_minor); +} + static void hns_roce_unregister_device(struct hns_roce_dev *hr_dev) { struct hns_roce_ib_iboe *iboe = &hr_dev->iboe; @@ -409,6 +422,7 @@ static const struct ib_device_ops hns_roce_dev_ops = { .uverbs_abi_ver = 1, .uverbs_no_driver_id_binding = 1, + .get_dev_fw_str = hns_roce_get_fw_ver, .add_gid = hns_roce_add_gid, .alloc_pd = hns_roce_alloc_pd, .alloc_ucontext = hns_roce_alloc_ucontext, -- 2.8.1

3 2

[PATCH v2 0/4] Fix the parameter of dma_map_sg()
by chenxiang 26 Mar '21

26 Mar '21

From: Xiang Chen <chenxiang66(a)hisilicon.com> According to Documentation/core-api/dma-api-howto.rst, the parameters of dma_unmap_sg() must be the same as those which are passed in to the scatter/gather mapping API. But for some drivers under crypto, the <nents> parameter of dma_unmap_sg() is number of elements after mapping. So fix them. Part of the document is as follows: To unmap a scatterlist, just call:: dma_unmap_sg(dev, sglist, nents, direction); Again, make sure DMA activity has already finished. .. note:: The 'nents' argument to the dma_unmap_sg call must be the _same_ one you passed into the dma_map_sg call, it should _NOT_ be the 'count' value _returned_ from the dma_map_sg call. Change Log: v1 -> v2: Remove changing the count passed to create_sg_component in driver cavium; Xiang Chen (4): crypto: amlogic - Fix the parameter of dma_unmap_sg() crypto: cavium - Fix the parameter of dma_unmap_sg() crypto: ux500 - Fix the parameter of dma_unmap_sg() crypto: allwinner - Fix the parameter of dma_unmap_sg() drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c | 9 ++++++--- drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c | 3 ++- drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c | 9 ++++++--- drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c | 3 ++- drivers/crypto/amlogic/amlogic-gxl-cipher.c | 6 +++--- drivers/crypto/cavium/nitrox/nitrox_reqmgr.c | 9 +++++---- drivers/crypto/ux500/cryp/cryp_core.c | 4 ++-- drivers/crypto/ux500/hash/hash_core.c | 2 +- 8 files changed, 27 insertions(+), 18 deletions(-) -- 2.8.1

2 5

[PATCH v5 0/2] add IRQF_NO_AUTOEN for request_irq
by Barry Song 26 Mar '21

26 Mar '21

-v5: * add the same check for IRQF_NO_AUTOEN in request_nmi() * combine a dozen of separate patches of input into one (hopefully this could easy the life of the maintainers) -v4: * remove the irq_settings magic for NOAUTOEN with respect to Thomas's comment Barry Song (2): genirq: add IRQF_NO_AUTOEN for request_irq Input: move to use request_irq by IRQF_NO_AUTOEN flag drivers/input/keyboard/tca6416-keypad.c | 3 +-- drivers/input/keyboard/tegra-kbc.c | 5 ++--- drivers/input/touchscreen/ar1021_i2c.c | 5 +---- drivers/input/touchscreen/atmel_mxt_ts.c | 5 ++--- drivers/input/touchscreen/bu21029_ts.c | 4 ++-- drivers/input/touchscreen/cyttsp_core.c | 5 ++--- drivers/input/touchscreen/melfas_mip4.c | 5 ++--- drivers/input/touchscreen/mms114.c | 4 ++-- drivers/input/touchscreen/stmfts.c | 3 +-- drivers/input/touchscreen/wm831x-ts.c | 3 +-- drivers/input/touchscreen/zinitix.c | 4 ++-- include/linux/interrupt.h | 4 ++++ kernel/irq/manage.c | 11 +++++++++-- 13 files changed, 31 insertions(+), 30 deletions(-) -- 2.25.1

2 3

[PATCH v2 0/3] drivers/perf: convert sysfs sprintf/snprintf/scnprintf to sysfs_emit
by Qi Liu 25 Mar '21

25 Mar '21

Use the generic sysfs_emit() and sysfs_emit_at() function to take place of sprintf/snprintf/scnprintf, to avoid buffer overrun. Qi Liu (2): drivers/perf: convert sysfs scnprintf family to sysfs_emit_at() and sysfs_emit() drivers/perf: convert sysfs sprintf family to sysfs_emit Zihao Tang (1): drivers/perf: convert sysfs snprintf family to sysfs_emit drivers/perf/arm-cci.c | 12 ++++++------ drivers/perf/arm-ccn.c | 31 +++++++++++++------------------ drivers/perf/arm-cmn.c | 22 +++++++++++----------- drivers/perf/arm_dmc620_pmu.c | 2 +- drivers/perf/arm_dsu_pmu.c | 5 ++--- drivers/perf/arm_smmuv3_pmu.c | 4 ++-- drivers/perf/arm_spe_pmu.c | 3 +-- drivers/perf/fsl_imx8_ddr_perf.c | 7 +++---- drivers/perf/hisilicon/hisi_uncore_pmu.c | 8 ++++---- drivers/perf/qcom_l2_pmu.c | 2 +- drivers/perf/qcom_l3_pmu.c | 4 ++-- drivers/perf/thunderx2_pmu.c | 4 ++-- drivers/perf/xgene_pmu.c | 4 ++-- 13 files changed, 50 insertions(+), 58 deletions(-) -- 2.8.1

2 4

[PATCH] drivers/perf: Simplify the SMMUv3 PMU event attributes
by Qi Liu 25 Mar '21

25 Mar '21

For each PMU event, there is a SMMU_EVENT_ATTR(xx, XX) and &smmu_event_attr_xx.attr.attr. Let's redefine the SMMU_EVENT_ATTR to simplify the smmu_pmu_events. Signed-off-by: Qi Liu <liuqi115(a)huawei.com> --- drivers/perf/arm_smmuv3_pmu.c | 32 +++++++++++++------------------- 1 file changed, 13 insertions(+), 19 deletions(-) diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c index 8ff7a67..4c8cb1b 100644 --- a/drivers/perf/arm_smmuv3_pmu.c +++ b/drivers/perf/arm_smmuv3_pmu.c @@ -509,27 +509,21 @@ static ssize_t smmu_pmu_event_show(struct device *dev, return sprintf(page, "event=0x%02llx\n", pmu_attr->id); } -#define SMMU_EVENT_ATTR(name, config) \ - PMU_EVENT_ATTR(name, smmu_event_attr_##name, \ - config, smmu_pmu_event_show) -SMMU_EVENT_ATTR(cycles, 0); -SMMU_EVENT_ATTR(transaction, 1); -SMMU_EVENT_ATTR(tlb_miss, 2); -SMMU_EVENT_ATTR(config_cache_miss, 3); -SMMU_EVENT_ATTR(trans_table_walk_access, 4); -SMMU_EVENT_ATTR(config_struct_access, 5); -SMMU_EVENT_ATTR(pcie_ats_trans_rq, 6); -SMMU_EVENT_ATTR(pcie_ats_trans_passed, 7); +#define SMMU_EVENT_ATTR(name, config) \ + (&((struct perf_pmu_events_attr) { \ + .attr = __ATTR(name, 0444, smmu_pmu_event_show, NULL), \ + .id = config, \ + }).attr.attr) static struct attribute *smmu_pmu_events[] = { - &smmu_event_attr_cycles.attr.attr, - &smmu_event_attr_transaction.attr.attr, - &smmu_event_attr_tlb_miss.attr.attr, - &smmu_event_attr_config_cache_miss.attr.attr, - &smmu_event_attr_trans_table_walk_access.attr.attr, - &smmu_event_attr_config_struct_access.attr.attr, - &smmu_event_attr_pcie_ats_trans_rq.attr.attr, - &smmu_event_attr_pcie_ats_trans_passed.attr.attr, + SMMU_EVENT_ATTR(cycles, 0), + SMMU_EVENT_ATTR(transaction, 1), + SMMU_EVENT_ATTR(tlb_miss, 2), + SMMU_EVENT_ATTR(config_cache_miss, 3), + SMMU_EVENT_ATTR(trans_table_walk_access, 4), + SMMU_EVENT_ATTR(config_struct_access, 5), + SMMU_EVENT_ATTR(pcie_ats_trans_rq, 6), + SMMU_EVENT_ATTR(pcie_ats_trans_passed, 7), NULL }; -- 2.8.1

2 1

[PATCH] nvme: use octal permissions '0444', '0200' and '0644'
by Meng Yu 25 Mar '21

25 Mar '21

Fixed following checkpatch warnings: 1. Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'; 2. Symbolic permissions 'S_IWUSR' are not preferred. Consider using octal permissions '0200'; 3. Symbolic permissions 'S_IRUGO | S_IWUSR' are not preferred. Consider using octal permissions '0644'; 4. And coding style fix. Signed-off-by: Meng Yu <yumeng18(a)huawei.com> --- drivers/nvme/host/core.c | 30 +++++++++++++++--------------- drivers/nvme/host/lightnvm.c | 6 +++--- drivers/nvme/host/multipath.c | 6 +++--- drivers/nvme/host/pci.c | 4 ++-- 4 files changed, 23 insertions(+), 23 deletions(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index c2c5bc4..46dadfb 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2578,7 +2578,7 @@ static void nvme_init_subnqn(struct nvme_subsystem *subsys, struct nvme_ctrl *ct size_t nqnlen; int off; - if(!(ctrl->quirks & NVME_QUIRK_IGNORE_DEV_SUBNQN)) { + if (!(ctrl->quirks & NVME_QUIRK_IGNORE_DEV_SUBNQN)) { nqnlen = strnlen(id->subnqn, NVMF_NQN_SIZE); if (nqnlen > 0 && nqnlen < NVMF_NQN_SIZE) { strlcpy(subsys->subnqn, id->subnqn, NVMF_NQN_SIZE); @@ -2670,7 +2670,7 @@ static ssize_t nvme_subsys_show_nqn(struct device *dev, return snprintf(buf, PAGE_SIZE, "%s\n", subsys->subnqn); } -static SUBSYS_ATTR_RO(subsysnqn, S_IRUGO, nvme_subsys_show_nqn); +static SUBSYS_ATTR_RO(subsysnqn, 0444, nvme_subsys_show_nqn); #define nvme_subsys_show_str_function(field) \ static ssize_t subsys_##field##_show(struct device *dev, \ @@ -2681,7 +2681,7 @@ static ssize_t subsys_##field##_show(struct device *dev, \ return sprintf(buf, "%.*s\n", \ (int)sizeof(subsys->field), subsys->field); \ } \ -static SUBSYS_ATTR_RO(field, S_IRUGO, subsys_##field##_show); +static SUBSYS_ATTR_RO(field, 0444, subsys_##field##_show); nvme_subsys_show_str_function(model); nvme_subsys_show_str_function(serial); @@ -3014,7 +3014,7 @@ int nvme_init_identify(struct nvme_ctrl *ctrl) ret = nvme_configure_apst(ctrl); if (ret < 0) return ret; - + ret = nvme_configure_timestamp(ctrl); if (ret < 0) return ret; @@ -3134,7 +3134,7 @@ static ssize_t nvme_sysfs_reset(struct device *dev, return ret; return count; } -static DEVICE_ATTR(reset_controller, S_IWUSR, NULL, nvme_sysfs_reset); +static DEVICE_ATTR(reset_controller, 0200, NULL, nvme_sysfs_reset); static ssize_t nvme_sysfs_rescan(struct device *dev, struct device_attribute *attr, const char *buf, @@ -3145,7 +3145,7 @@ static ssize_t nvme_sysfs_rescan(struct device *dev, nvme_queue_scan(ctrl); return count; } -static DEVICE_ATTR(rescan_controller, S_IWUSR, NULL, nvme_sysfs_rescan); +static DEVICE_ATTR(rescan_controller, 0200, NULL, nvme_sysfs_rescan); static inline struct nvme_ns_head *dev_to_ns_head(struct device *dev) { @@ -3290,7 +3290,7 @@ static ssize_t field##_show(struct device *dev, \ return sprintf(buf, "%.*s\n", \ (int)sizeof(ctrl->subsys->field), ctrl->subsys->field); \ } \ -static DEVICE_ATTR(field, S_IRUGO, field##_show, NULL); +static DEVICE_ATTR(field, 0444, field##_show, NULL); nvme_show_str_function(model); nvme_show_str_function(serial); @@ -3303,7 +3303,7 @@ static ssize_t field##_show(struct device *dev, \ struct nvme_ctrl *ctrl = dev_get_drvdata(dev); \ return sprintf(buf, "%d\n", ctrl->field); \ } \ -static DEVICE_ATTR(field, S_IRUGO, field##_show, NULL); +static DEVICE_ATTR(field, 0444, field##_show, NULL); nvme_show_int_function(cntlid); nvme_show_int_function(numa_node); @@ -3324,7 +3324,7 @@ static ssize_t nvme_sysfs_delete(struct device *dev, nvme_delete_ctrl_sync(ctrl); return count; } -static DEVICE_ATTR(delete_controller, S_IWUSR, NULL, nvme_sysfs_delete); +static DEVICE_ATTR(delete_controller, 0200, NULL, nvme_sysfs_delete); static ssize_t nvme_sysfs_show_transport(struct device *dev, struct device_attribute *attr, @@ -3334,7 +3334,7 @@ static ssize_t nvme_sysfs_show_transport(struct device *dev, return snprintf(buf, PAGE_SIZE, "%s\n", ctrl->ops->name); } -static DEVICE_ATTR(transport, S_IRUGO, nvme_sysfs_show_transport, NULL); +static DEVICE_ATTR(transport, 0444, nvme_sysfs_show_transport, NULL); static ssize_t nvme_sysfs_show_state(struct device *dev, struct device_attribute *attr, @@ -3357,7 +3357,7 @@ static ssize_t nvme_sysfs_show_state(struct device *dev, return sprintf(buf, "unknown state\n"); } -static DEVICE_ATTR(state, S_IRUGO, nvme_sysfs_show_state, NULL); +static DEVICE_ATTR(state, 0444, nvme_sysfs_show_state, NULL); static ssize_t nvme_sysfs_show_subsysnqn(struct device *dev, struct device_attribute *attr, @@ -3367,7 +3367,7 @@ static ssize_t nvme_sysfs_show_subsysnqn(struct device *dev, return snprintf(buf, PAGE_SIZE, "%s\n", ctrl->subsys->subnqn); } -static DEVICE_ATTR(subsysnqn, S_IRUGO, nvme_sysfs_show_subsysnqn, NULL); +static DEVICE_ATTR(subsysnqn, 0444, nvme_sysfs_show_subsysnqn, NULL); static ssize_t nvme_sysfs_show_hostnqn(struct device *dev, struct device_attribute *attr, @@ -3377,7 +3377,7 @@ static ssize_t nvme_sysfs_show_hostnqn(struct device *dev, return snprintf(buf, PAGE_SIZE, "%s\n", ctrl->opts->host->nqn); } -static DEVICE_ATTR(hostnqn, S_IRUGO, nvme_sysfs_show_hostnqn, NULL); +static DEVICE_ATTR(hostnqn, 0444, nvme_sysfs_show_hostnqn, NULL); static ssize_t nvme_sysfs_show_hostid(struct device *dev, struct device_attribute *attr, @@ -3387,7 +3387,7 @@ static ssize_t nvme_sysfs_show_hostid(struct device *dev, return snprintf(buf, PAGE_SIZE, "%pU\n", &ctrl->opts->host->id); } -static DEVICE_ATTR(hostid, S_IRUGO, nvme_sysfs_show_hostid, NULL); +static DEVICE_ATTR(hostid, 0444, nvme_sysfs_show_hostid, NULL); static ssize_t nvme_sysfs_show_address(struct device *dev, struct device_attribute *attr, @@ -3397,7 +3397,7 @@ static ssize_t nvme_sysfs_show_address(struct device *dev, return ctrl->ops->get_address(ctrl, buf, PAGE_SIZE); } -static DEVICE_ATTR(address, S_IRUGO, nvme_sysfs_show_address, NULL); +static DEVICE_ATTR(address, 0444, nvme_sysfs_show_address, NULL); static struct attribute *nvme_dev_attrs[] = { &dev_attr_reset_controller.attr, diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c index 6960875..2c7b99f 100644 --- a/drivers/nvme/host/lightnvm.c +++ b/drivers/nvme/host/lightnvm.c @@ -1138,11 +1138,11 @@ static ssize_t nvm_dev_attr_show_20(struct device *dev, } #define NVM_DEV_ATTR_RO(_name) \ - DEVICE_ATTR(_name, S_IRUGO, nvm_dev_attr_show, NULL) + DEVICE_ATTR(_name, 0444, nvm_dev_attr_show, NULL) #define NVM_DEV_ATTR_12_RO(_name) \ - DEVICE_ATTR(_name, S_IRUGO, nvm_dev_attr_show_12, NULL) + DEVICE_ATTR(_name, 0444, nvm_dev_attr_show_12, NULL) #define NVM_DEV_ATTR_20_RO(_name) \ - DEVICE_ATTR(_name, S_IRUGO, nvm_dev_attr_show_20, NULL) + DEVICE_ATTR(_name, 0444, nvm_dev_attr_show_20, NULL) /* general attributes */ static NVM_DEV_ATTR_RO(version); diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c index da78e49..deab995 100644 --- a/drivers/nvme/host/multipath.c +++ b/drivers/nvme/host/multipath.c @@ -621,8 +621,8 @@ static ssize_t nvme_subsys_iopolicy_store(struct device *dev, return -EINVAL; } -SUBSYS_ATTR_RW(iopolicy, S_IRUGO | S_IWUSR, - nvme_subsys_iopolicy_show, nvme_subsys_iopolicy_store); +SUBSYS_ATTR_RW(iopolicy, 0644, nvme_subsys_iopolicy_show, + nvme_subsys_iopolicy_store); static ssize_t ana_grpid_show(struct device *dev, struct device_attribute *attr, char *buf) @@ -662,7 +662,7 @@ void nvme_mpath_add_disk(struct nvme_ns *ns, struct nvme_id_ns *id) mutex_unlock(&ns->ctrl->ana_lock); } else { mutex_lock(&ns->head->lock); - ns->ana_state = NVME_ANA_OPTIMIZED; + ns->ana_state = NVME_ANA_OPTIMIZED; nvme_mpath_set_live(ns); mutex_unlock(&ns->head->lock); } diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index e2bacd3..47ee949 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -1739,7 +1739,7 @@ static ssize_t nvme_cmb_show(struct device *dev, return scnprintf(buf, PAGE_SIZE, "cmbloc : x%08x\ncmbsz : x%08x\n", ndev->cmbloc, ndev->cmbsz); } -static DEVICE_ATTR(cmb, S_IRUGO, nvme_cmb_show, NULL); +static DEVICE_ATTR(cmb, 0444, nvme_cmb_show, NULL); static u64 nvme_cmb_size_unit(struct nvme_dev *dev) { @@ -2108,7 +2108,7 @@ static int nvme_setup_io_queues(struct nvme_dev *dev) if (nr_io_queues == 0) return 0; - + clear_bit(NVMEQ_ENABLED, &adminq->flags); if (dev->cmb_use_sqes) { -- 2.8.1

1 0

[PATCH] nvme: use octal permissions '0444' and '0644'
by yumeng 25 Mar '21

25 Mar '21

-------- 转发的消息 -------- 主题: [PATCH] nvme: use octal permissions '0444' and '0644' 日期: Thu, 25 Mar 2021 11:45:45 +0800 From: Meng Yu <yumeng18(a)huawei.com> 收件人: xuzaibo(a)huawei.com, wangzhou1(a)hisilicon.com, fanghao11(a)huawei.com, yekai13(a)huawei.com, qianweili(a)huawei.com, shenyang39(a)huawei.com, tanghui20(a)huawei.com, liulongfang(a)huawei.com, chensihang1(a)hisilicon.com, yumeng18(a)huawei.com, songzhiqi1(a)huawei.com Fixed following checkpatch warnings: 1. Symbolic permissions 'S_IRUGO | S_IWUSR' are not preferred. Consider using octal permissions '0644'; 2. Symbolic permissions 'S_IRUGO | S_IWUSR' are not preferred. Consider using octal permissions '0644'. Signed-off-by: Meng Yu <yumeng18(a)huawei.com> --- drivers/nvme/host/core.c | 30 +++++++++++++++--------------- drivers/nvme/host/lightnvm.c | 6 +++--- drivers/nvme/host/multipath.c | 6 +++--- drivers/nvme/host/pci.c | 4 ++-- 4 files changed, 23 insertions(+), 23 deletions(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index e68a8c4..aec94d2 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2867,7 +2867,7 @@ static ssize_t nvme_subsys_show_nqn(struct device *dev, return sysfs_emit(buf, "%s\n", subsys->subnqn); } -static SUBSYS_ATTR_RO(subsysnqn, S_IRUGO, nvme_subsys_show_nqn); +static SUBSYS_ATTR_RO(subsysnqn, 0444, nvme_subsys_show_nqn); #define nvme_subsys_show_str_function(field) \ static ssize_t subsys_##field##_show(struct device *dev, \ @@ -2878,7 +2878,7 @@ static ssize_t subsys_##field##_show(struct device *dev, \ return sprintf(buf, "%.*s\n", \ (int)sizeof(subsys->field), subsys->field); \ } \ -static SUBSYS_ATTR_RO(field, S_IRUGO, subsys_##field##_show); +static SUBSYS_ATTR_RO(field, 0444, subsys_##field##_show); nvme_subsys_show_str_function(model); nvme_subsys_show_str_function(serial); @@ -3224,7 +3224,7 @@ int nvme_init_identify(struct nvme_ctrl *ctrl) ret = nvme_configure_apst(ctrl); if (ret < 0) return ret; - + ret = nvme_configure_timestamp(ctrl); if (ret < 0) return ret; @@ -3520,7 +3520,7 @@ static ssize_t field##_show(struct device *dev, \ return sprintf(buf, "%.*s\n", \ (int)sizeof(ctrl->subsys->field), ctrl->subsys->field); \ } \ -static DEVICE_ATTR(field, S_IRUGO, field##_show, NULL); +static DEVICE_ATTR(field, 0444, field##_show, NULL); nvme_show_str_function(model); nvme_show_str_function(serial); @@ -3533,7 +3533,7 @@ static ssize_t field##_show(struct device *dev, \ struct nvme_ctrl *ctrl = dev_get_drvdata(dev); \ return sprintf(buf, "%d\n", ctrl->field); \ } \ -static DEVICE_ATTR(field, S_IRUGO, field##_show, NULL); +static DEVICE_ATTR(field, 0444, field##_show, NULL); nvme_show_int_function(cntlid); nvme_show_int_function(numa_node); @@ -3560,7 +3560,7 @@ static ssize_t nvme_sysfs_show_transport(struct device *dev, return sysfs_emit(buf, "%s\n", ctrl->ops->name); } -static DEVICE_ATTR(transport, S_IRUGO, nvme_sysfs_show_transport, NULL); +static DEVICE_ATTR(transport, 0444, nvme_sysfs_show_transport, NULL); static ssize_t nvme_sysfs_show_state(struct device *dev, struct device_attribute *attr, @@ -3584,7 +3584,7 @@ static ssize_t nvme_sysfs_show_state(struct device *dev, return sprintf(buf, "unknown state\n"); } -static DEVICE_ATTR(state, S_IRUGO, nvme_sysfs_show_state, NULL); +static DEVICE_ATTR(state, 0444, nvme_sysfs_show_state, NULL); static ssize_t nvme_sysfs_show_subsysnqn(struct device *dev, struct device_attribute *attr, @@ -3594,7 +3594,7 @@ static ssize_t nvme_sysfs_show_subsysnqn(struct device *dev, return sysfs_emit(buf, "%s\n", ctrl->subsys->subnqn); } -static DEVICE_ATTR(subsysnqn, S_IRUGO, nvme_sysfs_show_subsysnqn, NULL); +static DEVICE_ATTR(subsysnqn, 0444, nvme_sysfs_show_subsysnqn, NULL); static ssize_t nvme_sysfs_show_hostnqn(struct device *dev, struct device_attribute *attr, @@ -3604,7 +3604,7 @@ static ssize_t nvme_sysfs_show_hostnqn(struct device *dev, return sysfs_emit(buf, "%s\n", ctrl->opts->host->nqn); } -static DEVICE_ATTR(hostnqn, S_IRUGO, nvme_sysfs_show_hostnqn, NULL); +static DEVICE_ATTR(hostnqn, 0444, nvme_sysfs_show_hostnqn, NULL); static ssize_t nvme_sysfs_show_hostid(struct device *dev, struct device_attribute *attr, @@ -3614,7 +3614,7 @@ static ssize_t nvme_sysfs_show_hostid(struct device *dev, return sysfs_emit(buf, "%pU\n", &ctrl->opts->host->id); } -static DEVICE_ATTR(hostid, S_IRUGO, nvme_sysfs_show_hostid, NULL); +static DEVICE_ATTR(hostid, 0444, nvme_sysfs_show_hostid, NULL); static ssize_t nvme_sysfs_show_address(struct device *dev, struct device_attribute *attr, @@ -3624,7 +3624,7 @@ static ssize_t nvme_sysfs_show_address(struct device *dev, return ctrl->ops->get_address(ctrl, buf, PAGE_SIZE); } -static DEVICE_ATTR(address, S_IRUGO, nvme_sysfs_show_address, NULL); +static DEVICE_ATTR(address, 0444, nvme_sysfs_show_address, NULL); static ssize_t nvme_ctrl_loss_tmo_show(struct device *dev, struct device_attribute *attr, char *buf) @@ -3656,8 +3656,8 @@ static ssize_t nvme_ctrl_loss_tmo_store(struct device *dev, opts->reconnect_delay); return count; } -static DEVICE_ATTR(ctrl_loss_tmo, S_IRUGO | S_IWUSR, - nvme_ctrl_loss_tmo_show, nvme_ctrl_loss_tmo_store); +static DEVICE_ATTR(ctrl_loss_tmo, 0644, nvme_ctrl_loss_tmo_show, + nvme_ctrl_loss_tmo_store); static ssize_t nvme_ctrl_reconnect_delay_show(struct device *dev, struct device_attribute *attr, char *buf) @@ -3683,8 +3683,8 @@ static ssize_t nvme_ctrl_reconnect_delay_store(struct device *dev, ctrl->opts->reconnect_delay = v; return count; } -static DEVICE_ATTR(reconnect_delay, S_IRUGO | S_IWUSR, - nvme_ctrl_reconnect_delay_show, nvme_ctrl_reconnect_delay_store); +static DEVICE_ATTR(reconnect_delay, 0644, nvme_ctrl_reconnect_delay_show, + nvme_ctrl_reconnect_delay_store); static struct attribute *nvme_dev_attrs[] = { &dev_attr_reset_controller.attr, diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c index b705988..ec25565 100644 --- a/drivers/nvme/host/lightnvm.c +++ b/drivers/nvme/host/lightnvm.c @@ -1137,11 +1137,11 @@ static ssize_t nvm_dev_attr_show_20(struct device *dev, } #define NVM_DEV_ATTR_RO(_name) \ - DEVICE_ATTR(_name, S_IRUGO, nvm_dev_attr_show, NULL) + DEVICE_ATTR(_name, 0444, nvm_dev_attr_show, NULL) #define NVM_DEV_ATTR_12_RO(_name) \ - DEVICE_ATTR(_name, S_IRUGO, nvm_dev_attr_show_12, NULL) + DEVICE_ATTR(_name, 0444, nvm_dev_attr_show_12, NULL) #define NVM_DEV_ATTR_20_RO(_name) \ - DEVICE_ATTR(_name, S_IRUGO, nvm_dev_attr_show_20, NULL) + DEVICE_ATTR(_name, 0444, nvm_dev_attr_show_20, NULL) /* general attributes */ static NVM_DEV_ATTR_RO(version); diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c index a1d476e..216604f 100644 --- a/drivers/nvme/host/multipath.c +++ b/drivers/nvme/host/multipath.c @@ -622,8 +622,8 @@ static ssize_t nvme_subsys_iopolicy_store(struct device *dev, return -EINVAL; } -SUBSYS_ATTR_RW(iopolicy, S_IRUGO | S_IWUSR, - nvme_subsys_iopolicy_show, nvme_subsys_iopolicy_store); +SUBSYS_ATTR_RW(iopolicy, 0644, nvme_subsys_iopolicy_show, + nvme_subsys_iopolicy_store); static ssize_t ana_grpid_show(struct device *dev, struct device_attribute *attr, char *buf) @@ -670,7 +670,7 @@ void nvme_mpath_add_disk(struct nvme_ns *ns, struct nvme_id_ns *id) nvme_update_ns_ana_state(&desc, ns); } } else { - ns->ana_state = NVME_ANA_OPTIMIZED; + ns->ana_state = NVME_ANA_OPTIMIZED; nvme_mpath_set_live(ns); } diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 17ab332..678eeba 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -1801,7 +1801,7 @@ static ssize_t nvme_cmb_show(struct device *dev, return scnprintf(buf, PAGE_SIZE, "cmbloc : x%08x\ncmbsz : x%08x\n", ndev->cmbloc, ndev->cmbsz); } -static DEVICE_ATTR(cmb, S_IRUGO, nvme_cmb_show, NULL); +static DEVICE_ATTR(cmb, 0444, nvme_cmb_show, NULL); static u64 nvme_cmb_size_unit(struct nvme_dev *dev) { @@ -2178,7 +2178,7 @@ static int nvme_setup_io_queues(struct nvme_dev *dev) if (nr_io_queues == 0) return 0; - + clear_bit(NVMEQ_ENABLED, &adminq->flags); if (dev->cmb_use_sqes) { -- 2.8.1 .

1 0

[PATCH v2] sched/topology: remove redundant cpumask_and in init_overlap_sched_group
by Barry Song 25 Mar '21

25 Mar '21

mask is built in build_balance_mask() by for_each_cpu(i, sg_span), so it must be a subset of sched_group_span(sg). Though cpumask_first_and doesn't lead to a wrong result of balance cpu, it is pointless to do cpumask_and again. Signed-off-by: Barry Song <song.bao.hua(a)hisilicon.com> Reviewed-by: Valentin Schneider <Valentin.Schneider(a)arm.com> --- -v2: add reviewed-by of Valentin, thanks! kernel/sched/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index f2066d682cd8..d1aec244c027 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -934,7 +934,7 @@ static void init_overlap_sched_group(struct sched_domain *sd, int cpu; build_balance_mask(sd, sg, mask); - cpu = cpumask_first_and(sched_group_span(sg), mask); + cpu = cpumask_first(mask); sg->sgc = *per_cpu_ptr(sdd->sgc, cpu); if (atomic_inc_return(&sg->sgc->ref) == 1) -- 2.25.1

1 0

[PATCH net v2] net: sched: fix packet stuck problem for lockless qdisc
by Yunsheng Lin 25 Mar '21

25 Mar '21

Lockless qdisc has below concurrent problem: cpu0 cpu1 . . q->enqueue . . . qdisc_run_begin() . . . dequeue_skb() . . . sch_direct_xmit() . . . . q->enqueue . qdisc_run_begin() . return and do nothing . . qdisc_run_end() . cpu1 enqueue a skb without calling __qdisc_run() because cpu0 has not released the lock yet and spin_trylock() return false for cpu1 in qdisc_run_begin(), and cpu0 do not see the skb enqueued by cpu1 when calling dequeue_skb() because cpu1 may enqueue the skb after cpu0 calling dequeue_skb() and before cpu0 calling qdisc_run_end(). Lockless qdisc has below another concurrent problem when tx_action is involved: cpu0(serving tx_action) cpu1 cpu2 . . . . q->enqueue . . qdisc_run_begin() . . dequeue_skb() . . . q->enqueue . . . . sch_direct_xmit() . . . qdisc_run_begin() . . return and do nothing . . . clear __QDISC_STATE_SCHED . . qdisc_run_begin() . . return and do nothing . . . . . . qdisc_run_end() . This patch fixes the above data race by: 1. Get the flag before doing spin_trylock(). 2. If the first spin_trylock() return false and the flag is not set before the first spin_trylock(), Set the flag and retry another spin_trylock() in case other CPU may not see the new flag after it releases the lock. 3. reschedule if the flags is set after the lock is released at the end of qdisc_run_end(). For tx_action case, the flags is also set when cpu1 is at the end if qdisc_run_end(), so tx_action will be rescheduled again to dequeue the skb enqueued by cpu2. Only clear the flag before retrying a dequeuing when dequeuing returns NULL in order to reduce the overhead of the above double spin_trylock() and __netif_schedule() calling. The performance impact of this patch, tested using pktgen and dummy netdev with pfifo_fast qdisc attached: threads without+this_patch with+this_patch delta 1 2.6Mpps 2.6Mpps +0.0% 2 3.9Mpps 3.8Mpps -2.5% 4 5.6Mpps 5.6Mpps -0.0% 8 2.7Mpps 2.8Mpps +3.7% 16 2.2Mpps 2.2Mpps +0.0% Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking") Signed-off-by: Yunsheng Lin <linyunsheng(a)huawei.com> --- V2: Avoid the overhead of fixing the data race as much as possible. --- include/net/sch_generic.h | 48 ++++++++++++++++++++++++++++++++++++++++++++++- net/sched/sch_generic.c | 12 ++++++++++++ 2 files changed, 59 insertions(+), 1 deletion(-) diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h index f7a6e14..09a755d 100644 --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h @@ -36,6 +36,7 @@ struct qdisc_rate_table { enum qdisc_state_t { __QDISC_STATE_SCHED, __QDISC_STATE_DEACTIVATED, + __QDISC_STATE_NEED_RESCHEDULE, }; struct qdisc_size_table { @@ -159,12 +160,42 @@ static inline bool qdisc_is_empty(const struct Qdisc *qdisc) static inline bool qdisc_run_begin(struct Qdisc *qdisc) { if (qdisc->flags & TCQ_F_NOLOCK) { + bool dont_retry = test_bit(__QDISC_STATE_NEED_RESCHEDULE, + &qdisc->state); + + if (spin_trylock(&qdisc->seqlock)) + goto out; + + /* If the flag is set before doing the spin_trylock() and + * the above spin_trylock() return false, it means other cpu + * holding the lock will do dequeuing for us, or it wil see + * the flag set after releasing lock and reschedule the + * net_tx_action() to do the dequeuing. + */ + if (dont_retry) + return false; + + /* We could do set_bit() before the first spin_trylock(), + * and avoid doing secord spin_trylock() completely, then + * we could have multi cpus doing the test_bit(). Here use + * dont_retry to avoiding the test_bit() and the second + * spin_trylock(), which has 5% performance improvement than + * doing the set_bit() before the first spin_trylock(). + */ + set_bit(__QDISC_STATE_NEED_RESCHEDULE, + &qdisc->state); + + /* Retry again in case other CPU may not see the new flag + * after it releases the lock at the end of qdisc_run_end(). + */ if (!spin_trylock(&qdisc->seqlock)) return false; WRITE_ONCE(qdisc->empty, false); } else if (qdisc_is_running(qdisc)) { return false; } + +out: /* Variant of write_seqcount_begin() telling lockdep a trylock * was attempted. */ @@ -176,8 +207,23 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) static inline void qdisc_run_end(struct Qdisc *qdisc) { write_seqcount_end(&qdisc->running); - if (qdisc->flags & TCQ_F_NOLOCK) + if (qdisc->flags & TCQ_F_NOLOCK) { spin_unlock(&qdisc->seqlock); + + /* qdisc_run_end() is protected by RCU lock, and + * qdisc reset will do a synchronize_net() after + * setting __QDISC_STATE_DEACTIVATED, so testing + * the below two bits separately should be fine. + * For qdisc_run() in net_tx_action() case, we + * really should provide rcu protection explicitly + * for document purposes or PREEMPT_RCU. + */ + if (unlikely(test_bit(__QDISC_STATE_NEED_RESCHEDULE, + &qdisc->state) && + !test_bit(__QDISC_STATE_DEACTIVATED, + &qdisc->state))) + __netif_schedule(qdisc); + } } static inline bool qdisc_may_bulk(const struct Qdisc *qdisc) diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c index 44991ea..7e3426b 100644 --- a/net/sched/sch_generic.c +++ b/net/sched/sch_generic.c @@ -640,8 +640,10 @@ static struct sk_buff *pfifo_fast_dequeue(struct Qdisc *qdisc) { struct pfifo_fast_priv *priv = qdisc_priv(qdisc); struct sk_buff *skb = NULL; + bool need_retry = true; int band; +retry: for (band = 0; band < PFIFO_FAST_BANDS && !skb; band++) { struct skb_array *q = band2list(priv, band); @@ -652,6 +654,16 @@ static struct sk_buff *pfifo_fast_dequeue(struct Qdisc *qdisc) } if (likely(skb)) { qdisc_update_stats_at_dequeue(qdisc, skb); + } else if (need_retry && + test_and_clear_bit(__QDISC_STATE_NEED_RESCHEDULE, + &qdisc->stat)) { + /* do another enqueuing after clearing the flag to + * avoid calling __netif_schedule(). + */ + smp_mb__after_atomic(); + need_retry = false; + + goto retry; } else { WRITE_ONCE(qdisc->empty, true); } -- 2.7.4

2 2

2024

2023

2022

2021

2020