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: <CAE4R7bAFBBdhoAVx4s0Ljc-Kcpvn8F-bHG+N6-1oxntnearWZQ@mail.gmail.com>
Date:	Wed, 7 Oct 2015 10:32:45 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	John Fastabend <john.fastabend@...il.com>,
	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Ido Schimmel <idosch@...lanox.com>, eladr@...lanox.com,
	Thomas Graf <tgraf@...g.ch>,
	Alexei Starovoitov <ast@...mgrid.com>,
	David Laight <David.Laight@...lab.com>
Subject: Re: [patch net-next v3 06/14] rocker: introduce worlds infrastructure

On Tue, Oct 6, 2015 at 11:14 PM, Jiri Pirko <jiri@...nulli.us> wrote:
> Wed, Oct 07, 2015 at 03:50:08AM CEST, sfeldma@...il.com wrote:
>
> <snip>
>
>>
>>> Also I wonder how this works when a pkt ingresses a port in mode A and
>>> egresses a port in mode B? What fib/fdb tables does it cross when this
>>> happens? It seems easier to just have two switch devices not a
>>> hybrid. If this per port implementation maps to some hardware that
>>> would be really interesting though.
>>
>>In retrospect, I regret adding the port mode feature to rocker.  I
>>like the world idea, so we can have a device with different
>>pipeline/resources, but we should have locked all ports on a switch to
>>one mode, or even as you hinted at earlier, use a unique sub-device ID
>>for a switch with all ports in a particular mode.  If you want to
>>ports with different worlds, just instantiate a switch in each world.
>>Instantiating new devices is easy.
>>
>>But, now Jiri has locked on to the dynamic port mode idea with pit
>>bull zeal, to the point of being able to switch a port mode at any
>>time from one mode to another from the host.  I just don't see that as
>>a real-world use-case.  Life is too short and we need to be focusing
>>on switchdev features, not refactoring or adding cool but useless
>>features.
>
> Can can still change this if you want. We can make
> ROCKER_TLV_CMD_PORT_SETTINGS_MODE read-only in hw (As it is in fact now
> as we have only one world).
>
> Then we add another property:
> static Property rocker_properties[] = {
>             DEFINE_PROP_STRING("name", Rocker, name),
>             DEFINE_PROP_STRING("world", Rocker, world),
>                 ....
>
> and we use this value in pci_rocker_init instead of r->world_dflt
>
> Looks straightforward.

Yes, perfect, I totally on-board with that change.  This puts all
ports on the device in the same mode.  I you want ports in a different
mode, instantiate another switch.

Mixing port modes on a switch, either statically or dynamically, would
have created another problem.  Switchdev uses the switch_id for each
port to know when ports belong to the same switch, same switching
domain, if you will.  Mixing port modes within a switch breaks this.
For example, the check we added to avoid double forwarding of pkts by
the bridge and the device depends on ports on the switch having the
same switch_id.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ