netdev - Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Oct 2013 08:53:13 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Felix Fietkau <nbd@...nwrt.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Neil Horman <nhorman@...driver.com>
CC:	John Fastabend <john.r.fastabend@...el.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	John Crispin <blogic@...nwrt.org>,
	Jonas Gorski <jogo@...nwrt.org>,
	Gary Thomas <gary@...assoc.com>,
	Vlad Yasevich <vyasevic@...hat.com>,
	Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch
 configuration API

On 10/23/13 08:04, Felix Fietkau wrote:

> A typical switch has something like 5-8 ports (+ one port that goes to
> the CPU),

My opinion:
So exposing the 5-8 ports as netdevs would be useful. Giving access to
their stats through per-port netdevs etc. i.e a switch/bridge will show
up on bootup and the 5-8 ports as well. The 5-8 ports will show up
as bridge ports to the switch.
If something requires other "services" like l3 - I am assuming that
would show up in the cpu port, but its role is really to demux
and send it to ingress of the originating port on ASIC (i.e dont
think it should be exposed).

>and handles the entire forwarding path on its own.

This is default behavior. i.e learning and flooding.
Can you at least retrieve the fdb? example how to figure out which
port a specific MAC address resides?

>It usually
> allows creating VLANs and assigning ports to them (tagged, untagged),

I wasnt sure about the vlans<->port mapping as i stated in the earlier
email. So on this issue, I can see the challenge.
You could of course put vlan netdevs on top of switch ports and then
attach those to the bridge, but i cant see an approach if a switch port
can support more than one vlan without having multiple bridges. example:
bridgeA: link ports {swp0:vlan1, swp1:vlan2, swp0:vlan4}
bridgeB: link ports {swp0:vlan3, swp1:vlan4, swp1:vlan2}

 > but many (probably most) switches do not support controlling the
> forwarding path via a MAC address based FDB.
>

Ok, so operations like fdb_add/del will be disallowed. This is really
up to the driver to not expose such ops.

> Many also do not have support for a packet header to indicate the
> incoming/outgoing switch port, so creating one netdev per port will work
> only for link status, not for the data path.

You mean when such a packet arrives on the "cpu" port, you wont know the
originating port?

cheers,
jamal

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