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]

Date:	Wed, 26 Mar 2014 16:16:04 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	Jiri Pirko <jiri@...nulli.us>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Neil Horman <nhorman@...driver.com>,
	Thomas Graf <tgraf@...g.ch>, 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-26 15:53 GMT-07:00 Jamal Hadi Salim <jhs@...atatu.com>:
> On 03/26/14 18:22, Florian Fainelli wrote:
>>
>> 2014-03-26 14:51 GMT-07:00 Jamal Hadi Salim <jhs@...atatu.com>:
>
>
>>
>> eth0 corresponds to a CPU Ethernet MAC facing e.g: sw1p3 switch port.
>> It is "regular" Ethernet driver connected to the switch without
>> switch-specific logic. The goal is twofold:
>>
>> - allow any regular Ethernet driver to be connected to an external
>> switch via e.g: MDIO/MDC or other without specific switch knowledge
>> - represents accurately how the hardware is designed/connected
>>
>
> Gah. Sorry - I missed the MII interface.
> In such a case as shown here then, how do you control sw1p0-3?

Most switches expose individual ports as individual PHY addresses
either on the same MDIO bus the Ethernet MAC is connected to the
switch, or an internal one which is accessible through a special PHY
address on the "regular" MDIO bus. Ports 0-3 are accessible
individually at MDIO addresses 0-3 and the special CPU port has a
special PHY address e.g: 16 for Marvell, 30 for Broadcom, which
delivers register access to global and per-port configuration
registers. For memory-mapped switches, well, you get per-port register
ranges, so this is much simpler.

ethtool would be the user-interface to talk individually to these
ports here, and the DSA driver just goes talk to the individual port
through MDIO to get their port status (right now it regularly polls
for the port link status/duplex/speed).

>
>
>> but maybe, we can simplify and have e.g: sw1p3 and eth0 be the same
>> interface...
>
>
> It sounds to me the CPU side is only a driver for sw1p3.

I think what I had in mind when I wrote that part of the mail is some
special hardware here on which the CPU Ethernet MAC output queues do
not have a 1:1 mapping to the corresponding switch egress port output
queues, but I think you are right.

>
>
>>>
>>> Note: even the high end chips tend to have the concept of a "cpu port"
>>> but my experience is to hide that as part of the switch driver.
>
>
> Note: the high end devices "cpu ports" are accessible typically
> via PCIE interfaces for control and some DMA for data activity.
>
> cheers,
> jamal
>
>



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