netdev - Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev mode of operation on cpsw driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK8P3a1eLUL3qHZ6P3txEkgFWuiOxTPm8jXagG2nD-3Y+Rwagw@mail.gmail.com>
Date:   Thu, 28 Jun 2018 09:53:07 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Grygorii Strashko <grygorii.strashko@...com>
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 Thu, Jun 28, 2018 at 1:03 AM, Grygorii Strashko
<grygorii.strashko@...com> wrote:
>
>
> 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.

I was referring to dynamically reconfiguring the device during switch
attachment (which you say is hard in the current driver, and I can believe that,
but it does seem like a problem that can be solved with a proper design),
and the kernel configuration must have no impact on the default behavior
in that case.

This would still meet the requirements for the use case you mention,
as one would definitely never want to bridge between an EtherCAT
interface and a management interface.

>>> 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.

But wouldn't that new driver have the exact same problem with reconfiguring
the device between the boot-time configuration that behaves like
dual_emac and the switch configuration once the switchdev gets attached?

      Arnd