Message ID | 20181202230933.15560-1-salil.mehta@huawei.com |
---|---|
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