netdev - Re: [PATCH] net: phy: b53: switchdev driver for Broadcom BCM53xx switches

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: <CACna6rypRBT3JijOhYmz_0U_MBBN4LKsZnHdY1MrpYtxc9ZT0w@mail.gmail.com>
Date:	Wed, 25 Feb 2015 07:44:09 +0100
From:	Rafał Miłecki <zajec5@...il.com>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	Andy Gospodarek <gospo@...ulusnetworks.com>,
	"David S. Miller" <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>,
	Jonas Gorski <jogo@...nwrt.org>,
	Hauke Mehrtens <hauke@...ke-m.de>,
	Felix Fietkau <nbd@...nwrt.org>, Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH] net: phy: b53: switchdev driver for Broadcom BCM53xx switches

On 24 February 2015 at 23:55, Florian Fainelli <f.fainelli@...il.com> wrote:
> On 24/02/15 14:50, Rafał Miłecki wrote:
>> On 24 February 2015 at 23:30, Andy Gospodarek <gospo@...ulusnetworks.com> wrote:
>>> I see there is an xmit function, but no napi registration at all.
>>>
>>> Is this simply because the SoC ethernet dev is doing all the frame rx?
>>> Is is able to demux the frames correctly, so it is clear which swXpY
>>> received the frame?  That will be necessary to ensure that standard
>>> applications that want to open sockets directly on the needed interfaces
>>> can still function properly.
>>
>> If you take a look at b53_port_xmit you'll start understanding why
>> there is no NAPI ;)
>>
>> As said in the commit message, these switches are really simple
>> devices. We can't actually send packets to the particular ports
>> (unless something has changed in the more recent hardware).
>
> These switches all support Broadcom tags, so you could use your host CPU
> Ethernet MAC to send/receive packets to/from specific ports of the
> switch, and then this is just like DSA, but everything that you say
> below is true.

OK, I'll need to learn about Broadcom tags then. Right now this is a
bit unclear for me. Are Broadcom tags supposed to be used with VLANs
at the same time?

I can get idea of sending packets in such setup. We could send packets
using VLAN interface (with VLAN tag), packets would go to all ports
assigned to the VLAN. Or we should send packets using port interface
with adding Broadcom tag there. Such packets would target a single
port. Quite easy.

But how switch would handle receiving packets from ports? If we were
using Broadcom tags and VLANs at the same time, how switch would know
if the packets received on port N should get a VLAN tag (PVID) or
should get a Broadcom tag?


>> So if we want to get any packets from switch port N we have to:
>> 1) Assign some PVID to the port N
>> 2) Put port N and "CPU port" in the same VLAN (matching PVID)
>> 3) Starting with above switch will tag every packet received on port N
>> and forward it to the "CPU port"
>> 4) Listen on the Ethernet device connected to the "CPU port" for
>> packets with a proper VLAN ID
>>
>> Now with the above example there are 2 most common scenarios you may
>> want to consider:
>>
>> 1) Having full control over every port
>> It requires assigning unique VLAN for every single port. Any switching
>> (forwarding packets) has to be done in software then.
>>
>> 2) Having few groups of ports
>> This is the most common case for home routers. You usually want to
>> have group of "LAN" ports when you don't really care which port
>> provided a given packet. This also allows using switch for offloading
>> traffic between machines the same ports group.
>
> With that use case in mind, yes, your driver is doing exactly that,
> allowing you to define VLAN membership for particular ports within a
> group, all of this gets sent to the host CPU, where the IP routing happens.

Not really. Let's say I setup VLAN N with 3 members:
1) Port A with PVID N & UNTAGGED
2) Port B with PVID N & UNTAGGED
3) CPU port
If machine connected to port A will start sending traffic to machine
connected to port B, switch will do all the work. CPU won't be
involved.

Just for sure I've tested above and I got 650 Mb/s iperf traffic with
99% idle BCM4706 CPU.

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