| Message ID | 20181202230933.15560-4-salil.mehta@huawei.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | net: hns3: Add more commands to Debugfs in HNS3 driver | expand |
On Sun, 2 Dec 2018 23:09:27 +0000, Salil Mehta wrote: > From: liuzhongzhu <liuzhongzhu@huawei.com> > > This patch prints port vlan table information. > > debugfs command: > echo dump port vlan tbl > cmd > > Sample Command: > root@(none)# echo dump port vlan tbl > cmd > vlan | port filter bitMap: > 0000 | 00000000:00000000:00000000:00000000:00000000:00000001 > root@(none)# > > Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Adding debugfs files for basic switch concepts like MAC and VLAN tables seems like a bit of a stretch to me. I wonder what others think.
From: Jakub Kicinski <jakub.kicinski@netronome.com> Date: Mon, 3 Dec 2018 15:12:22 -0800 > On Sun, 2 Dec 2018 23:09:27 +0000, Salil Mehta wrote: >> From: liuzhongzhu <liuzhongzhu@huawei.com> >> >> This patch prints port vlan table information. >> >> debugfs command: >> echo dump port vlan tbl > cmd >> >> Sample Command: >> root@(none)# echo dump port vlan tbl > cmd >> vlan | port filter bitMap: >> 0000 | 00000000:00000000:00000000:00000000:00000000:00000001 >> root@(none)# >> >> Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> >> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> > > Adding debugfs files for basic switch concepts like MAC and VLAN tables > seems like a bit of a stretch to me. I wonder what others think. Agreed.
> From: David Miller [mailto:davem@davemloft.net] > Sent: Monday, December 3, 2018 11:13 PM > To: jakub.kicinski@netronome.com > Cc: Salil Mehta <salil.mehta@huawei.com>; Zhuangyuzeng (Yisen) > <yisen.zhuang@huawei.com>; lipeng (Y) <lipeng321@huawei.com>; > mehta.salil@opnsrc.net; netdev@vger.kernel.org; linux- > kernel@vger.kernel.org; Linuxarm <linuxarm@huawei.com>; Liuzhongzhu > <liuzhongzhu@huawei.com>; jiri@resnulli.us; f.fainelli@gmail.com > Subject: Re: [RFC net-next 3/9] net: hns3: Add "port vlan table" > information query function > > From: Jakub Kicinski <jakub.kicinski@netronome.com> > Date: Mon, 3 Dec 2018 15:12:22 -0800 > > > On Sun, 2 Dec 2018 23:09:27 +0000, Salil Mehta wrote: > >> From: liuzhongzhu <liuzhongzhu@huawei.com> > >> > >> This patch prints port vlan table information. > >> > >> debugfs command: > >> echo dump port vlan tbl > cmd > >> > >> Sample Command: > >> root@(none)# echo dump port vlan tbl > cmd > >> vlan | port filter bitMap: > >> 0000 | 00000000:00000000:00000000:00000000:00000000:00000001 > >> root@(none)# > >> > >> Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> > >> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> > > > > Adding debugfs files for basic switch concepts like MAC and VLAN tables > > seems like a bit of a stretch to me. I wonder what others think. > > Agreed. I was wondering how other vendors are solving this? One way I could understand is to use "Switchdev" framework which in turn will expose entries to the kernel using the switch driver. In our NIC we don't have a proper switch and it cannot learn/age entries. Also, on-SoC NIC contains other tables which might not have any standard user-space interface at all. What are your suggestions regarding that? Thanks Salil
> > > Adding debugfs files for basic switch concepts like MAC and VLAN tables > > > seems like a bit of a stretch to me. I wonder what others think. > > > > Agreed. > > > I was wondering how other vendors are solving this? One way I could > understand is to use "Switchdev" framework which in turn will expose > entries to the kernel using the switch driver. In our NIC we don't > have a proper switch and it cannot learn/age entries. Your hardware is there to accelerate what linux can do in software. How do we manage the software version of this feature? > Also, on-SoC NIC contains other tables which might not have any standard > user-space interface at all. What are your suggestions regarding that? How are these tables map to software features the Linux stack implements? Andrew
> From: Andrew Lunn [mailto:andrew@lunn.ch] > Sent: Tuesday, December 4, 2018 10:56 AM > To: Salil Mehta <salil.mehta@huawei.com> > Cc: David Miller <davem@davemloft.net>; jakub.kicinski@netronome.com; > Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>; lipeng (Y) > <lipeng321@huawei.com>; mehta.salil@opnsrc.net; netdev@vger.kernel.org; > linux-kernel@vger.kernel.org; Linuxarm <linuxarm@huawei.com>; > Liuzhongzhu <liuzhongzhu@huawei.com>; jiri@resnulli.us; > f.fainelli@gmail.com > Subject: Re: [RFC net-next 3/9] net: hns3: Add "port vlan table" > information query function > > > > > Adding debugfs files for basic switch concepts like MAC and VLAN tables > > > > seems like a bit of a stretch to me. I wonder what others think. > > > > > > Agreed. > > > > > > I was wondering how other vendors are solving this? One way I could > > understand is to use "Switchdev" framework which in turn will expose > > entries to the kernel using the switch driver. In our NIC we don't > > have a proper switch and it cannot learn/age entries. > > Your hardware is there to accelerate what linux can do in software. > How do we manage the software version of this feature? Yes, so it can kind of represent switch in the hardware, has vports and has tables for mac-vlan, port-vlan, vlan (which I guess kernel also supports in vlan aware mode of bridging?). Perhaps, only way I can understand now to be able to use standard bridge, ip link tools to fetch this info is by having represented them by "Switchdev"? > > > Also, on-SoC NIC contains other tables which might not have any standard > > user-space interface at all. What are your suggestions regarding that? > > How are these tables map to software features the Linux stack > implements? If you refer output shown in patch you will get an idea, [RFC net-next 5/9] net: hns3: Add "manager table" information query function Manager Table stores entries for any exception packet matching or for matching any special types like control packets which we might not want to forward using general forwarding route using mac-vlan table. Not sure if this makes sense inside Linux kernel? Therefore, we thought of exposing them through the debugfs. Thanks Salil
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c index e59591b1258b..51af55f34e55 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c @@ -211,6 +211,7 @@ static void hns3_dbg_help(struct hnae3_handle *h) dev_info(&h->pdev->dev, "dump qos pri map\n"); dev_info(&h->pdev->dev, "dump qos buf cfg\n"); dev_info(&h->pdev->dev, "dump mac tbl\n"); + dev_info(&h->pdev->dev, "dump port vlan tbl\n"); } static ssize_t hns3_dbg_cmd_read(struct file *filp, char __user *buffer, diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c index 19b76f5e93d7..4a034a59fcb2 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c @@ -530,6 +530,84 @@ static void hclge_dbg_dump_mac_table(struct hclge_dev *hdev) kfree(mc_mac_tbl); } +static void hclge_dbg_dump_port_vlan_table(struct hclge_dev *hdev) +{ + struct hclge_vlan_filter_pf_cfg_cmd *req; + char printf_buf[HCLGE_DBG_BUF_LEN]; + struct hclge_desc desc; + u32 *vlan_bitmap; + u8 vlan_byte_val; + u8 vlan_offset; + u8 vlan_byte; + int vlan_len; + u32 vlan_id; + int ret, i; + bool flag; + + vlan_len = HCLGE_DBG_VLAN_ID_MAX / 8; + vlan_bitmap = kzalloc(vlan_len, GFP_KERNEL); + if (!vlan_bitmap) { + dev_err(&hdev->pdev->dev, + "port vlan table alloc memory failed\n"); + return; + } + + for (vlan_id = 0; vlan_id < HCLGE_DBG_VLAN_ID_MAX; vlan_id++) { + /* Prevent long-term occupation of the command channel. */ + if ((vlan_id % 100) == 0) + msleep(100); + + hclge_cmd_setup_basic_desc(&desc, + HCLGE_OPC_VLAN_FILTER_PF_CFG, true); + + vlan_offset = vlan_id / 160; + vlan_byte = (vlan_id % 160) / 8; + vlan_byte_val = 1 << (vlan_id % 8); + + req = (struct hclge_vlan_filter_pf_cfg_cmd *)desc.data; + req->vlan_offset = vlan_offset; + req->vlan_offset_bitmap[vlan_byte] = vlan_byte_val; + + ret = hclge_cmd_send(&hdev->hw, &desc, 1); + if (ret) { + dev_err(&hdev->pdev->dev, + "call hclge_cmd_send fail, ret = %d\n", ret); + kfree(vlan_bitmap); + return; + } + + if (req->vlan_cfg != 0) + continue; + + vlan_bitmap[(u32)(vlan_id / 32)] |= 1 << (vlan_id % 32); + } + + dev_info(&hdev->pdev->dev, "vlan | port filter bitMap:\n"); + + for (vlan_id = 0; vlan_id < HCLGE_DBG_VLAN_ID_MAX / 32; + vlan_id += 8) { + memset(printf_buf, 0, HCLGE_DBG_BUF_LEN); + snprintf(printf_buf, HCLGE_DBG_BUF_LEN, + "%04d | ", vlan_id * 32); + flag = false; + + for (i = 7; i >= 0; i--) { + snprintf(printf_buf + strlen(printf_buf), + HCLGE_DBG_BUF_LEN - strlen(printf_buf), + "%08x:", vlan_bitmap[(u32)(vlan_id + i)]); + + if (vlan_bitmap[(u32)(vlan_id + i)] > 0) + flag = true; + } + + printf_buf[strlen(printf_buf) - 1] = '\n'; + if (flag) + dev_info(&hdev->pdev->dev, "%s", printf_buf); + } + + kfree(vlan_bitmap); +} + static void hclge_dbg_fd_tcam_read(struct hclge_dev *hdev, u8 stage, bool sel_x, u32 loc) { @@ -603,6 +681,8 @@ int hclge_dbg_run_cmd(struct hnae3_handle *handle, char *cmd_buf) hclge_dbg_dump_qos_buf_cfg(hdev); } else if (strncmp(cmd_buf, "dump mac tbl", 12) == 0) { hclge_dbg_dump_mac_table(hdev); + } else if (strncmp(cmd_buf, "dump port vlan tbl", 18) == 0) { + hclge_dbg_dump_port_vlan_table(hdev); } else { dev_info(&hdev->pdev->dev, "unknown command\n"); return -EINVAL; diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h index b5a784506b9a..f0c7ad535fcc 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h @@ -14,6 +14,9 @@ #define HCLGE_DBG_MAC_TBL_E_PORT 0x3FF #define HCLGE_DBG_MAC_TBL_E_PORT_B BIT(11) +#define HCLGE_DBG_VLAN_ID_MAX 4096 +#define HCLGE_DBG_MNG_TBL_MAX 64 + #pragma pack(1) struct hclge_qos_pri_map_cmd {