From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grygorii Strashko Subject: Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev mode of operation on cpsw driver Date: Wed, 27 Jun 2018 18:03:07 -0500 Message-ID: <88e01f4c-202e-565a-de22-d0ef20b6c989@ti.com> References: <1528974690-31600-5-git-send-email-ilias.apalodimas@linaro.org> <20180618161627.GC5865@lunn.ch> <20180618201940.GA5890@apalos> <671c83ea-6227-cc09-e604-14cfa6804726@redhat.com> <20180620175128.GA27235@apalos> <20180620180342.GA28303@apalos> <033dd1bc-0401-a058-5283-4938ac39f701@redhat.com> <20180621124552.GA15208@apalos> <20180622074532.GA27414@apalos> <8e908165-9412-57b8-bc30-5b337fdd4033@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: Ilias Apalodimas , Ivan Vecera , Florian Fainelli , Andrew Lunn , Networking , , Sekhar Nori , =?UTF-8?B?SmnFmcOtIFDDrXJrbw==?= , Francois Ozog , , , To: Arnd Bergmann Return-path: Received: from fllv0015.ext.ti.com ([198.47.19.141]:45460 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751192AbeF0XDY (ORCPT ); Wed, 27 Jun 2018 19:03:24 -0400 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 06/27/2018 03:40 PM, Arnd Bergmann wrote: > On Wed, Jun 27, 2018 at 9:18 PM, Grygorii Strashko > wrote: >> On 06/22/2018 02:45 AM, Ilias Apalodimas wrote: >>> On Thu, Jun 21, 2018 at 05:31:31PM +0200, Arnd Bergmann wrote: >>>> On Thu, Jun 21, 2018 at 2:45 PM, Ilias Apalodimas >>>> wrote: >>>>> On Thu, Jun 21, 2018 at 02:19:55PM +0200, Ivan Vecera wrote: >>>> >>> >>> If people like this idea, i can send a V3 with these changes. >> >> Nop. I do not think this is good idea, because "dual_mac" mode has very strict >> meaning and requirements. In "dual_mac" mode both port should be teated and work >> as *separate network devices" (like two, not connected PCI eth cards) - the fact that >> it's implemented on top of hw, which can do packet switching doesn't matter here and just a >> technical solution. >> Main requirements: >> 1) No packet forwarding is allowed inside hw under any circumstances, only Linux >> Host SW can consume or forward packets >> 2) One interface should not block another inside CPSW hw which implies special FIFOs/HW >> configuration > > Could you explain the reasoning behind those requirements? I honestly don't > see what difference it makes, given that a new driver with switchdev support > would look exactly like the dual_emac mode as long as you don't add the > two interfaces into a bridge, and the user-visible behavior is already required > to be the same. Am not aware of all details - it's custom filtering/routing/firewalling applications. (Like Industrial Ethernet (EtherCAT) to Ethernet converter on one port and another port is for control/monitoring purposes) And yes, it looks similar. But, as I mentioned, dual_mac mode required CPSW to be configured differently and reconfiguration during attaching to the bridge is very (very) problematic - first, FIFOs/HW configuration not expected to be done on the fly, second vlans 1/2 reserved for this mode while bridge uses vid 1 by default. In dual_mac mode port just switched to promiscuous mode when attached to the bridge. Using kernel configuration option will break multi-platform support as all CPSW instances will start behaving as switch. > >> As per, above switchdev functionality doesn't make too much sense in "dual_mac" mode and >> introducing dual meaning for this mode is not a good choice either. >> >> Again, as discussed, option 4 is considered as preferred. > > Do you mean creating an incompatible binding that could be implemented by > the same driver, or duplicating the driver with one copy of the old binding > and one copy for the new binding? The idea is to keep dual_mac and one port mode (60% of use cases) as is while create new driver for two port switch mode by refactoring existing driver and re-using generic parts as max as possible. Also, update bindings as there are a lot of ancient and obsolete DT definitions which still supported for compatibility reasons. And, yes, possibility to mix dual_mac and switchdev in one driver is considered, but postponed as it hard to implement now, and as the main target is to drop custom ioctl and switch to standard Linux interfaces for switch. One step at time. -- regards, -grygorii