On Mon, Feb 22, 2016 at 12:32:47PM -0800, John Fastabend wrote: > On 16-02-22 10:32 AM, Jiri Pirko wrote: > > From: Ido Schimmel <ido...@mellanox.com> > > > > When splitting a port we replace it with 2 or 4 other ports. To be able > > to do that we need to remove the original port netdev and unmap it from > > its module. However, we first mark it as disabled, as active ports > > cannot be unmapped. > > > > Signed-off-by: Ido Schimmel <ido...@mellanox.com> > > Signed-off-by: Jiri Pirko <j...@mellanox.com> > > --- > > Hi Jiri, Ido, > > You've sort of lost me on this port splitting/unsplitting thread. What > does this actually do? Are you just creating two netdevs and LAGing them > in the hardware, I'm guessing not or you wouldn't have some device API > for it and would do it using normal methods. > > If its something to do with physical layout of the board itself why > don't you trigger this based on some init time introspection or an > interrupt if someone plugs in a port splitting cable/module (does that > exist?).
In some implementations there are interrupts that fire when modules are connected or removed. Even if an interrupt doesn't fire, it would be possible to have a timer event/workqueue in a driver that could read QFSP VPD information periodically to note that something has changed in the hardware and reconfigure as needed. I actually would perfer keying on something like that to perform a configuration change like rather than requiring the user configure it. Today you have to swap a 4x10GbE for a 1x40GbE module and then performing significant software config (possibly flashing EEPROMs in the case of some NICs) each time. That seems too error prone as a user could swap out a QSFP on what they think is one port on a switch and then perform a software change on another port without realizing it. That accidental disruption seems less tolerable than the one where there wrong physical port was added and removed and config needs to be applied. Network management apps can properly solve the problem where devices come and go accidently due to connecting the wrong QSFP, so that seems like a less critical use-case to handle than what I described above.
