Re: [PATCH/RFC net-next] rocker: forward packets to CPU when a port in promiscuous mode

From: Scott Feldman <sfeldma@gmail.com>
To: Simon Horman <simon.horman@netronome.com>
Cc: Jiri Pirko <jiri@resnulli.us>, Netdev <netdev@vger.kernel.org>,
	john fastabend <john.fastabend@gmail.com>
Subject: Re: [PATCH/RFC net-next] rocker: forward packets to CPU when a port in promiscuous mode
Date: Mon, 13 Jul 2015 23:37:59 -0700	[thread overview]
Message-ID: <CAE4R7bChu5sAKpU5tUkENfWZMhaWSs3EQZeggUxR=BjKSOqOeg@mail.gmail.com> (raw)
In-Reply-To: <1436415931-16469-1-git-send-email-simon.horman@netronome.com>

On Wed, Jul 8, 2015 at 9:25 PM, Simon Horman <simon.horman@netronome.com> wrote:
> This change allows the CPU to see all packets seen by a port when the
> netdev associated with the port is in promiscuous mode.
>
> This change was previously posted as part of a larger patch and in turn
> patchset which also aimed to allow rocker interfaces to receive packets
> when not bridged. That problem has subsequently been addressed in a
> different way by Scott Feldman.
>
> When this change was previously posted Scott indicated that he had some
> reservations about sending all packets from a switch to the CPU. The
> purpose of posting this patch is to start discussion of weather this
> approach is appropriate and if not how else we might move forwards.
>
> In my opinion if host doesn't want all packets its shouldn't put a port
> in promiscuous mode. But perhaps that is an overly naïve view to take.
>
> My main motivation for this change at this time is to allow rocker to
> work with Open vSwitch and it appears that this change is sufficient to
> reach that goal. Another approach might be to teach
> rocker_port_master_changed() about Open vSwitch.
>
> In the longer term I believe Open vSwitch should be able to program
> flows into rocker 'hardware' and thus not all packets would reach the CPU.

Hi Simon,

I like your alternate approach to teach rocker about Open vSwitch
using rocker_port_master_change() and only when port is captured by
OVS would we install the "promisc" filter to pass all traffic up.
(Maybe call it ROCKER_CTRL_DFLT_OVS rule?).

Putting a non-bridged, non-ovs port into promisc is kind of weird for
a switch port.  I think of the port in L3 mode by default, where the
port is locked down for all but some selective mcasts, and only opened
up by installing explicit routes.  (Unlike a bridged port where we
flood everything L2 we don't understand).

So maybe first pass is to pass up everything when port is captured by
OVS, and then later refine what's passed up per ovs flows on that
port.

-scott