netdev - Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath

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: <CAGVrzca=F+jkmpUGViopZ8fXh7M3YBEr2qZAomR5yD+E04XX9Q@mail.gmail.com>
Date:	Thu, 27 Mar 2014 16:46:37 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>,
	Sergey Ryazanov <ryazanov.s.a@...il.com>,
	Jiri Pirko <jiri@...nulli.us>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Neil Horman <nhorman@...driver.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Andy Gospodarek <andy@...yhouse.net>,
	dborkman <dborkman@...hat.com>, ogerlitz <ogerlitz@...lanox.com>,
	jesse <jesse@...ira.com>, pshelar <pshelar@...ira.com>,
	azhou <azhou@...ira.com>, Ben Hutchings <ben@...adent.org.uk>,
	Stephen Hemminger <stephen@...workplumber.org>,
	jeffrey.t.kirsher@...el.com, vyasevic <vyasevic@...hat.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Scott Feldman <sfeldma@...ulusnetworks.com>,
	Lennert Buytenhek <buytenh@...tstofly.org>,
	Shrijeet Mukherjee <shm@...ulusnetworks.com>,
	Felix Fietkau <nbd@...nwrt.org>
Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support of
 switch chip datapath

2014-03-27 16:42 GMT-07:00 Thomas Graf <tgraf@...g.ch>:
> On 03/27/14 at 05:59pm, Jamal Hadi Salim wrote:
>> On 03/27/14 17:54, Florian Fainelli wrote:
>> >2014-03-27 14:47 GMT-07:00 Jamal Hadi Salim <jhs@...atatu.com>:
>>
>> >I think it is. There is nothing in-tree that actually uses that
>> >feature (switch chaining), but all the infrastructure is there to:
>> >
>> >- represent links between switches, which one is cascaded from which
>> >one and get a sense of their addressing within the switch tree
>> >- a function call to get that cascading table to programmed to each switch
>> >- get all relevant "uplink/downlink" switch ports to be configured appropriately
>> >
>>
>> Sounds like we have a winner on this aspect at least.
>> Is it a common setup to have such cascading though - or is this some
>> overzelous way of solving cascading switches within a LAN?
>
> If the DSA code can be refactored, even better. Any issues with
> bumping these Florian?
>
> #define DSA_MAX_SWITCHES        4
> #define DSA_MAX_PORTS           12

I don't have access to the relevant datasheets at the moment, so I
can't remember on the top of my head whether that represents a hard
limit for all the Marvell switches drivers in tree (Lennert would
surely know), but at any rate, this should certainly be made dynamic
based on what the switch driver advertises, so please go ahead bumping
those.
-- 
Florian
--
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