On Wed, 5 Jun 2019 at 01:16, Russell King - ARM Linux admin <li...@armlinux.org.uk> wrote: > > On Wed, Jun 05, 2019 at 01:03:27AM +0300, Vladimir Oltean wrote: > > On Wed, 5 Jun 2019 at 00:48, Russell King - ARM Linux admin > > <li...@armlinux.org.uk> wrote: > > > > > > On Tue, Jun 04, 2019 at 02:37:31PM -0700, Florian Fainelli wrote: > > > > The firmware/boot loader transition to a full fledged OS with a switch > > > > is a tricky one to answer though, and there are no perfect answers > > > > AFAICT. If your SW is totally hosed, you might want the switch to > > > > forward traffic between all LAN ports (excluding WAN, otherwise you > > > > expose your home devices to the outside world, whoops). > > > > > > > > If your SW is fully operational, then the questions are: > > > > > > > > - do you want a DSA like behavior in your boot loader, in that all ports > > > > are separated but fully usable or do you want a dumb switch model where > > > > any port can forward to the CPU/management port, without any tags or > > > > anything (unmanaged mode) > > > > > > > > - what happens during bootloader to OS handover, should the switch be > > > > held in reset so as to avoid any possible indirect DMA into main memory > > > > as much as power saving? Should nothing happen and let the OS wipe out > > > > clean the setting left by the boot loader? > > > > > > > > All of these are in the realm of policy and trade offs as far as > > > > initializing/disruption goes, so there are no hard and fast answers. > > > > > > For a switch, there are four stages, not two: > > > > > > 1. The out-of-reset state, which from what I've seen seems to be to > > > behave like a dumb switch. > > > > > > 2. The boot loader state, which is generally the same as the > > > out-of-reset state. > > > > > > 3. The OS-booting state, which for a DSA switch in Linux isolates each > > > port from each other. > > > > > > 4. The OS-booted state, which depends on the system configuration. > > > > > > If you are setting up a switch in a STP environment, you _have_ to be > > > aware of all of those states, and plan your network accordingly. > > > While it's possible to argue that the boot loader should isolate the > > > ports, it may be that the system gets hosed to the point that the boot > > > loader is unable to run - then you have a switch operating in a STP > > > environment acting as a dumb switch. > > > > > > The same actually goes for many switches - consider your typical DSL > > > router integrated with a four port switch. By default, that switch > > > forwards traffic between each port. If you've setup the ports to be > > > isolated, each time the router is rebooted (e.g., due to a > > > configuration change) it will forward traffic between all ports until > > > the routers OS has finished booting and applied the switch > > > configuration. > > > > > > What I'm basically saying is that if you're going to the point of > > > using such hardware in a STP environment, you _must_ pay attention > > > to the behaviour of the hardware through all phases of its operation > > > and consider the consequences should it fail in any of those phases. > > > > > > -- > > > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > > > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down > > > 622kbps up > > > According to speedtest.net: 11.9Mbps down 500kbps up > > > > Hi Russell, > > > > The dumb switch was just an example. The absolute same thing (unwanted > > PHY connection) applies to regular NICs. I am not aware of any setting > > that makes the MAC ignore frames as long as they observe the > > appropriate MII spec. And the hardware will go on to process those > > frames, potentially calling into the operating system and making it > > susceptible to denial of service. > > Having authored several network device drivers, and worked on several > others, I think you have a misunderstanding somewhere. >
You caught me. But even ignoring the NIC case, isn't the PHY state machine inconsistent with itself? It is ok with callink phy_suspend upon ndo_stop, but it won't call phy_suspend after phy_connect, when the netdev is implicitly stopped? > It is not expected that the MAC will be "alive" while the network > interface is down - it is expected that the MAC will be disabled, and > memory necessary for buffer rings etc will not be claimed. > > > That is unless you set up your > > buffer rings/queues/whatever in the ndo_open/ndo_close callbacks. > > So yes, that is what is expected - so that when the interface is down, > the memory needed for the buffer rings and packet buffers is given > back to the system for other uses. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up > According to speedtest.net: 11.9Mbps down 500kbps up Regards, -Vladimir
