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: <53349B27.7070501@mojatatu.com>
Date:	Thu, 27 Mar 2014 17:41:59 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Florian Fainelli <f.fainelli@...il.com>,
	Sergey Ryazanov <ryazanov.s.a@...il.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

I should probably be reading emails backward to catchup, but this
one caught my eye.

On 03/27/14 12:41, Florian Fainelli wrote:

> It duplicates the information when things just work fine, consider an
> external switch connected via RGMII to a CPU Ethernet MAC, you might
> want to get statistics from both sides (the switch CPU port and the
> CPU Ethernet MAC) to diagnose why things are not working as expected,
> which unfortunately happens once in a while with RGMII.
>
> If we expose both net_device, we will be able to retrieve statistics
> about from both sides, without resorting to ad-hoc debugging tools,
> but maybe this is not worth the effort.
>

This is probably the most convincing rationale i have seen
for this netdev. I think the abstraction is what was bothering me
earlier from Jiri's patch. It is not a "master" netdev of the switch
(since a switch port can only be attached to one master),
it is closer to a "conduit" netdev Roopa was alluding to. From
abstraction you dont attach ports to it, it comes with ports - but it is
merely the control for those ports. Would refereing to this port as
"control" be a good way to go forward?
So if i wanted to retrieve hardware stats for sw1p0 i look up its
"control"->dev->somendo and pass it enough information to give me
the hardware stats for sw1p0.
I can see the rate control Sergey is refering to as merely a tc
ingress policer attached on it (which may translate to some hardware
register setting).
Likewise this is probably where my query to "tell me how many
fdb entries you can support" ends up.

>> So there are no reasons
>> to force user to configure this port manually, and automatic
>> configuration of CPU switch port without exporting them as netdev
>> seems as good approach.
>
> Well, maybe that's the answer, since we know that e.g: sw1p3 is always
> connected to e.g: eth0, we could create an automatic bridge between
> those two, this would keep the netdev exposure to user-space, but an
> user would not have to know about that specific detail to get things
> to work.
>

Could ifconfig down of this port have some semantic that nothing comes
to the cpu?

cheers,
jamal
--
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