netdev - Re: [PATCH/RFC net-next 0/4] Allow use of rocker ports without bridging

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:	Tue, 14 Apr 2015 16:11:49 +0900
From:	Simon Horman <simon.horman@...ronome.com>
To:	Scott Feldman <sfeldma@...il.com>
Cc:	Jiri Pirko <jiri@...nulli.us>, Netdev <netdev@...r.kernel.org>,
	"Arad, Ronen" <ronen.arad@...el.com>
Subject: Re: [PATCH/RFC net-next 0/4] Allow use of rocker ports without
 bridging

Hi Scott,

On Mon, Apr 13, 2015 at 08:43:16AM -0700, Scott Feldman wrote:
> On Mon, Apr 13, 2015 at 7:59 AM, Scott Feldman <sfeldma@...il.com> wrote:
> > On Sun, Apr 12, 2015 at 11:47 PM, Simon Horman
> > <simon.horman@...ronome.com> wrote:
> >> Hi,
> >>
> >> this short series attempts to allow rocker ports to be used when they
> >> are not attached to a bridge. It attempts to make use of flow entries
> >> in a rocker switch where appropriate and otherwise forwards packets up
> >> to the kernel for processing.
> >
> > Hi Simon,
> >
> > Unbridged ports should be working now with current driver/device.  I
> > wonder if you have an older qemu rocker device?  Use master branch of
> > https://github.com/scottfeldman/qemu-rocker.git.

For the record, that is what I am using.

> > My test setup is to IPv4 ping two hosts from two different ports.
> > Something like:
> >
> > sw1:sw1p1:11.0.0.1/24 <----------------> h1:eth1:11.0.0.2/24
> > sw1:sw1p2:12.0.0.1/24 <----------------> h2:eth1:12.0.0.2/24
> >
> > ARP and ping work fine.  What is your test setup?  I haven't spent a
> > lot of time on unbridged port testing, since major focus has been on
> > offloading bridge L2 and L3.

My setup is similar if not the same. I used it to test both bridging
and routing.

> Ah, I think I know why it's not working for you.  You don't have the
> VLAN 8021.q module loaded, do you?  I'm getting these:
> 
> [    2.871619] 8021q: 802.1Q VLAN Support v1.8
> [    2.871629] 8021q: adding VLAN 0 to HW filter on device sw1p1
> [    2.872097] 8021q: adding VLAN 0 to HW filter on device sw1p2
> 
> Which calls into the driver ndo_vlan ops and sets up untagged access.

Thanks! There is now one less mystery in my life.

I had not considered the ndo_vlan ops and with the 802.1q driver present
things seem to work.

> But, dependence on VLAN 802.1q module is wrong I think, and we'll need
> your patch (I haven't reviewed it yet, but I'm assuming it's doing
> basically what loading what VLAN 802.1q driver forces).

Yes, I think that is more or less the case.

One thing that my patches did which does not seem to occur without
them is to cause, or at least try to cause, all packets to
be forwarded to the CPU if the interface is in promiscuous mode.
This seems logical to me.

> The Spring Cleanup patchset has better setlink/dellink support so
> driver can manage VLANs from bridge driver and moves away from
> ndo_vlan ops used with 802.1q VLAN driver.  Ronan (Cc:d) has a VLAN
> patch that builds on top of my Spring Cleanup patchset  I think the
> order of changes will be to get my Spring Cleanup patchset in and then
> get yours/Ronan's patches in.  And rocker can get away from using
> ndo_vlan ops.

Sure, that ordering is entirely fine by me.

> Would you verify that without your patch, and with VLAN 802.1q driver
> loaded, unbridged ports are working?

As noted above, I have verified that scenario works.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html