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]
Date:	Mon, 22 Feb 2016 13:08:37 -0800
From:	John Fastabend <john.fastabend@...il.com>
To:	Ido Schimmel <idosch@...lanox.com>
CC:	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
	davem@...emloft.net, eladr@...lanox.com, yotamg@...lanox.com,
	ogerlitz@...lanox.com, yishaih@...lanox.com, dledford@...hat.com,
	sean.hefty@...el.com, hal.rosenstock@...il.com,
	eugenia@...lanox.com, roopa@...ulusnetworks.com,
	nikolay@...ulusnetworks.com, hadarh@...lanox.com, jhs@...atatu.com,
	jeffrey.t.kirsher@...el.com, brouer@...hat.com, ivecera@...hat.com,
	rami.rosen@...el.com
Subject: Re: [patch net-next 6/9] mlxsw: spectrum: Unmap local port from module
 during teardown

On 16-02-22 01:00 PM, Ido Schimmel wrote:
> Hi John,
> 
> Mon, Feb 22, 2016 at 10:32:47PM IST, john.fastabend@...il.com wrote:
>> On 16-02-22 10:32 AM, Jiri Pirko wrote:
>>> From: Ido Schimmel <idosch@...lanox.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 <idosch@...lanox.com>
>>> Signed-off-by: Jiri Pirko <jiri@...lanox.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.
> 
> Yep, it's not LAG. You basically have a mapping between a physical
> module and a local port, which is represented by a port netdev.
> 
> Each module has 4 lanes, so if you connect a splitter (say a 2x) you can
> map each 2 lanes to a different port and assign each a new local port.
> These are completely independent from each other, but they can only give
> you 50Gb/s max, as opposed to the original 100Gb/s (as it had 4 lanes
> all to itself).
> 
>>
>> 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?).
> 
> We currently don't have an event that tells us that a splitter is
> connected. Also, had we created / destroyed these based on events, then
> an accidental removal of the splitter would cause all the configuration
> setup on these ports to disappear (say VLANs on a bridged port, unicast
> flooding etc.).
> 

I still think this would be the better implementation. The configuration
should be saved in some daemon anyways and setup based on netdev events
so its not like it would disappear in any real system.

But seeing you don't get an interrupt or anything I guess manual
configuration is going to be the best you can do.


> Thanks.
> 
>>
>> Thanks,
>> John
>>
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ