Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath

["John W. Linville" <linville@tuxdriver.com>]

On Wed, Mar 26, 2014 at 02:21:22PM -0400, Neil Horman wrote:
> On Wed, Mar 26, 2014 at 11:29:03AM +0000, Thomas Graf wrote:

> > What I don't understand at this point is how hiding the ports behind
> > a master device would buy us anything. We would still need to abstract
> > the filtering capabilities of the ports at some level and hiding that
> > behind existing tools seems to most convenient way.
> > 
> 
> If we agree that inconsistent frame reception / stack bypass is acceptable, then
> hiding the ports buys us nothing.  My only goal with that suggestion was to
> differentiate ports on a switch device so that the ports were differentiated in
> such a way as to make it clear that they didn't behave like typical NIC ports
> that were meant to receive host terminated traffic only.  If the consensus is
> to allows sparse reception of forwarded traffic at the cpu, then no, its not
> worthwhile and can be ignored.

I don't like the master device idea.  It just seems likely to cause
confusion.  But, we may want something to expose some topology
information to the user.  There could be situations where it is
releavant to know that two netdevs are part of the same hardware
device.

In the past I've also seen boxes with multiple switch chips tied
together either through dedicated "stacking" ports or even just with
ethernet ports directly wired together inside the box.  A variety
of combinations are possible, each with performance considerations
that might be relevant to an admin.  It would be good if we could
help them map-out such relationships.

Maybe the existing bus infrastructure (or something like it) could
be leveraged?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.