On Thu, May 24, 2018 at 06:33:10PM +0200, Andrew Lunn wrote: > 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. > Understood, if we missed back anything on handling multicast for the cpu port we'll go back and fix it (i am assuming snooping is the answer here). Multicasting is only one part of the equation though. What about the need for vlans/FDBs on that port though?
Ilias
