netdev - Re: [PATCH 0/4] RFC CPSW switchdev mode

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 24 May 2018 18:33:10 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ilias Apalodimas <ilias.apalodimas@...aro.org>
Cc:     Ivan Vecera <ivecera@...hat.com>, Jiri Pirko <jiri@...nulli.us>,
        netdev@...r.kernel.org, grygorii.strashko@...com,
        ivan.khoronzhuk@...aro.org, nsekhar@...com,
        francois.ozog@...aro.org, yogeshs@...com, spatton@...com
Subject: Re: [PATCH 0/4] RFC CPSW switchdev mode

On Thu, May 24, 2018 at 07:02:54PM +0300, Ilias Apalodimas wrote:
> On Thu, May 24, 2018 at 05:25:59PM +0200, Andrew Lunn wrote:
> > O.K, back to the basic idea. Switch ports are just normal Linux
> > interfaces.
> > 
> > How would you configure this with two e1000e put in a bridge? I want
> > multicast to be bridged between the two e1000e, but the host stack
> > should not see the packets.
> I am not sure i am following. I might be missing something. In your case you
> got two ethernet pci/pcie interfaces bridged through software. You can filter
> those if needed. In the case we are trying to cover, you got a hardware that
> offers that capability. Since not all switches are pcie based shouldn't we be
> able to allow this ?

switchdev is about offloading what Linux can do to hardware to
accelerate it. The switch is a block of accelerator hardware, like a
GPU is for accelerating graphics. Linux can render OpenGL, but it is
better to hand it over to the GPU accelerator.

Same applies here. The Linux bridge can bridge multicast. Using the
switchdev API, you can push that down to the accelerator, and let it
do it.

So you need to think about, how do you make the Linux bridge not pass
multicast traffic to the host stack. Then how do you extend the
switchdev API so you can push this down to the accelerator.

To really get switchdev, you often need to pivot your point of view a
bit. People often think, switchdev is about writing drivers for
switches. Its not, its about how you offload networking which Linux
can do down to a switch. And if the switch cannot accelerate it, you
leave Linux to do it.

When you get in the details, i think you will find the switchdev API
actually already has what you need for this use case. What you need to
figure out is how you make the Linux bridge not pass multicast to the
host. Well, actually, not pass multicast it has not asked for. Then
accelerate it.

    Andrew