Message-ID: <88e01f4c-202e-565a-de22-d0ef20b6c989@ti.com>
Date:   Wed, 27 Jun 2018 18:03:07 -0500
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Ivan Vecera <ivecera@...hat.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Networking <netdev@...r.kernel.org>,
        <ivan.khoronzhuk@...aro.org>, Sekhar Nori <nsekhar@...com>,
        Jiří Pírko <jiri@...nulli.us>,
        Francois Ozog <francois.ozog@...aro.org>, <yogeshs@...com>,
        <spatton@...com>, <Jose.Abreu@...opsys.com>
Subject: Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev
 mode of operation on cpsw driver



On 06/27/2018 03:40 PM, Arnd Bergmann wrote:
> On Wed, Jun 27, 2018 at 9:18 PM, Grygorii Strashko
> <grygorii.strashko@...com> 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
>>>> <ilias.apalodimas@...aro.org> 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

Powered by blists - more mailing lists