Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Salil Mehta <salil.mehta@huawei.com>
To:     Andrew Lunn <andrew@lunn.ch>
CC:     David Miller <davem@davemloft.net>,
        "jakub.kicinski@netronome.com" <jakub.kicinski@netronome.com>,
        "Zhuangyuzeng (Yisen)" <yisen.zhuang@huawei.com>,
        "lipeng (Y)" <lipeng321@huawei.com>,
        "mehta.salil@opnsrc.net" <mehta.salil@opnsrc.net>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linuxarm <linuxarm@huawei.com>,
        Liuzhongzhu <liuzhongzhu@huawei.com>,
        "jiri@resnulli.us" <jiri@resnulli.us>,
        "f.fainelli@gmail.com" <f.fainelli@gmail.com>
Subject: RE: [RFC net-next 3/9] net: hns3: Add "port vlan table" information
 query function
Thread-Topic: [RFC net-next 3/9] net: hns3: Add "port vlan table"
 information query function
Thread-Index: AQHUipRWcc4RvlD+b0Kh0MVNnjjtYqVtlV4AgAAAJYCAALCJsIAAE+IAgABlhbA=
Date:   Tue, 4 Dec 2018 20:55:29 +0000
Message-ID: <F4CC6FACFEB3C54C9141D49AD221F7F93C06C4F4@FRAEML521-MBX.china.huawei.com>
References: <20181202230933.15560-1-salil.mehta@huawei.com>
 <20181202230933.15560-4-salil.mehta@huawei.com>
 <20181203151222.6e56efcd@cakuba.netronome.com>
 <20181203.151253.1348214769326219632.davem@davemloft.net>
 <F4CC6FACFEB3C54C9141D49AD221F7F93C06855D@FRAEML521-MBX.china.huawei.com>
 <20181204105554.GD741@lunn.ch>
In-Reply-To: <20181204105554.GD741@lunn.ch>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> 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