On 24 February 2015 at 23:55, Florian Fainelli [off-list ref] wrote:

On 24/02/15 14:50, Rafał Miłecki wrote:

quoted

On 24 February 2015 at 23:30, Andy Gospodarek [off-list ref] wrote:

quoted

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?

quoted

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ł