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]

Message-ID: <CAE4R7bBmhiSCSNu=KhDh+kY7EduLZoeT=yopBUxGaPRQ7sL_qQ@mail.gmail.com>
Date:	Tue, 14 Apr 2015 00:23:41 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	Simon Horman <simon.horman@...ronome.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

On Tue, Apr 14, 2015 at 12:11 AM, Simon Horman
<simon.horman@...ronome.com> wrote:
> 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.

Good.  Sorry about the wasted time.  I'm trying to get the
Documentation/network/switchdev.txt file updated with notes about
setup, so at least we all go the same path, right or wrong.

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

rocker needs help here for rx filters, for things like IGMP snooping
and so on.  promisc is ignored now as you found out.  Maybe after this
vlan stuff gets sorted out with mine and Ronan's patchsets, you can
look at the rx filters again?  I think we'll need to be more selective
with some of the default setups, like the bridge or bond putting port
in promisc by default.  Promisc seems dangerous thing to enable on a
live switch port.  Firehose in mouth kind of thing.

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