From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath Date: Thu, 27 Mar 2014 17:55:50 +0100 Message-ID: <20140327165550.GN2845@minipsycho.orion> References: <53330639.8050403@cumulusnetworks.com> <20140326165934.GH2869@minipsycho.orion> <20140326173536.GJ2869@minipsycho.orion> <20140326181436.GL2869@minipsycho.orion> <53334BDA.1060608@mojatatu.com> <20140327065616.GA2845@minipsycho.orion> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Florian Fainelli , Jamal Hadi Salim , Roopa Prabhu , Neil Horman , Thomas Graf , netdev , David Miller , Andy Gospodarek , dborkman , ogerlitz , jesse , pshelar , azhou , Ben Hutchings , Stephen Hemminger , jeffrey.t.kirsher@intel.com, vyasevic , Cong Wang , John Fastabend , Eric Dumazet , Scott Feldman , Lennert Buytenhek , Shrijeet Mukherjee , Felix Fietkau To: Sergey Ryazanov Return-path: Received: from mail-ee0-f43.google.com ([74.125.83.43]:55354 "EHLO mail-ee0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756694AbaC0Qzz (ORCPT ); Thu, 27 Mar 2014 12:55:55 -0400 Received: by mail-ee0-f43.google.com with SMTP id e53so3115797eek.16 for ; Thu, 27 Mar 2014 09:55:54 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Thu, Mar 27, 2014 at 03:10:24PM CET, ryazanov.s.a@gmail.com wrote: >Hi all, > >sorry for the intrusion, but let me place my 2 cents. > >2014-03-27 10:56 GMT+04:00 Jiri Pirko : >> Wed, Mar 26, 2014 at 11:22:51PM CET, f.fainelli@gmail.com wrote: >>>2014-03-26 14:51 GMT-07:00 Jamal Hadi Salim : >>>> On 03/26/14 14:14, Jiri Pirko wrote: >>>>> >>>>> Wed, Mar 26, 2014 at 06:58:32PM CET, f.fainelli@gmail.com wrote: >>>>>> >>>>>> 2014-03-26 10:35 GMT-07:00 Jiri Pirko : >>>> >>>> >>>> >>>>>> You are right, sw1p0 and sw1p1 were meant to be, say LAN ports in my >>>>>> example. >>>>>> >>>>>> I think there is an implicit convention that sw1 represents the >>>>>> Ethernet switch port connected to the CPU Ethernet MAC, and that it is >>>>>> always connected, hence there is no need to create a "fake" bridge to >>>>>> link sw1 to eth0 for instance? >>>>> >>>>> >>>>> I think you are kind of mixing apples and oranges (or I might be I'm not >>>>> understanding you correctly). >>>>> This is how I see it, sticking to the names you use in the example: >>>>> >>>>> (sw1) (abstract place-holder netdev) >>>>> -------- >>>>> switch chip CPU >>>>> ----------------------- ------ >>>>> sw1p0 sw1p1 sw1p2 sw1p3 eth0 >>>>> | | | | | >>>>> PHY PHY PHY ------someMII----- >>>>> >>>>> You see that eth0 is the CPU part of the "connection" and sw1p3 is the >>>>> switch part (port representation). >>>>> >>>> >>>> >>>> Florian - I am sure you explained this before; I just dont remember. Why >>>> is there need to expose eth0? It seems to me sw1p0-3 are abstracted >>>> already in the kernel and the "cpu port" is merely a control interface. >>> >>>eth0 corresponds to a CPU Ethernet MAC facing e.g: sw1p3 switch port. >>>It is "regular" Ethernet driver connected to the switch without >>>switch-specific logic. The goal is twofold: >>> >>>- allow any regular Ethernet driver to be connected to an external >>>switch via e.g: MDIO/MDC or other without specific switch knowledge >>>- represents accurately how the hardware is designed/connected >>> >>>but maybe, we can simplify and have e.g: sw1p3 and eth0 be the same interface... >> >> I believe that hawing both sw1p3 and eth0 is the correct way of >> modelling this. sw1p3 is instance if switch chip driver representing the >> actual port of a switch. eth0 is an instance of some other ordinary NIC >> driver (8139too is my favorite :)) >> >> This model allows to draw the exact picture. >> Also, when you add the described possibility to use iplink to build >> vlans, bridges whatever on the switch ports, it makes perfect sense to >> have this model. >> >> Merging sw1p3 and eth0 would cause a loose of information and confusion. >> > >CPU switch port and switch fabric itself should be configured in >consistence with host, in first place I mean a set of VLANs. Also it >should be mentioned that some generic knobs such as port rate and >duplex mode are meaningless for CPU switch port and a lot of status >information (rx/tx counters etc.) duplicates statistics of host >interface which is connected to switch port. So there are no reasons >to force user to configure this port manually, and automatic >configuration of CPU switch port without exporting them as netdev >seems as good approach. How can you tell that certain port is connected to CPU? That is platform specific. > >-- >BR, >Sergey