[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181204105554.GD741@lunn.ch>
Date: Tue, 4 Dec 2018 11:55:54 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Salil Mehta <salil.mehta@...wei.com>
Cc: David Miller <davem@...emloft.net>,
"jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
"Zhuangyuzeng (Yisen)" <yisen.zhuang@...wei.com>,
"lipeng (Y)" <lipeng321@...wei.com>,
"mehta.salil@...src.net" <mehta.salil@...src.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linuxarm <linuxarm@...wei.com>,
Liuzhongzhu <liuzhongzhu@...wei.com>,
"jiri@...nulli.us" <jiri@...nulli.us>,
"f.fainelli@...il.com" <f.fainelli@...il.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?
> 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
Powered by blists - more mailing lists